Finance Roadmap

1
Successfully Defining and Managing Requirements
A cost-effective and time-effective method to the
requirements definition process that eliminates
rework due to bad requirements.
Rick Pellegrino, PMPAugust 15, 2007
2
The Need for Good Requirements
Our failure to understand and document
requirements correctlythe first timeis the most
common source of projects that are late, over
budget and of poor quality.
3
Defining Managing Requirements
Based on your experiences to date

• What is your overall view of requirements
  gathering efforts (process and results)?

• Good experience or bad experience?
• Time-effective and cost-effective?
• Challenged with rework or scope creep?

2. What causes challenged requirements?
4
Common Requirements Challenges

• Poor planning for requirements definition
• Ineffective requirements definition techniques
• Missed requirements
• Requirements that dont meet expectations
• Non-value added requirements
• Constant changing requirements
• Too much rework
• Frustrated project teams (including end-users)

5
Domain of Requirements Definition
Traditional view to gathering requirements
Reserve large room
Conduct joint effort (JAD)
Invite everyone
Laundry list of nebulous statements
Create lots of good discussion
Process modeling
Brainstorming with post-it notes
Document what we hear (requirements)
Reinforce with detail specs
6
Now What?
7
Requirements Challenge
The seven sins that lead to bad requirements.
8
Requirements Challenge
Sin 1
Some projects attempt to define requirements and
project scope at the same time.
Bottom line Attempting to define requirements
without a clear scope statement is a waste of
time.
9
Requirements Challenge
Sin 2
We employ one requirements elicitation technique
only to gather and construct requirements.
Bottom line One size shoe fits none. One method
will not satisfy requirements definition needs
for all projects.
10
Requirements Challenge
Sin 3
Business requirements and product requirements
are not synonymous.
Bottom line Too many project teams attempt to
design and build something that is unclear and
vague.
11
Requirements Challenge
Sin 4
Project stakeholder expectations can be numerous.
E.g.,

• Project sponsor
• Project manager

• End-users
• Business Analyst

Bottom line Expectations need to be prioritized.
Satisfying business expectations is paramount.
12
Requirements Challenge
Sin 5
Project success requires collaborative effort.
Project manager focus is on PMM ? to complete a
project on-time, within budget.
Business analyst focus is on SDLC ? to complete a
project that meets customer expectations.
Bottom line Needs to be collaborative effort
with clearly defined roles and responsibilities.
13
Requirements is a Collaborative Effort
Project Constraints (intersection point)

• Project scope

• Project timelines

PMM Change Control System

• Project budget

• Project resource plan

Project Deliverables
Product Deliverables

• BRD

• Work breakdown structure

• Product breakdown structure

• Project schedule

• Computerized solutions

• Change management plan

ProductDeliverables
ProjectDeliverables

• Resource management plan

• Manual processes

• Test cases and procedures

• Communications plan

• Training

• Risk management plan

------------------- Project Management Phases
-------------------
ProjectManager
Startup
Planning
Execution Control
Closing
Business requirementsdocument (BRD)
Computerized solutionsManual processes
Test casesProcedures
Installation
Business case
BusinessAnalyst
Analysis
Design
Build or Create
Test or Verify
Implement
-------- Product Development Phases --------
14
Requirements Challenge
Sin 6
Thou shall not construct before its time.
Requirements definition begins in project
Planning phase, not in Execution Control.
Resist the urge to produce before a clear
understanding of the product requirements.
Bottom lineThe ready, fire, aim approach
leads to rework.Blind optimism leads to poor
results.
15
Requirements Challenge
Sin 7
Never enough time to do it right the first time,
but always enough time to do it over.
Bottom line The cost of rework approaches 50 on
large software projects, and 80 percent of all
product defects are inserted in the requirement
definition stage of product development.
1
2
1 Barry Boehm, software cost estimation model
2 Bell Labs and IBM studies
16
Defining Managing Requirements
Focus of tonights presentation
A practical approach to defining requirements
intended to eliminate scope creep and rework.

• Identify some key learning and takeaways.
• If your current processes dont include these
  steps, you need to evaluate why you are not doing
  them.
• Not enough time tonight to help you implement
  them.
• Additional sources for reference.
• Reinforce with an example.

