Understanding Requirements:

• Requirements Engineering,
• Establishing the ground work,
• Eliciting Requirements,
• Developing use cases,
• Building the requirements model,
• Negotiating Requirements,
• Validating Requirements
 REQUIREMENTS ANALYSIS
• Requirements analysis allows you to elaborate on basic requirements established during
the inception, elicitation, and negotiation tasks that are part of requirements engineering
• The requirements modeling action results in one or more of the following types of models:
• Scenario-based models of requirements from the point of view of various system
“actors”
• Data models that depict the information domain for the problem
• Class-oriented models that represent object-oriented classes (attributes and operations)
and the manner in which classes collaborate to achieve system requirements
• Flow-oriented models that represent the functional elements of the system and how
they transform data as it moves through the system
• Behavioral models that depict how the software behaves as a consequence of external
“events”
• These models provide a software designer with information that can be translated to
architectural, interface, and component-level designs.
• Finally, the requirements model (and the software requirements specification) provides the
developer and the customer with the means to assess quality once software is built.
Overall Objectives and Philosophy
• Throughout requirements modeling, your primary focus is on what, not how.
• What user interaction occurs in a particular circumstance,
• what objects does the system manipulate,
• what functions must the system perform,
• what behaviors does the system exhibit,
• what interfaces are defined, and
• what constraints apply?
• The analyst should model what is known and use that model as the basis for design of the
software increment.
• The requirements model must achieve three primary objectives:
• To describe what the customer requires,
• To establish a basis for the creation of a software design, and
• To define a set of requirements that can be validated once the software is built.
• The analysis model bridges the gap between a system-level description that describes
overall system or business functionality as it is achieved by applying software, hardware,
data, human, and other system elements and a software design that describes the
software’s application architecture, user interface, and component-level structure. This
relationship is illustrated in Figure 6.1.
Analysis Rules of Thumb
• A number of worthwhile rules of thumb that should be followed when creating the analysis model:
• The model should focus on requirements that are visible within the problem or business domain. The
level of abstraction should be relatively high. “Don’t get bogged down in details” [Arl02] that try to
explain how the system will work.
• Each element of the requirements model should add to an overall understanding of software
requirements and provide insight into the information domain, function, and behavior of the system.
• Delay consideration of infrastructure and other nonfunctional models until design. That is, a
database may be required, but the classes necessary to implement it, the functions required to
access it, and the behavior that will be exhibited as it is used should be considered only after
problem domain analysis has been completed.
• Minimize coupling throughout the system. It is important to represent relationships between classes
and functions. However, if the level of “interconnectedness” is extremely high, effort should be
made to reduce it.
• Be certain that the requirements model provides value to all stakeholders. Each constituency has its
own use for the model. For example, business stakeholders should use the model to validate
requirements; designers should use the model as a basis for design; QA people should use the
model to help plan acceptance tests.
• Keep the model as simple as it can be. Don’t create additional diagrams when they add no new
information. Don’t use complex notational forms, when a simple list will do.
Domain Analysis.
• Software domain analysis is the identification, analysis, and specification of common
requirements from a specific application domain, typically for reuse on multiple projects
within that application domain. . . . [Object-oriented domain analysis is] the identification,
analysis, and specification of common, reusable capabilities within a specific application
domain, in terms of common objects, classes, subassemblies, and frameworks
Requirements Modelling Approaches
• 2 approaches to analysis modelling
• structured analysis : considers data and the processes that transform the
data as separate entities. Data objects are modeled in a way that defines their
attributes and relationships. Processes that manipulate data objects are
modeled in a manner that shows how they transform data as data objects
flow through the system
• object-oriented analysis: focuses on the definition of classes and the manner
in which they collaborate with one another to effect customer requirements.
UML and the Unified Process are predominantly object oriented.
 THE UNIQUE NATURE OF WEBAPPS
• The following
 THE UNIQUE NATURE OF WEBAPPS
• The following
 THE UNIQUE NATURE OF WEBAPPS
• The following
 THE UNIQUE NATURE OF WEBAPPS
• The following
 THE UNIQUE NATURE OF WEBAPPS
• The following
 THE UNIQUE NATURE OF WEBAPPS
• The following
 THE UNIQUE NATURE OF WEBAPPS
• The following
 THE UNIQUE NATURE OF WEBAPPS
• The following
 THE UNIQUE NATURE OF WEBAPPS
• The following
 THE UNIQUE NATURE OF WEBAPPS
• The following
 SOFTWARE ENGINEERING
In order to).