Coupon Accepted Successfully!


Requirements Engineering


 Requirements engineering is about communicating with the customer.  The objective is to arrive at a written agreement describing the functionality of the software to be developed.  The final product of this activity is usually called a specification and forms the basis for all the development activities that follow.  It turns out that the activities of this stage of the development life cycle are among the most difficult, but perhaps the most important.


The problem of developing a clear understanding of what the customer needs has become a classic challenge.  Newcomers to the field are sometimes surprised to learn that the customer representatives themselves find it difficult to communicate their needs clearly. Given this state of affairs, projects frequently find themselves changing requirements throughout the development period.  The later in the development process that a requirement is changed, the more difficult and more expensive that change becomes.  Therefore, what may seem to be excessive time spent on this first phase is in fact an excellent investment in risk reduction for the entire project.  Many tools are used at this stage to increase confidence in understanding what the system should be like, including rapid prototyping, user scenarios and functions/feature lists.  Bringing modeling and design tools into this phase is not unusual.  Not surprisingly, this phase is characterized by lengthy meetings between the developer and customer.


Requirements Analysis and Modeling


The focus of this activity is on defining the operational characteristics of the software and has three primary goals of providing the following: 

  • behavioral description of customer requirements with the emphasis on the what rather than the how 
  • foundation for the software design 
  • operational system definition that can be used for system validation after the software development is complete.

The following subactivities are identified with requirements analysis and modeling:


Domain analysis


Reusability is an important goal in software development since it reduces development costs, increases reliability and reduces development time.  Domain analysis is the process of identifying patterns that can be reused.  These patterns can be any common functions or features that have the potential for broad use across an application domain.  An application domain is typically a class of problem such as financial, medical or aerospace; however, the broader the reuse the better.


Data modeling


Analysis modeling sometimes begins with the identification of all data objects that are to be processed in the system and the relationships between these objects.  Data modeling is used for large database and information systems applications.


Object oriented analysis


The object-oriented (OO) approach to analysis represents the latest “paradigm shift” in analysis methodology and is epitomized by the Java language at the implementation stage. Some of the claims which have made this approach popular are as follows:

  • Customers can understand OO models with no programming knowledge thus facilitating the all-important early phases of communication.
  • OO languages promote code reuse and thus programmer productivity
  • The OO design and analysis methods are accommodating to change


The OO approach is based on modeling of the problem domain using classes and objects.

Class: defines the data and procedural abstractions for the information content and behavior of some system entity.

Method: representation of one of the behaviors of a class.

Object: instance of a specific class. Objects can inherit the attributes and operations defined for a class. Classes are sometimes illustrated as “cookie cutters” and the associated objects as “cookies”.


The goal of object-oriented analysis is the design of all classes and associated methods that are appropriate for the system being developed.


The unified modeling language (UML) has been developed for the modeling and development of object-oriented (OO) systems.  UML has become an industry standard for OO development.


Scenario-based modeling


End-user involvement in a software project is critical to its success.  Scenario-based modeling provides mechanisms for capturing information on how end-users desire to interact with the system.  UML provides support for the development of interaction scenarios that begin with the writing of use-cases that describe a use of the system by a specific end-user.  The dynamics of these use-cases can be represented in UML activity diagrams similar to flow charts.  More complex interactions can be captured in UML swimlane diagrams that can model concurrent activities.


Flow oriented modeling


Although not part of UML, the input-process-output data flow diagrams (DFD) continue to be a very popular analysis modeling tool and can be used to augment UML diagrams.  Data flow in the system can be modeled in a hierarchical fashion with DFDs with higher level context diagrams being refined with greater detailed DFDs at lower levels.


Dynamic modeling


After static data and attribute relationships have been established, it is useful to create behavioral models to represent the systems response to external events.  Use-cases can be used to identify events and UML sequence diagrams can be used to model how events trigger transitions from one object to another.


Test Your Skills Now!
Take a Quiz now
Reviewer Name