17
Requirements Definition Process Flow
2RequirementsElicitation
1RequirementsPlanning
3RequirementsDocumentation
6RequirementsApproval
4RequirementsReview
5RequirementsPrioritization
18
Requirements Definition Process Flow
2RequirementsElicitation
Requirements Content Context
1RequirementsPlanning
3RequirementsDocumentation
Individually Collectively
6RequirementsApproval
4RequirementsReview
Scoring requirements
5RequirementsPrioritization
19
Requirements Definition Process Flow
2RequirementsElicitation
1RequirementsPlanning
3RequirementsDocumentation
6RequirementsApproval
4RequirementsReview
5RequirementsPrioritization
20
1. Requirements Planning
The need for a requirements work plan
Any endeavor where the outcome is important is
best achieved by planning, then using an orderly
process.
Requirements planning is critical for
successfully defining requirements.

• Blind optimism does not work.
• Neither does the ready, FIRE, aim approach.

21
1. Requirements Planning
Requirements Work Plan
Provides guidance (planned process) on how
requirements will be

• Defined
• Documented
• Verified for acceptance
• Managed and controlled by the project team.

22
1. Requirements Planning
Requirements Work Plan
Three major work plan components

• Requirements Identification / Definition Plan

Requirement sources, planned methods techniques

• Requirements Review and Approval Plan

Individually and collectively as a document

• Requirements Management Plan

Activities, Requirements Change Management process
23
Linkage to Effective Requirements
Business Objective
Project Purpose
BusinessRequirement
BusinessRequirement
BusinessRequirement
Product
Product
Product
Product
Product
24
Linkage to Effective Requirements
Business Objective
Project Purpose
BusinessRequirement
BusinessRequirement
BusinessRequirement
Product
Product
Product
Product
Product
25
1. Requirements Planning
Project Purpose
A project that lacks a clearly defined and
well-communicated direction is a recipe for
disaster.

• A project purpose statement aligns all
  stakeholders in a common direction.

• No one can write good requirements without a
  clear understanding of the project purpose.

26
1. Requirements Planning
Project Purpose

• One clear and concise sentence of what the
  project must achieve.
• Defines scope.
• Establishes highest level business function.
• Provides reason / justification for the business
  requirements.

27
1. Requirements Planning
Example of Project Purpose Statement
The purpose of the XYZ project is to convert
tonights meeting room into an educational
training room.
28
Linkage to Effective Requirements
Business Objective
Project Purpose
BusinessRequirement
BusinessRequirement
BusinessRequirement
Product
Product
Product
Product
Product
29
1. Requirements Planning
Understanding Business Objective
Projects are initiated by the organization to
achieve a business objective.
30
The Role of Projects in Organizations
Organizations initiate projects to achieve a
defined business objective that can not be
achieved within its current business processes.
Business Objective
BusinessProcesses
Project
Implementation
Upon successful completion, the project is rolled
into and becomes part of the Organizations
on-going processes.
31
1. Requirements Planning
Understanding Business Objective
A business objective is a measurable statement
about the preferred outcome or change the
business is looking to achieve as a result of a
successfully completed project.
Provides success criteria to evaluate the project
results or to give the project value.
32
1. Requirements Planning
Formulating Business (or project) Objective

• Increase income, productivity, satisfaction
• Decrease costs, risk
• Compliance
• Solve a problem
• Take advantage of an opportunity

33
1. Requirements Planning
Well-written business objective contains three
elements

• Observable, measurable goal (e.g., reduce costs,
  increase revenue or productivity, compliance).
• Level of performance (e.g., 100,000 per year).
• Conditions under which the goal should be
  achieved (e.g., using the XYZ system, by reducing
  customer returns, by 12/31/06).

34
Requirements Definition Process Flow
2RequirementsElicitation
1RequirementsPlanning
3RequirementsDocumentation
6RequirementsApproval
4RequirementsReview
5RequirementsPrioritization
35
2. Requirements Elicitation
Requirements definition is a discovery and
invention process, not just a collection or
gathering process.
Requirements definition is an exploratory
activity, involving multiple communication
techniques.
Elicitation demands iteration. 
36
2. Requirements Elicitation

• Requirement Types

• Requirement Sources

• Requirement Elicitation Techniques

37
2. Requirements Elicitation
Requirement Types

• Business Requirements

Initial set of nebulous statements that address
what the business is looking to create or improve
upon.
38
1. Requirements Planning
Project Purpose Statement
The purpose of the XYZ project is to convert
tonights meeting room into an educational
training room.
Example of Business Requirements

