Effective Project Management:

Traditional, Agile, Extreme

Managing Complexity in
the Face of Uncertainty

Ch04 : How to Scope a Project & Collect

Requirements

Learning Objectives

Tools, templates, and processes

Confirm goals and objectives
Influence client expectations
Define Conditions of Satisfaction
Scoping meeting
Requirements Breakdown Structure
Business process diagramming
Prototyping the solution
Business validation
Revising the Project Overview Statement

Tools, Templates & Processes

Requirements Gathering
Diagramming Business Processes
Prototyping
Validating Business Cases
Requirements Breakdown Structure template
Requirements Traceability Matrix template
Approval to Plan the Project

Client Wants vs Client Needs Dilemma

NEEDS
WANTS

What your client wants may not be what your client needs.
Your job is to make sure that what they want is what they
need and that you will deliver what they need.

Tips on Managing Client Expectations

Make sure you understand what your client

wants/needs/expects; MoSCOW method
Make sure the client understands what you will do
Put yourself in the shoes of your client
Meaningfully involve your client wherever possible
Keep your client informed as requirements evolve
Preparation of a detailed project scope
statement is critical to project success and
builds upon the major deliverables,
assumptions, and constraints that are
documented during project initiation.

Product Analysis

For projects that have a product as a deliverable,

as opposed to a service or result, product
analysis can be an effective tool.
Product analysis includes techniques such as:
product breakdown
systems analysis
requirements analysis
systems engineering
value engineering
value analysis

Project Scoping Process

Planning & Conducting the Project Scoping

Meeting

Deliverables

Conditions of Satisfaction (acceptance criteria)

Requirements Document/List
Requirements Breakdown Structure (RBS)
Best-fit project management life cycle (PMLC)
Revise Project Overview Statement and Conditions of
Satisfaction

What Are Requirements?

A requirement is something the product/project should
do/produce or a quality that it must have.

Different Perspectives on Requirements

Approaches to Requirements Gathering

Facilitated Group Session/Focus Groups

Interviews
Observation
Brainstorming
Idea/mind mapping
Requirements Reuse
Business Process Diagramming
Prototyping
Use Cases
User Stories and Personas

Facilitated Group Session Method

Strengths
1.
2.
3.

Excellent for cross-functional processes

Detailed requirements are documented and verified
immediately
Resolves issues with an impartial facilitator

Risks
1.
2.

Untrained facilitators can lead to negative responses

Time and cost of planning and executing can be high

Table
04-01

Interview Method
Strengths
1.
2.

End-user participation
High-level description of functions and processes provided

Risks
1.
2.
3.

Descriptions may differ from actual detailed activities

Without structure, stakeholders may not know what information to
provide
Real needs ignored if analyst is prejudiced

Table
04-01

Observation Method
Strengths
1.
2.

Specific/complete descriptions of actions provided

Effective when routine activities are difficult to describe

Risks
1.
2.
3.

Documenting and videotaping may be time-consuming,

expensive, and have legal overtones
Confusing/conflicting information must be clarified
Misinterpretation of what is observed

Table
04-01

Requirements Reuse Method

Strengths
1.
2.
3.
4.
5.

Requirements quickly generated/refined

Redundant efforts reduced
Client satisfaction enhanced by previous proof
Quality increase
Reinventing the wheel minimized

Risks
1.
2.
3.

Significant investment to develop archives, maintenance,

and library functions
May violate intellectual rights of previous owner
Similarity may be misunderstood

Table
04-01

Business Process Diagramming

Strengths
1.
2.
3.

Excellent for cross-functional processes

Visual communications
Verification of what is/what is not

Risks
1.
2.
3.

Implementation of improvement is dependent on an

organization open to change
Good facilitation, data gathering, and interpretation
required
Time-consuming
Table
04-01

Prototyping
Strengths
1.
2.
3.
4.
5.
6.

Innovative ideas can be generated

Users clarify what they want
Users identify requirements that may be missed
Client-focused
Early proof of concept
Stimulates thought process

Risks
1.
2.
3.
4.

Client may want to implement prototype

Difficult to know when to stop
Specialized skills required
Absence of documentation

Table
04-01

Use Case Scenarios

Strengths
1.
2.
3.
4.

State of system described before entering the system

Completed scenarios used to describe state of system
Normal flow of event/exceptions revealed
Improved client satisfaction and design.

Risks
1.
2.
3.
4.

Newness has resulted in some inconsistencies

Information may still be missing from scenario
description
Long interaction required
Training expensive
Table
04-01

User Stories and Personas

Strengths:
1. Simple to learn and easy to express
2. Captured in the language of the user
Risks:
1. Focus on functional requirements, may miss
the non-functional.
Example rental car theme:

As a traveler, I can rent a car.

As a traveler, I can get collision insurance on a car
rental policy.
As a traveler, I can request a baby car seat be
inside my car.

Agile Requirements Documentation

Must meet three criteria, namely,

Must be essential (have minimal detail),

Valuable (be needed), and
Timely (done just in time).
Initially, small efforts are performed and requirements are
focused on small, specific capabilities with the customers and
developers teaming to work the interplay of requirements and
capabilities together.
Elements key to the success of agile projects are very short
cycles, substantial customer collaboration from start to finish,
close team work, open and constant communication among
participants.

Agile Requirements Documentation

Product Backlog
The Product Backlog is the manifestation of the
vision and the business case for the product. The
backlog is made up of Product Backlog
Items (PBIs).
PBIs can be anything from market requirements, to
diagrams, to specifications.
The best practice is user stories. Whatever the team
decides on, it is critical to represent the end-user's
perspective.

Requirements Breakdown Structure

