Contents

Principles of Software Engineering and Requirements Modeling

• Requirements Engineering
• Groundwork for Understanding of Software Requirements
• Overview of Eliciting Requirements
• Developing Use Cases, Building the Requirements Model;
• Negotiating Requirements;
• Validating Requirements;

2
 Requirements Engineering

Introduction:

The broad spectrum (range, variety) of tasks and techniques that

lead to an understanding of requirements is called requirements engineering.

•In other words , Requirements engineering (RE) refers to the process of

defining, documenting and maintaining requirements

From a requirements engineering is a major software engineering action that

begins during the communication activity and continues into the modeling
activity. It must be adapted to the needs of the process, the project, the
product, and the people doing the work.

Requirements engineering builds a bridge to design and construction.

3
“Requirements engineering provides the appropriate mechanism for
understanding what the customer wants, analyzing need, assessing
feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification, and managing the
requirements as they are transformed into an operational system.”

It encompasses seven distinct tasks: (IEENSVM)

 Inception (beginning)
 Elicitation (bring out)
 Elaboration (expansion , explanation)
 Negotiation
 Specification Elicitation (Practice of collecting the
requirements of a system from users,
 Validation
customers and other stakeholders)
 Management 4
1. Inception ( Beginning , Start)
At project inception, ask a set of question that establish a 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 other stakeholders and the software team.

2. Elicitation (bring out) requirements from all stakeholders.

Ask the customer, the users, and others what the objectives for the system
or product are, what is to be accomplished, how the system or product fits
into the needs of the business, and finally, how the system or product is to
be used on a day-to-day basis.

5
2. Elicitation cont..
Number of problems are encountered as elicitation occurs.

Problems of scope :
The boundary of the system is ill-defined or the customers/users specify
unnecessary technical detail that may confuse, rather than clarify.

Problems of understanding :
The customers/users are not completely sure of what is needed, have a poor
understanding of the limitations, don’t have a full understanding of the
problem domain, omit information ,specify requirements that conflict with
the needs of other customers/users, or specify requirements that are
ambiguous.

Problems of volatility (unpredictability):

The requirements change over time. To help overcome these problems, you
must approach requirements gathering in an organized manner.
6
3. Elaboration (expansion, explanation) :
create an analysis model that identifies data, function and behavioral
requirements.
Elaboration is driven by the creation and refinement of user scenarios
that describe how the end user (and other actors) will interact with
the system.

4. Negotiation - agree on a deliverable system that is realistic (Reasonable)

for developers and customers.
- Customers, users, and other stakeholders are asked to category
requirements and then discuss conflicts in priority.
- Using an iterative approach that prioritizes requirements, assesses their
cost and risk, and addresses internal conflicts, requirements are eliminated,
combined, and/or modified so that each party achieves some measure of
satisfaction
7
5. Specification — Specification means different things to different
people. It 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

8
6. 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 validation examines the specification to ensure that all
software requirements have been stated unambiguously; that
inconsistencies, omissions, and errors have been detected and corrected;

7. Requirement Management
> Requirements for computer-based systems change, and the desire to
change requirements persists throughout the life of the system.
>Requirements management is a set of activities that help the project team
identify, control, and track requirements and changes to requirements at
any time as the project proceeds.
9
Inception: The steps required to establish the groundwork(basic
work) for An understanding of software requirements…

Groundwork For Understanding of Software Requirements

 Requirements engineering is simply a matter of conducting meaningful

conversations with colleagues who are well-known members of the team.
But reality is often quite different.

 Customer(s) or end users may be located in a different city or country,

may have only a vague(unclear) idea of what is required, may have
conflicting opinions about the system to be built, may have limited
technical knowledge, and may have limited time to interact with the
requirements engineer

10
Groundwork For Understanding of Software Requirements

Here are the steps required to establish the groundwork for an understanding
of software requirements—to get the project started in away that will keep it
moving forward toward a successful solution.

1. Identifying Stakeholders
2. Recognizing Multiple Viewpoints
3. Working toward Collaboration
4. Asking the First Questions

11
Groundwork For Understanding of Software Requirements

1.Identifying Stakeholders

Sommer ville and Sawyer [Som97] define a stakeholder as “anyone who

benefits in a direct or indirect way from the system which is being
developed.”

Ex : business operations managers, product managers, marketing people,

internal and external customers, end users, consultants, product
engineers, software engineers, support and maintenance engineers, and
others.

Each stakeholder has a different view of the system, achieves different

benefits, and is open to different risks if the development effort should
fail.
12
Groundwork For Understanding of Software Requirements

