Requirements Management IIBA RD 2008 - 06 - 23

Requirements management
Richard Dickerson
COPYRIGHT © 2008 Richard Dickerson
1 RM definition
2 RM tools and processes
3 Applied methodology
4 Implementing RM
5 Conclusion and questions

1 RM definition
Requirement definition
Requirement types
Requirements relationships
High quality requirements
Definition of a requirement
• A condition or capability needed by a
stakeholder to solve a problem or achieve an
objective.
• A requirement may be unstated, implied by
other requirements, or directly stated and
managed.

Types of requirements
Business
Stakeholder
Solution
Requirements
Functional Implementation
Non-functional
Business
Ref Requirement
FRQ- Decrease the servicing costs of
1456 customer interaction.
Requirements
FRQ- Increase the quality of customer
1457 data.
FRQ- Increase the number of cross-
1458 selling opportunities.

Stakeholder
Ref Requirement
Requirements
FRQ- The call centre agent must be
2032 able to view a list of work that
he/she can perform.
FRQ- The call centre agent must have
2033 access to all customer’s contact
information.
FRQ- An audit of the call centre agent’s
2034 activities must be generated.
Solution
Requirements
Ref Requirement
Y
FRQ- The work lists must be sorted by
2145 priority.
Functional FRQ- The work list must be filtered. It
2234 must only include the items the
call centre agent is allowed to
perform.

Solution
Requirements
Ref Requirement
Y
FRQ- The system should provide 90% of
2145 responses to the user in less than 2
Non-functional seconds.
FRQ- Users must be able to use the
2234 application with 6 hours or less
training.
Solution
Requirements
Ref
Y Requirement
FRQ- Client data must be migrated from
2145 v1.1 to v1.2 of the application.
Implementation FRQ- A role of central administrator
2234 must be created.

Business
Stakeholder
Solution
Requirements
Non-functional
Hierarchy of requirements
Business
Stakeholder
Increasing
Solution level of
granularity
Non-functional

Requirement relationships
Business
SSuttaarkkTee
ehhxootldldeer
r
Non-functional
Requirement trade-offs
PM Perspective
Time
Business requirements
Cost Quality

Requirement trade-offs
Stakeholder Perspective
Usability
Support Operations
Business requirements
Legal Security
Training Audit
Yourmust meet regulatory requirements.
The solution
Business Text
Stakeholder Legal: Transaction history must be stored for 5 years.
S
o
l
u
Non-functional
t
An audit log is i ...
required. o
The audit
n log must be
The audit log must capable of storing 5
store the transaction million records.
amount.

High quality requirements
• Unambiguous
• Unique
• Referenced
• Clear
• Does not prescribe design
• Quantifiable
• Testable
1 RM definition
BABOK description
Requirements management definition

Requirements lifecycle

Based on BABOK V2.0
Business analysis planning and monitoring
Solution
Enterprise Elicitation Requirements assessment
analysis analysis and
v
alidation
Requirements management and communication
Underlying competencies
Based on BABOK v2.0
• Packaging, tracing, managing and

communicating requirements for the
stakeholders and implementers of the project
• Iterative and spans the duration of the project.

Requirement lifecycle
Received
Accepted
Elaborated
Prioritised
Specified
Implemented
Rejected
Requirement lifecycle
Project management process
Received
Accepted
Elaborated Time, cost, effort estimation
Prioritised Deliverables identified, scope
Specified
Implemented
Rejected

Enterprise Solution
analysis assessment
Elicitation Requirements
analysis
Business
Marketing Requirements management

Sales
Analysts
Architects
Customers
Users
Call centre
Legislation
Policy
Project level
Business
Marketing
Requirements management
Sales
Analysts
Architects
Customers
Users
Call centre
Legislation
Policy
Enterprise level
1 RM definition
Version, baseline, release
Meta-data
Traceability

Baselining
Requirement Use case 1 Use case 2 Test case Manual
0.1
0.2 0.1
0.3 0.1 0.2
0.4 0.2 0.3 0.1 0.1
0.5 0.4 0.2
0.6 0.5 0.3
0.7 0.4
Requirement meta-data
• Unique reference
• Acceptance criteria
• Author
• Ownership
• Priority
• Source
• Rationale
• Status
• Cost
Requirements traceability
• "Purpose. Create and maintain
relationships between requirements and
other solution components".
Requirement traceability
Business requirement
Stakeholder requirement Stakeholder requirement
Functional requirement
Non-Functional requirement
Use case
Technical design
Prototype
Requirement traceability
• Impact analysis
• Ensure completeness
• Solution validation
• Assign related to release or baseline
• Determine scope
• Regression testing
• Facilitates change control
1 RM definition
Requirements documentation
Requirements prioritisation
Managing scope
Change management

Requirement documentation
Received
Accepted
Elaborated
Prioritised
Specified
Implemented
Rejected
• Why?
• How?
• How much/What level of detail?

• Why document requirements?
– Enables requirement planning, control,
management.
– Increases efficiency of future
enhancements
– Can be re-used on other
projects
– Provides continuity
(Resource, time)
– Facilitates geographically
dispersed teams
– Assists completeness
checks
– Assists review
• How store requirements?
– Requirement management tools.
– Requirement specifications
– Use case specifications
– Diagrams

