Please enable JavaScript.
Coggle requires JavaScript to display documents.
Requirement Life Cycle Management - Coggle Diagram
Requirement Life Cycle Management
Overview
Scope of requirements lifecycle management:
1) Trace requirements
2) Maintain requirements
3) Prioritise requirements
4) Assess requirements changes
5) Approve requirements
Inception
: Business need is represented as a requirement and brought forward for consideration
Retirement:
the solution is retired
1) Trace Requirement
BABOK 5.1
How do we do it?
Identify the types of relationships between the requirements that you need to capture
Take into account the level of formality
Think about how you will use this data
Use your requirements architecture
Examples
Process traceability
Tasks -> Activities -> Subprocess -> Process -> Value Chain (Marketing - Sales - Order - Full payment)
Software traceability
Need -> Business requirement -> Stakeholder requirement -> Solution requirement -> Design -> Backlog item -> Test case -> Commit -> Test execution
Key output:
●
Requirements (traced)
: have clearly defined relationships to other requirements, solution components, or releases, phases, or iterations, within a solution scope, such that coverage and the effects of change are clearly identifiable.
●
Designs (traced)
: clearly defined relationships to other requirements, solution components, or releases, phases, or iterations, within a solution scope, such that coverage and the effects of change are clearly identifiable
2) Maintain requirements
BABOK 5.2
What do we maintain?
Requirements
Attributes
Relationships
Key outputs:
- Requirements (maintained)
: defined once and available for long-term usage by the organization. They may become organizational process assets or be used in future initiatives. In some cases, a requirement that was not approved or implemented may be maintained for a possible future initiative.
- Designs (maintained)
: may be reusable once defined. For example, as a self contained component that can be made available for possible future use.
3) Prioritise Requirements
Prioritisation is the act of ranking requirements to determine their relative importance to stakeholders.
BABOK 5.3
Basis for prioritisation
You need to agree with your stakeholders what the basis for prioritisation is:
❖ Benefits. ❖ Penalty. ❖ Cost. ❖ Risk. ❖ Time sensitivity.
❖ Stability. ❖ Compliance. ❖ Dependencies
Key outputs
● Requirements (prioritized)
: prioritized or ranked requirements are available for additional work, ensuring that the highest valued requirements are addressed first.
● Designs (prioritized)
: prioritized or ranked designs are available for additional work, ensuring that the highest valued designs are addressed first
Technique: Prioritisation
Prioritization provides a framework for business analysts to facilitate stakeholder decisions and to understand the relative importance of business analysis information
Define frameworks: IEC = (Impact + Confidence + Ease) / 3
Technique: Backlog Management
The backlog is used to record, track, and prioritize remaining work items
Platform: rija
Items in the backlog:
An item is added to the backlog if it has value to a stakeholder.
A backlog may contain, but is not limited to, any combination of the following items:
❖ use cases. ❖ user stories. ❖ functional requirements. ❖ NFRs. ❖ designs. ❖ customer orders. ❖ risk items. ❖ change requests ❖ defects. ❖ planned rework ❖ maintenance. ❖ conducting a presentation. ❖ completing a document
4) Assess Requirements Changes
BABOK 5.4
Definition
The degree to which your organisation prefers to adapt to, or predict changes will define the procedures for managing change and the level of formality required.
There are two extremes:
❖ Predictive paradigm
❖ Adaptive paradigm
and an endless variety of approaches in between
When the change happens:
Understand <-> Assess <-> Update
Impact analysis
Impact analysis is performed to assess or evaluate the effect of a change.
What to consider:
❖ Benefit. ❖ Cost. ❖ Impact. ❖ Schedule. ❖ Urgency
Impact resolution
All impacts and resolutions resulting from the change analysis are to be documented and communicated to all stakeholders.
Types of resolutions:
❖ Approve. ❖ Deny. ❖ Defer
Key Outputs:
●
Requirements Change Assessment:
the recommendation to approve, modify, or deny a proposed change to requirements.
● Designs Change Assessment:
the recommendation to approve, modify, or deny a proposed change to one or more design components
Technique: Item tracking
Item tracking is used to capture and assign responsibility for issues and stakeholder concerns that pose an impact to the solution
BABOK 10.26
DRAID log
Item tracking tracks the item from the initial recording of the concern and its degree of impact to its agreed-upon closure
❖ Decisions. ❖ Risks. ❖ Assumptions.
❖ Issues. ❖ Dependencies
What to track?
Each recorded item may contain all or any of the following attributes for item tracking.
Usually you would use some software package to manage it.
❖ Summary. ❖ Resolution date. ❖ Category. ❖ Owner
❖ Type. ❖ Resolver. ❖ Date. ❖ Strategy. ❖ Identified by
❖ Status. ❖ Impact. ❖ Updates. ❖ Priority. ❖ Escalation
5) Approval Requirements
Understand Stakeholder Roles
According to the defined approval process
Conflict and Issue management
Stakeholder groups frequently have varying points of view and conflicting priorities.
Gain consensus
Business analysts facilitate this approval process by addressing any questions or providing additional information when requested.
Track and Communicate Approval
The business analyst records approval decisions and communicates the status of requirements and designs.
Key outputs
● Requirements (approved)
: requirements which are agreed to by stakeholders and are ready for use in subsequent business analysis efforts.
● Designs (approved):
designs which are agreed to by stakeholders and are ready for use in subsequent business analysis or solution development efforts.