2. Recognizing Multiple Viewpoints

Because many different stakeholders exist, the requirements of the system

will be explored from many different points of view.

Each of these constituencies (voters) will contribute information to the

requirements engineering process. As information from multiple
viewpoints is collected, emerging requirements may be inconsistent or
may conflict with one another.

You should categorize all stakeholder information (including inconsistent

and conflicting requirements) in a way that will allow decision makers to
choose an internally consistent set of requirements for the system. 14

13
Groundwork For Understanding of Software Requirements

3. Working toward Collaboration

If five stakeholders are involved in a software project, you may have

----five (or more) different opinions about

- The proper set of requirements, after that

- Customers (and other stakeholders) must collaborate
among themselves and with software engineering
practitioners if a successful system is to result.

The job of a requirements engineer is to identify areas of

commonality and areas of conflict or inconsistency.

14
Groundwork For Understanding of Software Requirements

4. Asking the First Questions

first set of context-free questions focuses on the customer and other

stakeholders, the overall project goals and benefits. For example,
you might ask:

• Who is behind the request for this work?

• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?

These questions help to identify all stakeholders who will have interest
in the software to be built.

15
Groundwork For Understanding of Software Requirements

Asking the First Questions cont..

In addition, the questions identify the measurable benefit of a successful

implementation and possible alternatives to custom software development.
The next set of questions enables you to gain a better understanding of the problem
and allows the customer to voice his or her perceptions about a solution:

• How would you characterize “good” output that would be generated by a successful
solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the solution will
be used?
• Will special performance issues or constraints affect the way the solution is
approached?

16
Groundwork For Understanding of Software Requirements

Asking the First Questions cont..

The final set of questions focuses on the effectiveness of the

communication activity itself. Gause and Weinberg [Gau89] call these
“meta-questions” and propose the following (abbreviated) list:

• Are you the right person to answer these questions? Are your answers
“official”?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?

These questions (and others) will help to “break the ice” and initiate the
communication that is essential to successful elicitation
17
 Eliciting Requirements

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

 Quality Function Deployment
 Usage Scenarios
 Elicitation Work Products

18
1.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 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.
• 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.

19
Collaborative Requirements Gathering cont..

 During inception basic questions and answers establish the scope

of the problem and the overall perception of a solution. Out of these
initial meetings, the developer and customers write a one- or two-
page “product request.”

 A meeting place, time, and date are selected; a facilitator is

chosen; and attendees from the software team and other
stakeholder organizations are invited to participate. The product
request is distributed to all attendees before the meeting date.

20
Collaborative Requirements Gathering cont..
In reality, others would contribute to this narrative during the
requirements gathering meeting and considerably more information would
be available. But even with additional information, ambiguity would be
present, omissions would likely exist, and errors might occur. For now, the
preceding “functional description” will suffice.

Each attendee is asked to make another list of services (processes or

functions) that manipulate or interact with the objects. Finally, lists of
constraints (e.g., cost, size, business rules) and performance criteria (e.g.,
speed, accuracy) are also developed.

21
Collaborative Requirements Gathering cont..

The lists of objects can be pinned to the walls of the room using large sheets
of paper, stuck to the walls using adhesive-backed sheets, or written on a
wall board.

After individual lists are presented in one topic area, the group creates a
combined list by eliminating redundant entries, adding any new ideas that
come up during the discussion, but not deleting anything. After you create
combined lists for all topic areas, discussion—coordinated by the facilitator
—ensues.

In many cases, an object or service described on a list will require further

explanation. To accomplish this, stakeholders develop mini-specifications for
entries on the lists
22
2. 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”.

QFD identifies three types of requirements

1. Normal requirements
2. Expected requirements
3. Exciting requirements

23
Quality Function Deployment cont..

1.Normal requirements :
 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.

 Examples of normal requirements might be requested types of graphical

displays, specific system functions, and defined levels of performance.

2. Expected requirements :
 These requirements are understood to the product or system and may be
so fundamental that the customer does not openly state them.

 Their absence will be a cause for significant dissatisfaction.

 Examples of expected requirements are: ease of human/machine

interaction, overall operational correctness and reliability, and ease of
software installation.
24
Quality Function Deployment cont..

3. Exciting requirements :

- These features go beyond the customer’s expectations and prove to be very

satisfying when present.

- For example, software for a new mobile phone comes with standard features, but
is coupled with a set of unexpected capabilities (e.g., multi touch screen, visual
voice mail) that delight every user of the product.

25
3. Usage Scenarios
 As requirements are gathered, an overall vision of system functions and
features begins 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, provide a description of how the system will be used.

