Requirements Engineering-I

 Inception—ask a set of questions that establish …

 basic understanding of the problem
 the people who want a solution
 the nature of the solution that is desired, and
 the effectiveness of preliminary communication and
collaboration between the customer and the developer
 Elicitation—elicit requirements from all stakeholders
 Elaboration—create an analysis model that identifies data, function
and behavioral requirements
 Negotiation—agree on a deliverable system that is realistic for
developers and customers
Requirements Engineering-II
 Specification—can be any one (or more) of the following:
A written document
A set of models
A formal mathematical
A collection of user scenarios (use-cases)
A prototype
 Validation—a review mechanism that looks for
errors in content or interpretation
areas where clarification may be required
missing information
inconsistencies (a major problem when large products or
systems are engineered)
conflicting or unrealistic (unachievable) requirements.
 Requirements management
Eliciting Requirements
Requirements elicitation (also called requirements gathering)
combines elements of problem solving, elaboration, negotiation, and
specification. In order to encourage a collaborative, team-oriented
approach to requirements gathering, stakeholders work together to
identify the problem, propose elements of the solution, negotiate
different approaches, and specify a preliminary set of solution
requirements.
 Collaborative Requirements Gathering
Many different approaches to collaborative requirements gathering
have been proposed. Each makes use of a slightly different scenario,
but all apply some variation on the following basic guidelines:
• Meetings (either real or virtual) are conducted and attended by both
software engineers and other stakeholders.
•Rules for preparation and participation are established.
• An agenda is suggested that is formal enough to cover all important
points but informal enough to encourage the free flow of ideas.
Eliciting Requirements
• A “facilitator” (can be a customer, a developer, or an outsider) controls
the meeting.
• A “definition mechanism” (can be work sheets, flip charts, or wall
stickers or an electronic bulletin board, chat room, or virtual forum)
is used.
 Quality Function Deployment
Quality function deployment (QFD) is a quality management
technique that translates the needs of the customer into technical
requirements for software. QFD “concentrates on maximizing
customer satisfaction from the software engineering process”
[Zul92]. To accomplish this, QFD emphasizes an understanding
of what is valuable to the customer and then deploys these values
throughout the engineering process.
Eliciting Requirements
Within the context of QFD, normal requirements identify the
objectives and goals that are stated for a product or system during
meetings with the customer. If these requirements are present, the
customer is satisfied. Expected requirements are implicit to the
product or system and may be so fundamental that the customer does
not explicitly state them. Their absence will be a cause for significant
dissatisfaction. Exciting requirements go beyond the customer’s
expectations and prove to be very satisfying when present.
Although QFD concepts can be applied across the entire software
process. Specific QFD techniques are applicable to the requirements
elicitation activity. QFD uses customer interviews and observation,
surveys, and examination of historical data (e.g., problem reports) as
raw data for the requirements gathering activity. These data are then
translated into a table of requirements—called the customer voice
table—that is reviewed with the customer and other stakeholders.
A variety of diagrams, matrices, and evaluation methods are then
used to extract expected requirements and to attempt to derive
exciting requirements [Aka04]
Eliciting Requirements
 Usage Scenarios
As requirements are gathered, an overall vision of system functions and
features begin to materialize. However, it is difficult to move into more
technical software engineering activities until you understand how
these functions and features will be used by different classes of end
users. To accomplish this, developers and users can create a set of
scenarios that identify a thread of usage for the system to be
constructed. The scenarios, often called use cases [Jac92], provide a
description of how the system will be used.
 Elicitation Work Products
The work products produced as a consequence of requirements
elicitation will vary depending on the size of the system or product to
be built. For most systems, the work products include:
(1) a statement of need and feasibility,
(2) a bounded statement of scope for the system or product,
(3) a list of customers, users, and other stakeholders who participated
in requirements elicitation,
Eliciting Requirements
(4) a description of the system’s technical environment,
(5) a list of requirements (preferably organized by function) and the
domain constraints that applies to each,
(6) A set of usage scenarios that provide insight into the use of the system
or product under different operating conditions, and
(7) any prototypes developed to better define requirements. Each of these
work products is reviewed by all people who have participated in
requirements elicitation.
 Agile Requirements Elicitation
Within the context of an agile process, requirements are elicited by asking all
stakeholders to create user stories. Each user story describes a simple system
requirement written from the user’s perspective. User stories can be written
on small note cards, making it easy for developers to select and manage a
subset of requirements to implement for the next product increment.
Proponents claim that using note cards written in the user’s own language
allows developers to shift their focus to communication with stakeholders on
the selected requirements rather than their own agenda .
Eliciting Requirements
Although the agile approach to requirements elicitation is attractive for many
software teams, critics argue that a consideration of overall business goals and
nonfunctional requirements is often lacking. In some cases, rework is required
to accommodate performance and security issues. In addition, user stories may
not provide a sufficient basis for system evolution over time
 Service-Oriented Methods
Service-oriented development views a system as an aggregation of services. A
service can be “as simple as providing a single function, for example, a
request/response-based mechanism that provides a series of random numbers,
or can be an aggregation of complex elements, such as the Web service API”
Requirements elicitation in service-oriented development focuses on the
definition of services to be rendered by an application.
Most service design methods emphasize understanding the customer, thinking
creatively, and building solutions quickly. To achieve these goals,
requirements elicitation can include ethnographic studies, innovation
workshops, and early low-fidelity prototypes. Techniques for eliciting
requirements must also acquire information about the brand and the
stakeholders’ perceptions of it.
 Requirements Analysis
