Requirement Gathering

Slide Set - 5
Organized & Presented By:
Software Engineering Team CSED
TIET, Patiala
 Requirements Gathering
( 7 Step Model )
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management
 Inception Task
• During inception, the requirements engineer asks a set of questions to
establish…
– A basic understanding of the problem
– The people who want a solution
– The nature of the solution that is desired
– The effectiveness of preliminary communication and collaboration between the
customer and the developer
• Through these questions, the requirements engineer needs to…
– Identify the stakeholders
– Recognize multiple viewpoints
– Work toward collaboration
– Break the ice and initiate the communication

3
 The First Set of Questions
These questions focus on the customer, other stakeholders, the overall
goals, and the benefits

• 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?

4
 Requirements Gathering
(Elicitation)
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management
 Elicitation Task
• Eliciting requirements is difficult because of
– Problems of scope in identifying the boundaries of the
system or specifying too much technical detail rather than
overall system objectives
– Problems of understanding what is wanted, what the
problem domain is, and what the computing environment
can handle (Information that is believed to be "obvious" is
often omitted)
– Problems of volatility because the requirements change
over time
• Elicitation may be accomplished through two activities
– Collaborative requirements gathering
– Quality function deployment

6
 Eliciting Requirements
Conduct FA ST
m eet ings

Make list s of
f unc t ions, classes

Make list s of
const raint s, et c.

f orm al priorit izat ion?

El i c i t re q u i re m e n t s
yes no

Use QFD t o inf orm ally def ine act ors

priorit ize priorit ize
requirem ent s requirem ent s

draw use-case
writ e scenario
diagram

Creat e Use-cases
com plet e t em plat e

These courseware
materials are to be used in
conjunction with Software
Engineering: A
Practitioner’s Approach,
7
6/e and are provided with
permission by R.S.
 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.
• 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.
 Elicitation Work Products
The work products will vary depending on the system, but should
include one or more of the following items

• 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 (organized by function) and the domain
constraints that apply to each
• A set of preliminary usage scenarios (in the form of use cases) that
provide insight into the use of the system or product under different
operating conditions
• Any prototypes developed to better define requirements

10
 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.
 Use-Case Diagram
Ar ms/ disar ms
syst em

Accesses syst em sensor s

via Int er net

homeow ner

Responds t o
alar m event

Encount er s an
er r or condit ion

syst em Reconf igur es sensor s

and r elat ed
These slides are designed to administ r at or
syst em f eat ur es
accompany Software
Engineering: A Practitioner’s
Approach, 7/e (McGraw-Hill,
2009). Slides copyright 2009
by Roger Pressman.
 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.
 Class Diagram
From the SafeHome system …

Sensor

name/id
type
location
area
characteristics

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

Reading
Command
State name
s
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

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

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management
 Elaboration Task
• During elaboration, the software engineer takes the information
obtained during inception and elicitation and begins to expand and
refine it
• Elaboration focuses on developing a refined technical model of
software functions, features, and constraints
• It is an analysis modeling task
– Use cases are developed
– Domain classes are identified along with their attributes and relationships
– State machine diagrams are used to capture the life on an object
• The end result is an analysis model that defines the functional,
informational, and behavioral domains of the problem

17
 Requirements Gathering
(Negotiation)
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management
 Negotiation Task
• During negotiation, the software engineer reconciles the conflicts
between what the customer wants and what can be achieved given
limited business resources
• Requirements are ranked (i.e., prioritized) by the customers, users,
and other stakeholders
• Risks associated with each requirement are identified and analyzed
• Rough guesses of development effort are made and used to assess
the impact of each requirement on project cost and delivery time
• Using an iterative approach, requirements are eliminated, combined
and/or modified so that each party achieves some measure of
satisfaction

19
 The Art of Negotiation

• Recognize that it is not competition

• Map out a strategy
• Listen actively
• Focus on the other party’s interests
• Don’t let it get personal
• Be creative
• Be ready to commit

20
 Requirements Gathering
(Specification)
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management
 Specification Task
• A specification is the final work product produced by the
requirements engineer
• It is normally in the form of a software requirements specification
• It serves as the foundation for subsequent software engineering
activities
• It describes the function and performance of a computer-based
system and the constraints that will govern its development
• It formalizes the informational, functional, and behavioral
requirements of the proposed software in both a graphical and
textual format

22
 Typical Contents of a Software
Requirements Specification
• Requirements
– Required states and modes
– Software requirements grouped by capabilities (i.e., functions, objects)
– Software external interface requirements
– Software internal interface requirements
– Software internal data requirements
– Other software requirements (safety, security, privacy, environment,
hardware, software, communications, quality, personnel, training, logistics,
etc.)
– Design and implementation constraints
• Qualification provisions to ensure each requirement has been met
– Demonstration, test, analysis, inspection, etc.
• Requirements traceability
– Trace back to the system or subsystem where each requirement applies

23
Requirements Gathering (Validation)
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management
 Validation Task
• During validation, the work products produced as a result of
requirements engineering are assessed for quality
• The specification is examined to ensure that
– all software requirements have been stated unambiguously
– inconsistencies, omissions, and errors have been detected and corrected
– the work products conform to the standards established for the process,
the project, and the product
• The formal technical review serves as the primary requirements
validation mechanism
– Members include software engineers, customers, users, and other
stakeholders

25
 Questions to ask when Validating
Requirements
• 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?

26
 Questions to ask when Validating
Requirements (continued)
• 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?

– Approaches: Demonstration, actual test, analysis, or inspection

• 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?

27
 Requirements Gathering
(Requirement Management)
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management
Requirements Management Task
• During requirements management, the project team performs a set of
activities to identify, control, and track requirements and changes to
the requirements at any time as the project proceeds

• Each requirement is assigned a unique identifier

• The requirements are then placed into one or more traceability tables

• These tables may be stored in a database that relate features,

sources, dependencies, subsystems, and interfaces to the
requirements

• A requirements traceability table is also placed at the end of the

software requirements specification

29