26
4. 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 :

• A statement of need and feasibility.

• A bounded statement of scope for the system or product.
• A list of customers, users, and other stakeholders who
participated in requirements elicitation.
• A description of the system’s technical environment.
• A list of requirements (preferably organized by function)
• A set of usage scenarios
Each of these work products is reviewed by all people who have
participated in requirements elicitation.
27
 Developing Use Cases

“ A use case captures a contract ... [that] describes the system’s behavior
under various conditions as the system responds to a request from one of its
stakeholders . . .”

In essence, a use case tells a stylized story about how an end user (playing
one of a number of possible roles) interacts with the system under a specific
set of circumstances. The story may be narrative text, an outline of tasks or
interactions, a template-based description, or a diagrammatic
representation.

Regardless of its form, a use case depicts the software or system from the
end user’s point of view.

28
The first step in writing a use case is to define the set of “actors” that will be
involved in the story.

Actors are the different people (or devices) that use the system or product
within the context of the function and behavior that is to be described.

Actors represent the roles that people (or devices) play as the system
operates.

Defined somewhat more formally, an actor is anything that communicates

with the system or product and that is external to the system itself. Every
actor has one or more goals when using the system. 30

29
Note that an actor and an end user are not necessarily the same thing. A
typical user may play a number of different roles when using a system,
whereas an actor represents a class of external entities that play just one
role in the context of the use case.

As an example, consider a machine operator (a user) who interacts with the

control computer for a manufacturing cell that contains a number of robots
and numerically controlled machines.

After careful review of requirements, the software for the control computer
requires four different modes (roles) for interaction: programming mode,
test mode, monitoring mode, and troubleshooting mode.

Therefore, four actors can be defined: programmer, tester, monitor, and

trouble shooter. In some cases, the machine operator can play all of these
roles.

30
EACH SCANARIO (USE CASE) should be answered THE FOLLOWING
QUESTIONS:

• Who is the primary actor, the secondary actor(s)?

• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor obtain, 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?

31
Example :

we define four actors: homeowner (a user), setup manager (likely the

same person as homeowner, but playing a different role), sensors
(devices attached to the system), and the monitoring and response
subsystem (the central station that monitors the SafeHome home
security function). 32
The homeowner actor interacts with the home security function in a
number of different ways using either the alarm control panel or a PC:

• Enters a password to allow all other interactions.

• Inquires about the status of a security zone.
• Inquires about the status of a sensor.
• Presses the panic button in an emergency.
• Activates/deactivates the security system.

33
1.The homeowner observes the SafeHome control panel (Figure) to
determine if the system is ready for input. If the system is not ready, a not
ready message is displayed on the LCD display, and the homeowner must
physically close windows or doors so that the not ready message disappears

2. The homeowner uses the keypad to key in a four-digit password. The

password is compared with the valid password stored in the system. If the
password is incorrect, the control panel will beep once and reset itself for
additional input. If the password is correct, the control panel awaits further
action.

3. The homeowner selects and keys in stay or away (see Figure 5.1) to
activate the system. Stay activates only perimeter sensors (inside motion
detecting sensors are deactivated).Away activates all sensors.

4. When activation occurs, a red alarm light can be observed by the

homeowner.
34
 The basic use case presents a high-level story that describes the interaction
between the actor and the system.
 The following template for detailed descriptions of use cases:

Use case: InitiateMonitoring

Primary actor: Homeowner

Goal in context : To set the system to monitor sensors when the

home owner leaves the house or remains inside.

Preconditions: System has been programmed for a password and to

recognize various sensors.

Trigger: The homeowner decides to “set” the system, i.e., to turn on

the alarm functions.

Scenario: 1. Homeowner: observes control panel

2. Homeowner: enters password
3. Homeowner: selects “stay” or “away”
4. Homeowner: observes read alarm light to indicate that
SafeHome has been armed 35
Exceptions: 1. Control panel is not ready: homeowner checks all sensors
to determine which are open; closes them.
2. Password is incorrect (control panel beeps once):
homeowner re enters correct password.
3. Password not recognized: monitoring and response
subsystem must be contacted to reprogram password.
4. Stay is selected: control panel beeps twice and a stay light
is lit; perimeter sensors are activated.
5. Away is selected: control panel beeps three times and an
away light is lit; all sensors are activated.

Priority: Essential, must be implemented

When available: First increment

Frequency of use: Many times per day

Channel to actor: Via control panel interface

Secondary actors: Support technician, sensors

Channels to secondary actors: Support technician: phone line

Sensors: hardwired and radio frequency interfaces 36

Open issues:

