Requirements Process: Gathering, Planning and Elicitation

The Requirements Process

PMI Tools & Techniques Forum
Ivars K. Lenss, PMP

Agenda

 Introductions
 Definition of Requirements
 Requirements Planning
 Requirements Elicitation
 Process Modeling
 Q&A
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP

What Is a Requirement?

(1) A condition or capability needed by a stakeholder
to solve a problem or achieve an objective.

(2) A condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or other
formally imposed documents.

(3) A documented representation of a condition or
capability as in (1) or (2)
Source: IEEE Std 610.12-1990

Ivars K. Lenss, PMP

How Requirements Work
 Requirements are not solutions
 Design translates requirements into solutions
 Many stakeholders mix requirements with their
proposed solutions

 Requirements gathering is discovering the
essence of the system

 Essence is the business reason of the work -
what the work would be if there was no project

Ivars K. Lenss, PMP

Benefits of Good Requirements

 Common understanding
 Collaborative relationships
 Commitment of team members
 Products support stakeholder needs

Ivars K. Lenss, PMP

Correcting Requirement Defects

Stage of Discovery Relative Cost to Correct

Requirements development 1X

Design 2-3X

Construction 5-10X

System or acceptance test 8-20X

Operation 68-110X

Source: Wiegers More About software requirements

Ivars K. Lenss, PMP

Cost of Requirements Defects

 Requirements defects contribute to
one third of total delivered defects
 Fixing requirements errors consumes
70-80% of project rework costs
 Requirements defects consume 28-42%
of total software development costs
Source: Wiegers Software Requirements

Ivars K. Lenss, PMP

Requirement Sources
 Business  Implementation
 Stakeholder  Maintainability
 User  Regulatory
 Quality of Service  Legal
 Performance  Safety
 Security  Request for Proposal
 External Systems  Derived
Ivars K. Lenss, PMP

Raw Requirements
A raw requirement is an environmental or customer requirement that
has not been analyzed and formulated as a well-formed requirement.
(IEEE Std 1233, 1998 Edition)

 Higher-level statements of the business
goals, objectives, and success factors
 Often expressed in initiating documents
 Often vague and subjectively interpreted
 Can be intermingled with ideas and
suggestions for potential designs
Ivars K. Lenss, PMP

Example
 Requirement: “The traffic monitor running in the
background shall provide status messages at
regular intervals not less than every minute.”

 What are the status messages?
 How are they provided to the user?
 If displayed, how long are they displayed?
 What is the acceptable timing interval?

Ivars K. Lenss, PMP

Business Events

 A system responds to things that happen
externally – these are business events
 Each event has a preplanned response –
This response is a business use case
 A requirement associates a business event
with a business use case

Ivars K. Lenss, PMP

Well-Formed Requirements
A well-formed requirement is a statement of system functionality (a capability)
that can be validated, and that must be possessed by a system to solve a
customer objective, and is qualified by measurable conditions and bounded by
constraints. (IEEE Std 1233, 1998 Edition)

 Abstract: Independent of its implementation
 Unambiguous: Interpreted in only one way
 Traceable: Associated with source
 Validateable: Fit criteria

Ivars K. Lenss, PMP

Example
Raw Requirement: “The traffic monitor running in the
background shall provide status messages at
regular intervals not less than every minute.”

 The traffic monitor shall display status
messages in a designated area of the user
interface
 The messages shall be updated every 60
seconds, plus or minus five seconds
 Messages shall remain visible continuously

Ivars K. Lenss, PMP

Requirements Classification
 Functional Requirements
- Things the product must do
- Action verbs – calculate, produce, inspect, publish

 Nonfunctional Requirements
- Qualities the product must have
- Look and feel, performance, security, regulatory

 Constraints
- Boundaries and limits on the solution.
- Glossary and naming conventions
- Training, knowledge transfer

Ivars K. Lenss, PMP

Examples

 Functional
 The rail system shall move people from San
Francisco to Los Angeles
 Nonfunctional
 The rail system shall operate at an optimal