• What level of detail?
– "The overriding principle for business
analysis is only to produce requirements
documentation to the extent needed to
ensure the clear understanding by the
team."
– “Analysts need to communicate the
requirements in the format that the
stakeholder will best understand.”
– Detailed stakeholder analysis
required.
– Other benefits may require
additional detail.
RM documentation
"The purpose of war is not battle but victory."
or:
The purpose of analysis is not modelling but
understanding.
Sun Tsu,
The Art of War, ca 500 BC
From: <http://easyweb.easynet.co.uk>

Factor Low High
High complexity
Low team stability
High team maturity
Large project
Low project duration
High access to code
Low requirement stability
High resource dispersion
Low stakeholder availability
Low cultural demand
High product lifespan
High vendor usage
Additional info on documentation
Business analysis planning and monitoring
Solution
v
alidation
Underlying competencies

Requirement prioritisation
Received
Accepted
Elaborated
Prioritised
Specified
Implemented
Rejected
R prioritisation factors
• Business value (Cost, benefit)
• Business or technical risk
• Dependencies
• Likelihood of success
• Resource factors
• Compliance
• Stakeholder agreement

RM prioritisation challenges
• Non-negotiable demands
• Gaming the system
• Unrealistic trade-offs
RM prioritisation methods
• MoSCoW analysis
• Kano analysis
– Threshhold
– Performance
– Excitement
• Time boxing
• Voting

Requirement prioritisation
1
Requirement 1 Priority, cost, category

Requirement 2
Requirement 3
Scope definition
Business requirement Business
requirement
Functional requirement Functional requirement
Non-Functional
requirement
Use case
Technical design
Prototype
Scope definition
1 A
B
Requirement 1
Requirement 2 Release A scope
Use case 1
Requirement 3
Requirements change
"Software is the only engineering discipline in
which the equivalent of changing the wing
on an airplane
constitutes maintenance."
Industrial Proverb, quoted by Jim Highsmith
From: <http://easyweb.easynet.co.uk>

Requirement change
Business requirement
Decreasing
Functional requirement
stability
Non-Functional requirement
Use case
Technical design
Prototype
COPYRIGHT ©
2008 Richard
Dickerson
Requirement change
1 A B
Change requirement 1
Requirement 1
Requirement 2
Release A scope
Use case 1
Requirement 3
New requirement 2
Prioritisation

1 RM definition
Agile vs. Formal

• Is not a one or other decision.
• A continuum is available.
• Choose the correct combination for your
project.
• Retain the project management and
requirement management disciples across
both. They are life-cycle methodology
independent.

Formal methodology
Solution
v
alidation
Received Received Received
Elaborated Elaborated Elaborated
Prioritised Prioritised Prioritised
Specified Specified Specified
Approved Approv Approved Validated
ed
✓ ✓ ✓ ✓
Agile methodology
Solution
v
alidation
ed

Agile vs. Formal
Solution
v
alidation
ed
Agile: Discussion
Agile: Prototypes
Formal: Release management board
Formal: Prototypes, use cases
1 RM definition
4 Implementing RM

How to get people to use RM
• Present the benefits
• Define clear process and methods
• Ensure all aware and understand process
• Ensure all project processes make use of the
RM output.
• Recommend tool
• One storage method
• Simple
• Use statistics
RM Products
• Serena
• TopTeam
• Doors
• Borland
• Rational

RM product selection guidelines
• Versions, baselines and releases.
• Configurable meta-data.
• Configure objects.
• Baselines and releases assigned to
specific versions of objects.
• Configure views.
• Traceability
1 RM definition
4 Implementing RM
5 Conclusion and questions

References:
• Business Analysis Body of
Knowledge® (BABOK®) V2.0

For permission to use material from this text, or any additional questions and permissions, can be submitted
by email to rjdickerson@telkomsa.net.

Requirements Management IIBA RD 2008 - 06 - 23

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirements Management IIBA RD 2008 - 06 - 23

Uploaded by

Copyright:

Available Formats

Requirements management

COPYRIGHT © 2008 Richard Dickerson

2 RM tools and processes

5 Conclusion and questions

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

Stakeholder Legal: Transaction history must be stored for 5 years.

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

Requirements management definition

COPYRIGHT © 2008 Richard Dickerson

Business analysis planning and monitoring

COPYRIGHT © 2008 Richard Dickerson

Based on BABOK v2.0

Requirements management and communication

• Packaging, tracing, managing and

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

Marketing Requirements management

2 RM tools and processes

Version, baseline, release

COPYRIGHT © 2008 Richard Dickerson

Requirement Use case 1 Use case 2 Test case Manual

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

Stakeholder requirement Stakeholder requirement

COPYRIGHT © 2008 Richard Dickerson

2 RM tools and processes

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

Additional info on documentation

Business analysis planning and monitoring

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

Requirement 1 Priority, cost, category

COPYRIGHT © 2008 Richard Dickerson

Functional requirement Functional requirement

COPYRIGHT © 2008 Richard Dickerson

COPYRIGHT © 2008 Richard Dickerson

Stakeholder requirement Stakeholder requirement

COPYRIGHT © 2008 Richard Dickerson

2 RM tools and processes

COPYRIGHT © 2008 Richard Dickerson