Chapter 5

 Understanding Requirements
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1
 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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 2
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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 3
Inception
 Identify stakeholders
 “who else do you think I should talk to?”
 Recognize multiple points of view
 Work toward collaboration
 The first questions
 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 slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4
Eliciting Requirements
 meetings are conducted and attended by both software engineers
and customers
 rules for preparation and participation are established
 an agenda is suggested
 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
 the goal is
 to identify the problem
 propose elements of the solution
 negotiate different approaches, and
 specify a preliminary set of solution requirements

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 5
Quality Function Deployment
 Technique to translate the needs of the
customer into technical requirements for
software.
 Normal Requirements – reflects objectives and goals of
system stated during meetings with customer.
 Expected Requirements – implicit and may be so
fundamental that the customer does not explicitly state
them. E.g. human/machine interaction
 Exciting Requirements – features that go beyond the
customer’s expectations and prove to be very satisfying
when present.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6
Quality Function Deployment
 Function deployment determines the “value”
(as perceived by the customer) of each
function required of the system
 Information deployment identifies data objects
and events
 Task deployment examines the behavior of the
system
 Value analysis determines the relative priority
of requirements

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7
Elicitation Work Products
 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)
and the domain constraints that apply to each.
 a set of usage scenarios that provide insight into the use of
the system or product under different operating conditions.
 any prototypes developed to better define requirements.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8
Problems in Requirements
 Anomaly
 Inconsistency
 Incomplete

9
Anomaly
 ambiguity in a requirement.
 When a requirement is anomalous, several interpretations of that
requirement are possible.
 Any anomaly in any of the requirements can lead to the
development of an incorrect system, since an anomalous
requirement can be interpreted in the several ways during
development.

10
Anomalous Req. Examples
 While gathering the requirements for a process control
application, the following requirement was expressed by a certain
stakeholder: When the temperature becomes high, the heater
should be switched off. Please note that words such as “high”,
“low”, “goo d”, “bad” etc. are indications of ambiguous
requirements as these lack quantification and can be subjectively
interpreted. If the threshold above which the temperature can be
considered to be high is not specified, then it can be interpreted
differently by different developers.
 Suppose one office clerk described the following requirement:
during the final grade computation, if any student scores a
sufficiently low grade in a semester, then his parents would need
to be informed. This is clearly an ambiguous requirement as it
lacks any well defined criterion as to what can be considered as a
“sufficiently low grade”.

11
Inconsistency
 Two requirements are said to be inconsistent, if one of
the requirements contradicts the other.

 E.g. Consider the following two requirements that were collected

from two different stakeholders in a process control application
development project.
 The furnace should be switched-off when the temperature of the
furnace rises above 500 C.
 When the temperature of the furnace rises above 500 C, the
water shower should be switched-on and the furnace should
remain on.
 The requirements expressed by the two stakeholders are clearly
inconsistent.

12
Inconsistency Req. Example
 suppose one of the clerks gave the following requirement— A
student securing fail grades in three or more subjects must
repeat the courses over an entire semester, and he cannot credit
any other courses while repeating the courses.
 Suppose another clerk expressed the following requirement—
there is no provision for any student to repeat a semester; the
student should clear the subject by taking it as an extra subject
in any later semester.
 There is a clear inconsistency between the requirements given by
the two stakeholders.

13
Incomplete
 An incomplete set of requirements is one in which some
requirements have been overlooked. The lack of these features
would be felt by the customer much later, possibly while using
the software.
 Often, incompleteness is caused by the inability of the customer
to visualize the system that is to be developed and to anticipate
all the features that would be required.
 An experienced analyst can detect most of these missing features
and suggest them to the customer for his consideration and
approval for incorporation in the requirements.

14
Incomplete Req. Examples
 one of the clerks expressed the following—If a student secures a
grade point average (GPA) of less than 6, then the parents of the
student must be intimated about the regrettable performance
through a (postal) letter as well as through e-mail. However, on
an examination of all requirements, it was found that there is no
provision by which either the postal or e-mail address of the
parents of the students can be entered into the system. The
feature that would allow entering the e-mail ids and postal
addresses of the parents of the students was missing, thereby
making the requirements incomplete.
 In a chemical plant automation software, suppose one of the
requirements is that if the internal temperature of the reactor
exceeds 200C then an alarm bell must be sounded. However, on
an examination of all requirements, it was found that there is no
provision for resetting the alarm bell after the temperature has
been brought down in any of the requirements. This is clearly an
incomplete requirement. 15
Software Requirement
Specification
 SRS document is generated as the output of
requirement analysis phase.
 Contains complete description about software
without talking much about implementation
details.
 Defines the scope and boundaries of the
system.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16
Important categories of
users of SRS
 Users, customers and marketing personnel
 Software developers
 Test Engineers
 User Documentation Writers
 Project Managers
 Maintenance Engineers

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17
Characteristics of Good SRS
 Concise
 Structured
 Black Box View
 Traceable
 Response to undesired events
 Verifiable

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 18
Important Categories of
Customer Requirements
 Functional Requirements
 Non-functional Requirements
 Goals of Implementation

19
How to classify?
 Aspects which can be expressed as transformation of some
input data to some output data (i.e., the functions of the
system) should be documented as the functional requirement.
 Any other requirements whose compliance by the developed
system can be verified by inspecting the system are
documented as non- functional requirements.
 Aspects whose compliance by the developed system need not
be verified but are merely included as suggestions to the
developers are documented as goals of the implementation.

20
Identifying Functional
Requirements
 Identify the high-level functions of the systems by reading the
informal documentation of the gathered requirements.
 The high-level functions would be split into smaller sub
requirements.
 A high-level function is one using which the user can get some
useful piece of work done.
 Each high-level requirement typically involves accepting some
data from the user through a user interface, transforming it to
the required response, and then displaying the system
response in proper format.

21
22
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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 23
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?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 24
Negotiating Requirements
 Identify the key stakeholders
 These are the people who will be involved in the
negotiation
 Determine each of the stakeholders “win
conditions”
 Win conditions are not always obvious
 Negotiate
 Work toward a set of requirements that lead to “win-
win”

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 25
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?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 26
 Validating Requirements - II
 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.
 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 slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 27