cruise speed of 100 miles per hour
 Constraint
 The rail system shall operate at a maximum
speed of 130 miles per hour
Ivars K. Lenss, PMP

Requirement Attributes
• Assigned to each well-formed requirement

For example:
<identification> = 4.3.2
<priority> = high
<criticality> = low
<feasibility> = high
<risk> = medium
<source> = customer
<class> = nonfunctional
<type> = performance

Requirements Planning

January 14, 2009

Requirements Planning
 Identify stakeholders and key project team members
 Identify and communicate key roles/responsibilities
to people involved in requirements gathering
 [R]esponsible (does the work)
 [A]ccountable (the decision maker-only one person)
 [C]onsulted (consulted prior to the work, provides
input)
 [I]nformed (on a need to know basis)
 Identify project assumptions
 Determine tools and techniques to gather and
communicate requirements

Ivars K. Lenss, PMP

Planning Considerations

 Number of stakeholders
 Locations of stakeholders
 Sources of domain knowledge
 Organizational culture
 Documentation requirements

Ivars K. Lenss, PMP

Obstacles

 Multiple, conflicting needs from stakeholders
 Stakeholder availability
 Stakeholder knowledge
 Lack of involvement of the right people
 Delivery dates mandated without prioritized
requirements
 Scope creep
 Analysis paralysis

Ivars K. Lenss, PMP

Requirements Life Cycle
Target Stakeholder
Environment Goals, Needs,

PR
O
and Objectives

D
U
C
T
REQUIREMENTS
RELEASE
Process MODELS Requirements FEEDBACK Product
Modeling Definition Release
TI TS
A N
N
IC E
O
IF EM

FE
B DB
MO

U A
EC UIR

E
IL C
DE

D K
SP EQ
LS

R

B N
K
G
C
ED SI
A

T
FE E

C
D

U
D
O
PR
Product
Product Build
Design DESIGN
SPECIFICATION
Ivars K. Lenss, PMP Source: Robertson & Robertson, Mastering the Requirements Process

Requirements Elicitation

January 14, 2009

Requirements Elicitation

 Used to build analytical models
 Exposes missing, incomplete, or incorrect
requirements

 Determines if additional iterations required

Ivars K. Lenss, PMP

REQUIREMENTS
WORKSHOPS

INTERVIEWS BRAINSTORMING/
FOCUS GROUPS

SURVEY/
QUESTIONNAIRE REQUIREMENTS PROTOTYPING

OBSERVATION/
SHADOWING DOCUMENT
ANALYSIS

REVERSE INTERFACE
ENGINEERING ANALYSIS

Ivars K. Lenss, PMP

Interviews
 Solicit stakeholder involvement, authority, impact
 Most common elicitation technique
 Structured interview, pre-defined questions
 Unstructured interview, no pre-defined questions
 Encourages participation and establishes rapport
with the stakeholder
 Results subject to interviewer’s interpretation
 Not a means of reaching consensus

Ivars K. Lenss, PMP

Requirements Workshops
 Structured way to capture requirements (scope,
define, discover, prioritize, and reach closure)
 Also referred to as JAD, Joint Application Design
 Effective way to elicit requirements quickly
 Feedback is immediate
 Stakeholders availability affects scheduling
 Too many participants can slow down the process
 Too few participants can overlook requirements

Ivars K. Lenss, PMP

Brainstorming/Focus Group
 Focuses on a topic or problem area
 Share new ideas without criticism or evaluation
 Create a condensed list of ideas

 Homogeneous—individuals with similar characteristics
 Differing perspectives might not be shared

 Heterogeneous—individuals with diverse backgrounds
 Individuals may self-censor if not comfortable with others’
background

Ivars K. Lenss, PMP

Survey / Questionnaire

 Quick and relatively inexpensive
 Does not usually require significant time
 Efficient when stakeholders are not co-located
 Closed-ended questions:
 Used when issues are known, responses are not
 Effective in obtaining quantitative data
 Open-ended questions:
 Effective in obtaining insights and opinions
 Difficult to quantify and summarize

