The document discusses the requirements process. It defines requirements, explains how requirements are developed and elicited from stakeholders, and how they are modeled. The key steps in the requirements process are requirements planning, elicitation using techniques like interviews and workshops, and modeling requirements using analytical models to express different views. Maintaining good requirements is important as defects found later in the project life cycle are much more costly to fix.
2. 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
3. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
4. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
5. Benefits of Good Requirements
Common understanding
Collaborative relationships
Commitment of team members
Products support stakeholder needs
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
6. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
7. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
8. Requirement Sources
Business Implementation
Stakeholder Maintainability
User Regulatory
Quality of Service Legal
Performance Safety
Security Request for Proposal
External Systems Derived
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
9. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
10. 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?
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
11. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
12. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
13. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
14. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
15. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
16. 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
18. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
19. Planning Considerations
Number of stakeholders
Locations of stakeholders
Sources of domain knowledge
Organizational culture
Documentation requirements
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
20. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
21. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP Source: Robertson & Robertson, Mastering the Requirements Process
23. Requirements Elicitation
Used to build analytical models
Exposes missing, incomplete, or incorrect
requirements
Determines if additional iterations required
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
24. REQUIREMENTS
WORKSHOPS
INTERVIEWS BRAINSTORMING/
FOCUS GROUPS
SURVEY/
QUESTIONNAIRE REQUIREMENTS PROTOTYPING
OBSERVATION/
SHADOWING DOCUMENT
ANALYSIS
REVERSE INTERFACE
ENGINEERING ANALYSIS
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
25. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
26. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
27. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
28. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
29. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
30. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
31. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
32. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
33. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
35. 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)
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
36. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
37. Model Views
Behavioral Models (processes, tasks, sequences)
Relationship Map
Context Diagram
Stakeholder Classes
Actor Map
Actor Table
Prototype
Process Map
Use Cases
Scenarios
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
38. Writing Requirements
Written for stakeholders
Written for designers
Written using business language
Associated with a fit criterion
Designers can build what the client wants
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
39. 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.
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP
40. 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
Tools & Techniques Forum
January 14, 2009 Ivars@Lenss.us
Ivars K. Lenss, PMP