Chapter 5

■ Understanding Requirements

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
■ The broad spectrum of task and techniques that lead to an understanding of
requirements is called requirement engineering
■ Requirement 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 during transformation into operational system.
■ It encompasses seven distinct tasks : Inception, Elicitation, elaboration ,
negotiation , specifications, validations and management.
■ Some of these task occurs parallel and all are important for project

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-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 (obtain) requirements from all stakeholders
■ Elicitation is not simple it faces following problems
• Problem of scope
• Problem of understanding
• Problem of volatility
■ 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. 3
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. 4
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. 5
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. 6
Eliciting 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
Quality Function Deployment
■ Function deployment determines the “value” (as
perceived by the customer) of each function
required for 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. 8
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. 9
Building the Analysis Model

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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13