Ivars K. Lenss, PMP

Prototyping
 Creates “mock ups” of screen or report layouts
 Lets stakeholders “see” the system’s interface
 Horizontal prototype
 Models a shallow and wide view of the system (breadth)
 Vertical prototype
 Models a deep and narrow view of the system (depth)
 Can take considerable time
 Can get bogged down by the “hows” rather than “whats”
 May lead to unrealistic expectations of performance,
reliability, usability

Ivars K. Lenss, PMP

Document Analysis
 Used to gather details of the “As Is” environment
 Leverage existing materials to discover and/or confirm
requirements
 Applied in situations where
 the subject matter experts for the existing systems are no longer
with the organization
 or are not going to be available throughout the duration of the
requirements elicitation process

 Documentation may not be up-to-date
 Can be tedious and time-consuming

Ivars K. Lenss, PMP

Interface Analysis
 Used to identify shared interface requirements
 Interfaces types include:
 User interfaces
 System-to-system interfaces
 Interfaces to and from external hardware devices
 Reveals inputs, outputs, functionality
 Important to look across all interfaces
 Promotes successful interoperability
 Does not reveal business processes

Ivars K. Lenss, PMP

Observation / Shadowing
 Study people performing their jobs
 Assess an SME’s work environment
 Sometimes called "job shadowing” or “following
people around”
 Documents details about a current process
 Could be time-consuming
 May be disruptive

Ivars K. Lenss, PMP

Reverse Engineering
 Existing system has little or outdated documentation
 Helps in understanding what a system actually does
 Black Box:
 Studied without examining its internal structure
 White Box:
 Inner workings of the system/product are studied
 Expensive and time-consuming
 Can be restricted by copyright laws
 Existing tools have limited capabilities and require
training to use

Ivars K. Lenss, PMP

Requirements Modeling

January 14, 2009

Analytical Models
 Express different views of requirements
 Provide perspectives and focus
 Achieve specific levels of detail
 Facilitate communication
 Models can be text, diagrams, or both
 Behavior models (processes, tasks, sequences)
 Structural models (parts and relationships)
 Dynamic models (how things change over time)
 Control models (decisions and policies)

Ivars K. Lenss, PMP

Model Views
 Control Models (guidelines, standards)
 Business Policies
 Business Rules

 Structural Models (parts and relationships)
 Domain Models
 Glossary

 Dynamic Models (changes over time)
 Event Table

Ivars K. Lenss, PMP

Model Views
 Behavioral Models (processes, tasks, sequences)
 Relationship Map
 Context Diagram
 Stakeholder Classes
 Actor Map
 Actor Table
 Prototype
 Process Map
 Use Cases
 Scenarios

Ivars K. Lenss, PMP

Writing Requirements

 Written for stakeholders
 Written for designers
 Written using business language
 Associated with a fit criterion
 Designers can build what the client wants

Ivars K. Lenss, PMP

Establishing Metrics

 Project Metrics – measurements
associated with the project
 Cost, effort, schedule, risk, resources, etc.

 Product Metrics – measurements
associated with the product
 Defects, performance, size, etc.

Ivars K. Lenss, PMP

Further Reading
1. Wiegers, Karl E., Software Requirements , 2nd ed., Microsoft Press, 2003
2. Wiegers Karl, E., More about Software Requirements: Thorny Issues and
Practical Advice, Microsoft Press, 2006
3. Robertson & Robertson, Mastering the Requirements Process, 2nd ed.,
Addison-Wesley, 2006
4. Sward, Measuring the Business Value of Information Technology, Intel
Press, 2006
5. Bridgeland, Zahavi, Business Modeling, A Practical Guide to Realizing
Business Value, Morgan Kaufman, 2009
6. IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System
Requirements Specifications

Ivars K. Lenss, PMP

Requirements Process: Gathering, Planning and Elicitation

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (15)

Similaire à Requirements Process: Gathering, Planning and Elicitation

Similaire à Requirements Process: Gathering, Planning and Elicitation (20)

Requirements Process: Gathering, Planning and Elicitation