The Requirements Process Workshop Presentation

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

The Requirements Process Workshop Presentation

More Related Content

What's hot

Viewers also liked

Similar to The Requirements Process Workshop Presentation

The Requirements Process Workshop Presentation