• Ability to create an environment conducive to
  training.
• Ability to stimulate learning experience.
• Create a learning facility befitting the stature
  of a professional instructor.

39
Linkage to Good Requirements
Business Objective
Project Purpose
BusinessRequirement
BusinessRequirement
BusinessRequirement
Product
Product
Product
Product
Product
40
2. Requirements Elicitation
Requirement Types

• Product Requirements

• A precise statement of product need.

Functional Requirement Something that the
product must do. Non-functional requirement A
characteristic the product must have.
41
2. Requirements Elicitation
Non-functional Requirement Types

• Look and feel requirements
• Usability requirements
• Operational requirements
• Performance requirements
• Maintainability requirements
• Security requirements

42
2. Requirements Elicitation

• Requirement Types

• Requirement Sources

• Requirement Elicitation Techniques

43
2. Requirements Elicitation
Requirement Sources

• People Subject matter experts (SME) who
  understand business or product needs well enough
  and are able to share information.

Highly skilled in performing a specialized job,
task or skill within the organization.

• Sr. Management corporate direction, KPIs

• Functional area managers current processes,
  process improvements, policies and procedures

• Departmental associates product functions and
  features

44
2. Requirements Elicitation
Requirement Sources

• Business Processes

• External stimuli that triggers chain of events

• Regulations

• Government-imposed requirements

• Agency regulations (SEC, FDA, FSLIC)

• Industry (or trade) standards

• Organization Established Policies

• Standards, Procedures, SOP

• Corporate and Departmental

45
2. Requirements Elicitation

• Requirement Types

• Requirement Sources

• Requirement Elicitation Techniques

46
Linkage to Good Requirements
Business Objective
Project Purpose
BusinessRequirement
BusinessRequirement
BusinessRequirement
Product
Product
Product
Product
Product
47
2. Requirements Elicitation
Requirement Elicitation Techniques

• Process modeling

• Data modeling

• ERD

• Activity diagrams

• DFD

• Use-cases

48
2. Requirements Elicitation
Requirement Elicitation Techniques (continued)

• Prototyping

• Observation
• Research
• Interviews
• Focus group
• Brainstorming
• Questionnaire survey

• Simulation model

• Mock-up

• Unstructured Structured

49
Requirements Definition Process Flow
2RequirementsElicitation
1RequirementsPlanning
3RequirementsDocumentation
6RequirementsApproval
4RequirementsReview
5RequirementsPrioritization
50
4. Requirements Review
Reviewing the requirements document is a powerful
technique for identifying ambiguous or
unverifiable requirements requirements that
arent defined clearly enough for design to
begin.
51
4. Requirements Review
Review Techniques

• Peer review

• Copyediting and basic proofreading
• Content review
• Structured walkthrough

• Product verification

52
4. Requirements Review
Product Verification
To prevent rework, you must validate requirements
before you produce the product.
Verification enables the requirements team to
interrupt and to visualize a product for
completeness.
53
4. Requirements Review
Product Verification

• Measurable statement about a planned test or
  inspection to confirm that a product will meet
  intended need and expectation.

• Specific and concise so the product requirements
  can be tested against its description.

• Serves as the basis for product acceptance
  criteria.

54
The Cost of Requirement Errors
Relative cost to repair a defect at different
project lifecycle phases
Definition
1
Design
5
Build
10
Unit test
20
Acceptance test
50
Maintenance
200
Standish Group
55
In Summary
Successful requirements definition is not tool
nor technique specific, but is largely driven by
a practical approach and process focused on
understanding the value and link between four key
components

• business objective
• project purpose
• business requirements
• product requirements.

56
Additional Reference Sources
Presentation Material Intro to BA / How to Gather
Document User Requirements, Version 3.0, 2004,
CDI education White Papers Gathering Business
Requirements (Simply and Efficiently), Cecilia
Murphey SMART Requirements, April 1995, Mike
Mannion, Barry Keepence, Software Engineering
Research Group Books Customer Centered
Products, 2001, Ivy F. Hooks, Kristin A.
Farry Effective Requirements Practices, 2001,
Ralph R. Young Mastering the Requirements
Process, 1999, Suzanne Robertson, James
Robertson Software Requirements, second edition,
2003, Karl E. Weigers
57
Successfully Defining and Managing Requirements
The End!