Requirements analysis specifies software’s operational characteristics
indicates software's interface with other system elements establishes
constraints that software must meet Requirements analysis allows the
software engineer (called an analyst or modeler in this role) to: elaborate
on basic requirements established during earlier requirement engineering
tasks build models that depict user scenarios, functional activities,
problem classes and their relationships, system and class behavior, and
the flow of data as it is transformed.
Requirements Modeling Strategies
 One view of requirements modeling, called 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.

 A second approach to analysis modeled, called object oriented

analysis, focuses on
• the definition of classes and
• the manner in which they collaborate with one another to
effect customer requirements
Building the Analysis Model
The intent of the analysis model is to provide a description of the
required informational, functional, and behavioral domains for a
computer-based system. The model changes dynamically as you learn
more about the system to be built, and other stakeholders understand
more about what they really require. For that reason, the analysis
model is a snapshot of requirements at any given time. You should
expect it to change.

As the analysis model evolves, certain elements will become

relatively stable, providing a solid foundation for the design tasks that
follow. However, other elements of the model may be more volatile,
indicating that stakeholders do not yet fully understand requirements
for the system. We present a brief overview in the sections that follow
 Elements of the Analysis Model
There are many different ways to look at the requirements for a computer-
based system. Some software people argue that it’s best to select one mode of
representation and apply it to the exclusion of all other modes.
Building the Analysis Model
Other practitioners believe that it’s worthwhile to use a number of
different modes of representation to depict the analysis model.
Different modes of representation force you to consider requirements
from different viewpoints—an approach that has a higher probability
of uncovering omissions, inconsistencies, and ambiguity. A set of
generic elements is common to most analysis models.
 Scenario-based elements.
The system is described from the user’s point of view using a
scenario-based approach. For example, basic use cases and their
corresponding use case diagrams (Fig.8.2) evolve into more
elaborate template-based use cases. Scenario-based elements of the
requirements model are often the first part of the model that is
developed. As such, they serve as input for the creation of other
modeling elements. Figure 8.3 depicts a UML activity diagram for
eliciting requirements and representing them using use cases. Three
levels of elaboration are shown, culminating in a scenario-based
representation.
Building the Analysis Model

Fig. 8.2 UML use case diagram for Fig. 8.3 UML activity diagram for
SafeHome home security function eliciting requirements
Building the Analysis Model
Class-based elements.
Each usage scenario implies a set of objects that are manipulated as
an actor interacts with the system. These objects are categorized
into classes—a collection of things that have similar attributes and
common behaviors. For example, a UML class diagram can be used
to depict a Sensor class for the SafeHome security function (Figure
8.4). Note that the diagram lists the attributes of sensors (e.g., name,
type) and the operations (e.g., identify, enable) that can be applied to
modify these attributes. In addition to class diagrams, other
analysis modeling elements depict the manner in which classes
collaborate with one another and the relationships and interactions
between classes.

Fig. 8.4 Class diagram for sensor

Building the Analysis Model
Behavioral elements.
The behavior of a computer-based system can have a profound effect on the
design that is chosen and the implementation approach that is applied.
Therefore, the requirements model must provide modeling elements that
depict behavior. The state diagram is one method for representing the
behavior of a system by depicting its states and the events that cause the
system to change state. A state is any observable mode of behavior. In
addition, the state diagram indicates what actions (e.g., process activation)
are taken as a consequence of a particular event. To illustrate the use of a
state diagram, consider software embedded within the SafeHome control
panel that is responsible for reading user input. A simplified UML state
diagram is shown in Figure 8.5

Fig. 8.5 UML state diagram notation

 Scenario-Based Modeling
Although the success of a computer-based system or product is measured in
many ways, user satisfaction resides at the top of the list. If you understand how
end users (and other actors) want to interact with a system, your software team
will be better able to properly characterize requirements and build meaningful
analysis and design models. Hence, requirements modeling with UML begins
with the creation of scenarios in the form of use cases and activity diagrams.

Creating a Preliminary Use Case

Alistair Cockburn characterizes a use case as a “contract for behavior”. The
“contract” defines the way in which an actor uses a computer-based system to
accomplish some goal. In essence, a use case captures the interactions that occur
between producers and consumers of information and the system itself.

a use case describes a specific usage scenario in straightforward language from

the point of view of a defined actor. But how do you know (1) what to write
about, (2) how much to write about it, (3) how detailed to make your description,
and (4) how to organize the description? These are the questions that must be
answered if use cases are o provide value as a requirements modeling tool.
How Much to Write About?
Use-Cases
 a scenario that describes a “thread of usage” for a system
 actors represent roles people or devices play as the system functions
 users can play a number of different roles for a given scenario

Developing a Use-Case
 What are the main tasks or functions that are performed by the
actor?
 What system information will the actor acquire, produce or change?
 Will the actor have to inform the system about changes in the
external environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?
Use-Case Diagram
Data Modeling

 examines data objects independently of processing

 focuses attention on the data domain
 creates a model at the customer’s level of abstraction
 indicates how data objects relate to one another
Class-Based Modeling
 Class-based modeling represents:
 objects that the system will manipulate
 operations (also called methods or services) that will
be applied to the objects to effect the manipulation
 relationships (some hierarchical) between the objects
 collaborations that occur between the classes that
are defined.
 The elements of a class-based model include
classes and objects, attributes, operations, and
collaboration diagrams.
Requirements Modeling for WebApps
Content Analysis. The full spectrum of content to be provided by the
WebApp is identified, including text, graphics and images, video,
and audio data. Data modeling can be used to identify and describe
each of the data objects.

Interaction Analysis. The manner in which the user interacts with the
WebApp is described in detail. Use-cases can be developed to
provide detailed descriptions of this interaction.

Functional Analysis. The usage scenarios (use-cases) created as part

of interaction analysis define the operations that will be applied to
WebApp content and imply other processing functions. All
operations and functions are described in detail.

Configuration Analysis. The environment and infrastructure in which

the WebApp resides are described in detail.