Chapter 5

• Understanding Requirements

1
• Requirements Engineering
• Establishing the groundwork
• Eliciting Requirements
• Developing Use Cases, Building the
Requirements Model
• Negotiating Requirements, Validating
Requirements

2
3
 These slides are designed to
accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw- 4
Hill, 2009). Slides copyright 2009 by
A software requirement can be of 3 types:
•Functional requirements
•Non-functional requirements
•Domain requirements

5
6
• Functional requirements describe what specifically
needs to be implemented in a particular system or
product and what actions users have to take to
interact with the software. They determine what the
system should do.
• Non-functional requirements show what properties
and features a particular solution has, namely, how
the system will work and why.

7
• As a rule, the non-functional requirements primarily include various
product quality attributes determining system quality features, most
often as listed below:
1. Availability – requirements for app continuous running, for example,
24/7, minimum idle time, etc.
2. Reliability – app behavior in case of alarm status, for example,
automatic restart and operation recovery.
3. Scalability – ways to expand the system and avoid adversely affected
performance.
4. Performance – how many simultaneous users or transactions the system
is to service and its response time.
5. Security – app operation and use of safety requirements related to access
control, private data processing, and external attack risk reduction.
6. Usability – ease of use and user-friendly interface, that allow users to
seamlessly interact with the product.
7. Extensibility – requirements for app extensibility in case there is a need
to add new functional requirements.
8
 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

9
 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
10
11
 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

12
What are the basic guidelines for conducting a Collaborative
requirements gathering meeting?
i) 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.

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

14
 Eliciting Requirements

Conduct FAST
meetings

Make lists of
functions, classes

Make lists of
constraints, etc.

formal prioritization?
Elicit requirements
yes no

Use QFD to informally define actors

draw use-case
write scenario
diagram

Create Use-cases
complete template

15
 Building the Analysis Model
• Elements of the analysis model
– Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an
“actor” and the system
– Class-based elements
• Implied by scenarios
– Behavioral elements
• State diagram
– Flow-oriented elements
• Data flow diagram
16
 Use-Cases
• A collection of user scenarios that describe the thread of usage of a system
• Each scenario is described from the point-of-view of an “actor”—a person or
device that interacts with the software in some way
• Each scenario answers 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 extensions might be considered as the story is described?
– What variations in the actor’s interaction are possible?
– 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?

17
 Use-Case Diagram
Arms/ disarms
system

Accesses system sensors

homeowner

Responds to
alarm event

Encounters an
error condition

system Reconfigures sensors

18
Class Diagram
From the SafeHome system …

Sensor

name/id
type
location
area
characteristics

identify()
enable()
disable()
reconfigure()

19
State Diagram

Reading
Commands
State name
System status = “ready”
Display msg = “enter cmd”
Display status = steady
State variables

Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input State activities

20
 Negotiating Requirements

• Identify the key stakeholders

21
 Validating Requirements - I
• Is each requirement consistent with the overall objective for the system/product?
• Have all requirements been specified at the proper level of abstraction? That is, do
some requirements provide a level of technical detail that is inappropriate at this
stage?
• Is the requirement really necessary or does it represent an add-on feature that
may not be essential to the objective of the system?
• 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?

22