The requirements breakdown structure (RBS) is a

hierarchical description of all requirements that must be
present in the solution in order to deliver the business value
expected.
All decomposition levels are not necessary for every
requirement. Some requirements will be more
comprehensive than others, and utilize all levels.
The simplest requirement might be best described using
only a Features list. The decomposition is subjective. There
can be more than one valid decomposition. In the final
analysis, all that is needed is a decomposition that
completely describes each requirement.

Requirements Breakdown Structure

The RBS is an aid in helping decide which strategy is

best for the PMLC Model to be followed, in other
words, the nature of the project as viewed through its
RBS.

It is the best guide you will have to choosing the best

strategy for managing the project.

Requirements Breakdown Structure

The RBS is a tool that can be used to make sure the

project team members have the same understanding
of the solution to be delivered.

The client is in their comfort zone, and they can

participate in assuring that common understanding too.

Building the Requirements Breakdown Structure

Figure
04-03

Characteristics of the RBS

The RBS is intuitive and most meaningful to the

client
The RBS is a deliverables-based approach
The RBS is consistent with the PMI PMBOK
The RBS remains client-facing as long as possible
into the planning exercise

Advantages of using the RBS

Does not require a trained facilitator

Does not require learning one of the contemporary
approaches to requirements gathering
Presents an intuitive approach to gathering requirements
Allows the client to work with the project team in an
environment familiar to them, i.e., to stay in their own
comfort zone
Paints a clear picture of the degree to which the solution
is clearly defined
Provides the input needed to choose the best fit PMLC
model

Requirements Breakdown Structure

Example Epic :
As a news reporter, I need a portable device with multimedia support
so that I can capture news from field and use them in my reports.
Features
Audio
Video

Sub-features
Audio recording
Audio playback
Audio editing
Noise cancellation

User story (for audio editing)

As a device user, I want to edit the audio recordings and store them,
so that I can upload them to newsroom database.

Requirements Breakdown Structure

Portable Device to Capture News

Audio

Video

Audio Recording

----

Video Recoding

Audio Playback

----

Video Playback

Noise Cancellation

----

Video Editing

Audio Editing

----

Edit

Edit

Verifying Requirements Attributes

Completeness Are the requirements essentially

complete or are some missing?
Clarity Are the requirements clear? Are they
ambiguous or imprecise?
Validity Do the requirements reflect client intentions?
Measurability Does the requirement have a fit
criterion (measurement)?
Testability Can the criterion be used to test whether
the requirement provides the solution?

Verifying Attributes (continued)

Maintainability Will the implementation be difficult or

easy to understand or maintain?
Reliability Can the reliability and availability
requirements be met?
Look and Feel Have all human factors been met
(GUI, ergonomics, etc.)?
Feasibility Can the requirements be implemented?
Precedent Has a requirement similar to this been
implemented before?

Verifying Attributes (continued)

Scale Are the requirements large and/or complex?

Stability How often and to what degree might the
requirements change?
Performance Can the performance be met on a
consistent basis?
Safety Can the safety requirements be fully
demonstrated?
Specifications Is the documentation adequate to
design, implement, and test the system?

The Challenge of Requirements Management

Not always obvious

Come from many sources
Not always easy to express clearly in words
Many different types of requirements at different levels
of detail
Number of requirements can become unmanageable if
not controlled
Requirements are not independent and may create
conflict situations
Many interested and responsible parties
Change as a result of changing business conditions
Can be time-sensitive

How to get requirements gathering started

Sometimes the client has trouble envisioning
a solution or senior management is not
convinced that this project makes business sense.
If so, then consider:

Brainstorming
Diagramming business processes
Prototyping
Business case validation

Categories of Requirements

Functional
Non-functional
Global
Product/project constraints

Definition: Functional Requirement

Functional requirements specify what the product or
service must do.

Give an example of a functional requirement.

Definition: Non-Functional Requirement

Non-functional requirements demonstrate properties
that the product or service should have in order to do
what must be done.

Give an example of a non-functional requirement.

Definition: Global Requirement

Global requirements describe the highest level of
requirements within the system or product. They can be
thought of as general requirements.

Give an example of a global requirement.

Definition: Product/Project Constraints

Product/project constraints are those requirements that,
on the surface, resemble design constraints or project
constraints.

Give an example of a product/project constraint.

Evolution of Requirements

Requirements may start out at a high level and

become progressively more detailed as more about the
requirements is known.

Ongoing meetings and methods may be needed to

capture just the right detail.

Tracking the maturity level of requirements can be

very helpful.

Establishing Conditions of Satisfaction

Clarify
Request
Response

Request
Agree on
Response

Negotiate agreement and

Revise the Project Overview Statement

Figure
04-02

Requirements Traceability Matrix (RTM)

An RTM is a grid that links product requirements
from their origin to the deliverables that satisfy
them.
helps ensure that each requirement adds
business value by linking it to the business and
project objectives
provides a means to track requirements
throughout the project life cycle, helping to
ensure that requirements approved in the
requirements documentation are delivered at
the end of the project
provides a structure for managing changes to
the product scope

Requirements Traceability Matrix (RTM)

Tracing includes, but is not limited to, tracing
requirements for the following:
Business needs, opportunities, goals, and
objectives;
Project objectives;
Project scope/WBS deliverables;
Product design;
Product development;
Test strategy and test scenarios
High-level requirements to more detailed
requirements.

Summary

Tools, templates, and processes

Confirming goals and objectives
Influencing client expectations
Requirements Breakdown Structure
Business process diagramming
Agile requirements
Prototyping the solution
Business validation
Requirements Traceability Matrix
Revising the Project Overview Statement