Understanding

Requirements

1
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 2
copyright 2009 by Roger Pressman.
Understanding Requirements
• Requirements engineering helps software engineers better
understand the problems they are trying to solve.
• Building an elegant computer solution that ignores the customer’s
needs helps no one.
• It is very important to understand the customer’s wants and needs
before you begin designing or building a computer-based solution.
Requirements Engineering
• Must be adapted to the needs of a specific process, project, product,
or people doing the work.
• Begins during the software engineering communication activity and
continues into the modeling activity.
• In some cases requirements engineering may be abbreviated, but it is
never abandoned.
• It is essential that the software engineering team understand the
requirements of a problem before the team tries to solve the
problem.
Requirements Engineering-Tasks

Inception • establish the groundwork

Elicitation • elicit requirements from all stakeholders

• create an analysis model that identifies data, function and

Elaboration behavioral requirements
• agree on a deliverable system that is realistic for
Negotiation developers and customers

Specification • documents

Validation • a review mechanism

Requirements • identify, control, and track requirements and changes as

management project proceeds

5
Establish the Ground work
• 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?

6
The next set of questions
• enable developer to better understand the problem and the
customer’s perceptions of the solution
• How would you characterize good output form a successful solution?
• What problem(s) will this solution address?
• Can you describe the business environment in which the solution will
be used?
• Will special performance constraints affect the way the solution os
approached?

7
The final set of questions focuses on
• The final set of questions focuses on communication effectiveness
• Are you the best person to give “official” answers to these questions?
• Are my questions relevant to your problem?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?

8
Eliciting Requirements

• Goal is to identify the problem, propose solution elements, negotiate

approaches, and specify preliminary set of solutions requirements
1. Collaborative requirements gathering

2. Quality function deployment

3. Usage scenarios

4. Elicitation work product

9
1. Collaborative requirements gathering guidelines

• Meetings attended by both developers and customers

• Rules for preparation and participation are established

• Flexible agenda is used

• Facilitator controls the meeting

• Definition mechanism (e.g. stickers, flip sheets, electronic bulletin board) used to
gauge group consensus

10
2. Quality function deployment (QFD)
• Quality function deployment (QFD) is a quality management technique that
translates the needs of the customer into technical requirements for software
• QFD identifies three types of requirements
• Normal requirements. The objectives and goals that are stated for a product or system
during meetings with the customer
• Expected requirements. These requirements are implicit to the product or system and
may be so fundamental that the customer does not explicitly state them.
• Exciting requirements. These features go beyond the customer’s expectations and prove
to be very satisfying when present

11
3.Usage Scenarios

• Usage Scenarios
• To 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

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

13
 Software Requirement specification

ww.processimpact.com/process_assets/srs_preview.pdf
Use-Cases
• Use-cases are a scenario based technique in the UML which
identify the actors in an interaction and which describe the
interaction itself.

• 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.
• Each scenario is described from the point-of-view of an
“actor”

15
Questions
• 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

16