The Requirements Process
PMI Tools & Techniques Forum
Ivars K. Lenss, PMP
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
Agenda
Introductions
Definition of Requirements
Requirements Planning
Requirements Elicitation
Process Modeling
Q&A
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
Benefits of Good Requirements
Common understanding
Collaborative relationships
Commitment of team members
Products support stakeholder needs
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
Raw Requirements
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
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)
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
Well-Formed Requirements
Abstract: Independent of its implementation
Unambiguous: Interpreted in only one way
Traceable: Associated with source
Validateable: Fit criteria
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)
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
Example
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
Raw Requirement: “The traffic monitor running in the
background shall provide status messages at
regular intervals not less than every minute.”
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
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
PMI Tools & Techniques Forum
January 14, 2009
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
Planning Considerations
Number of stakeholders
Locations of stakeholders
Sources of domain knowledge
Organizational culture
Documentation requirements
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
Requirements Life Cycle
REQUIREMENTS
Process
Modeling
Target
Environment
Stakeholder
Goals, Needs,
and Objectives
Requirements
DefinitionMODELS
Product
Design
REQUIR
EM
ENTS
SPECIF
ICATIO
N
MO
DE
LS
DESIG
N
FEEDBACK
Product
BuildDESIGN
SPECIFICATION
Product
Release
PRODUCT
RELEASE
FEEDBACK
PRODUCT
BUILD
FEEDBACK
Source: Robertson & Robertson, Mastering the Requirements Process
Requirements Elicitation
PMI Tools & Techniques Forum
January 14, 2009
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
Requirements Elicitation
Used to build analytical models
Exposes missing, incomplete, or incorrect
requirements
Determines if additional iterations required
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
REQUIREMENTS
INTERVIEWS
REQUIREMENTS
WORKSHOPS
BRAINSTORMING/
FOCUS GROUPS
PROTOTYPING
DOCUMENT
ANALYSIS
INTERFACE
ANALYSIS
REVERSE
ENGINEERING
OBSERVATION/
SHADOWING
SURVEY/
QUESTIONNAIRE
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Requirements Modeling
PMI Tools & Techniques Forum
January 14, 2009
Ivars K. Lenss, PMP
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Tools & Techniques Forum
January 14, 2009 [email protected]
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
Further Reading