1.Should there be a way to activate the system without the use of a

password or with an abbreviated password?

2. Should the control panel display additional text messages?

3. How much time does the homeowner have to enter the password from
the time the first key is pressed?

4. Is there a way to deactivate the system before it actually activates?

37
38
 Building the Requirements Model

Introduction:

The intent of the analysis model is to provide a description of the required

informational, functional, and behavioral domains for a computer-based
system.

 Elements of the Requirements 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 (e.g. the use case)

A set of generic elements is common to most requirements models.

1. Scenario-based elements.
2. Class-based elements
3. Behavioral elements
4. Flow-oriented elements

39
Building the Requirements Model
1. Elements of the Requirements Model :
1. Scenario-based elements.
2. Class-based elements
3. Behavioral elements
4. Flow-oriented elements

2. Analysis Pattern

40
# Elements of the Requirements Model cont..

1.Scenario-based elements.

The system is described from the user’s point of view using a scenario-based
approach.

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 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.

41
Scenario-based elements cont..

42
2. Class-based elements. Class diagram for
sensor

• 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 canbe used to depict a
Sensor class for the SafeHome
security function (Figure). 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
43
3. 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 externally observable mode of behavior. In addition, the state
diagram indicates actions (e.g., process activation) taken as a consequence
of a particular event.

In addition to behavioral representations of the system as a whole, the

behavior of individual classes can also be modeled. 44
Behavioral elements cont..

45
4. Flow – Oriented elements :

Information is transformed as it flows through a computer-based system.

The system accepts input in a variety of forms, applies functions to
transform it, and produces output in a variety of forms.

Input may be a control signal transmitted by a transducer, a series of

numbers typed by a human operator, a packet of information transmitted
on a network link, or a voluminous data file retrieved from secondary
storage.

46
# Analysis Patterns

Anyone who has done requirements engineering on more than a few

software projects begins to notice that certain problems reoccur across all
projects within a specific application domain.

These analysis patterns suggest solutions (e.g., a class, a function, a behavior)

within the application domain that can be reused when modeling many
applications.

Two benefits that can be associated with the use of analysis patterns:

47
First, analysis patterns speed up the development of abstract analysis models
that capture the main requirements by providing reusable analysis models with
examples as well as a description of advantages and limitations.

Second, analysis patterns facilitate the transformation of the analysis model into
a design model by suggesting design patterns and reliable solutions for common
problems.

48
 Negotiating Requirements

In reality, you may have to enter into a negotiation with one or more
stakeholders. In most cases, stakeholders are asked to balance
functionality, performance, and other product or system characteristics
against cost and time-to-market.

The intent of this negotiation is to develop a project plan that meets

stakeholder needs while at the same time reflecting the real-world
constraints (e.g., time, people, budget) that have been placed on the
software team.

The best negotiations strive for a “win-win” result. That is, stakeholders
win by getting the system or product that satisfies the majority of their
needs and you (as a member of the software team) win by working to
realistic and achievable budgets and deadlines.

49
A set of negotiation activities at the beginning of each software process
iteration. Rather than a single customer communication activity, the
following activities are defined:

1. Identification of the system or subsystem’s key stakeholders.

2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into
a set of win-win conditions for all concerned (including the software
team).

Successful completion of these initial steps achieves a win-win result,

which becomes the key criterion for proceeding to subsequent software
engineering activities.

50
 Validating Requirements

Introduction: As each element of the requirements model is created, it is

examined for inconsistency, omissions, and ambiguity. The requirements
represented by the model are prioritized by the stakeholders and grouped
within requirements packages that will be implemented as software
increments.

A review of the requirements model addresses the following questions:

• Is each requirement consistent with the overall objectives for the

system/product?

• Have all requirements been specified at the proper level of abstraction?

• Is the requirement really necessary or does it represent an add-on

feature that may not be essential to the objective of the system?

51
• Is each requirement bounded and unambiguous?

• Does each requirement have attribution? That is, is a source (generally,

a specific individual) noted for each requirement?

• Do any requirements conflict with other requirements?

• Is each requirement achievable in the technical environment that will

house the system or product?

• Is each requirement testable, once implemented?

• Does the requirements model properly reflect the information,

function, and behavior of the system to be built?

52
• Has the requirements model been “partitioned” in a way that exposes
progressively more detailed information about the system?

• Have requirements patterns been used to simplify the requirements

model? Have all patterns been properly validated? Are all patterns
consistent with customer requirements?

These and other questions should be asked and answered to ensure that
the requirements model is an accurate reflection of stakeholder needs
and that it provides a solid foundation for design.

53