Requirements Life Cycle Management Flashcards
Requirements Life Cycle Management
The Requirements Life Cycle Management knowledge area describes the tasks
that business analysts perform in order to manage and maintain requirements
and design information from inception to retirement.
What tasks does Requirements Lifecycle Management include?
- Trace Requirements
- Maintain Requirements
- Prioritize Requirements
- Assess Requirements Changes
- Approve Requirements
Trace Requirements
Requirements traceability identifies and documents the lineage of each
requirement, including its backward traceability, its forward traceability, and its
relationship to other requirements. Traceability is used to help ensure that the
the solution conforms to requirements and to assist in scope, change, risk, time, cost,
and communication management.
Trace Requirements - types of relationships
Derive
Depends
Satisfy
Validate
Trace Requirements - types of relationships - Derive
Relationship between two requirements, used when a requirement
is derived from another requirement. This type of relationship is appropriate
to link the requirements on different levels of abstraction. For example, a
solution requirement derived from a business or a stakeholder requirement.
Trace Requirements - types of relationships - Depends
Relationship between two requirements, used when a requirement depends on another requirement.
Trace Requirements - types of relationships - Satisfy
relationship between an implementation element and the requirements it is satisfying. For example, the relationship between a functional requirement and a solution component that is implementing it.
Trace Requirements - types of relationships - Validate
relationship between a requirement and a test case or other element that can determine whether a solution fulfills the requirement.
Trace Requirements - Techniques
Business Rules Analysis
Functional Decomposition
Process Modelling
Scope Modelling
Maintain Requirements - Purpose
The purpose of Maintain Requirements is to retain requirement accuracy and consistency throughout and beyond the change during the entire requirements life cycle, and to support reuse of requirements in other solutions.
Maintain Requirements - Description
A requirement that represents an ongoing need must be maintained to ensure
that it remains valid over time.
In order to maximize the benefits of maintaining and reusing requirements, the
requirements should be:
• consistently represented,
• reviewed and approved for maintenance using a standardized process that
defines proper access rights and ensures quality, and
• easily accessible and understandable.
Maintain Requirements - Techniques
Business Rules Analysis Data Flow Diagrams Data Modelling Document Analysis Functional Decomposition Process Modelling Use Cases and Scenarios User Stories
Prioritize Requirements
Prioritization is the act of ranking requirements to determine their relative
importance to stakeholders. When a requirement is prioritized, it is given greater
or lesser priority. Priority can refer to the relative value of a requirement, or to the
sequence in which it will be implemented. Prioritization is an ongoing process,
with priorities changing as the context changes.
Typical factors that influence prioritization
Benefit Penalty Cost Risk Dependencies Time Sensitivity Stability Regulatory or Policy Compliance
Basis for Prioritization - Benefit
the advantage that accrues to stakeholders as a result of requirement implementation, as measured against the goals and objectives for the change. The benefit provided can refer to a specific functionality, desired quality, or strategic goal or business objective. If there are multiple stakeholders, each group may perceive benefits differently. Conflict resolution and negotiation may be employed to come to consensus on
overall benefit.
Basis for Prioritization - Penalty
Penalty: the consequences that result from not implementing a given
requirement. This includes prioritizing requirements in order to meet
regulatory or policy demands imposed on the organization, which may take
precedence over other stakeholder interests. Penalty may also refer to the
negative consequence of not implementing a requirement that improves
the experience of a customer.
Basis for Prioritization - Cost
Cost: the effort and resources needed to implement the requirement.
Information about cost typically comes from the implementation team or
the vendor. Customers may change the priority of a requirement after
learning the cost. Cost is often used in conjunction with other criteria, such
as cost-benefit analysis.
Basis for Prioritization - Risk
Risk: the chance that the requirement cannot deliver the potential value, or
cannot be met at all. This may include many factors such as the difficulty of
implementing a requirement, or the chance that stakeholders will not
accept a solution component. If there is a risk that the solution is not
technically feasible, the requirement that is most difficult to implement may
be prioritized to the top of the list in order to minimize the resources that
are spent before learning that a proposed solution cannot be delivered. A
proof of concept may be developed to establish that high risk options are
possible.
Basis for Prioritization - Dependencies
Dependencies: relationships between requirements where one
requirement cannot be fulfilled unless the other requirement is fulfilled. In
some situations, it may be possible to achieve efficiencies by implementing
related requirements at the same time. Dependencies may also be external
to the initiative, including but not limited to other teams’ decisions, funding
commitments, and resource availability.
Basis for Prioritization - Time Sensitivity
Time Sensitivity: the ‘best before’ date of the requirement, after which
the implementation of the requirement loses significant value. This includes
time-to-market scenarios, in which the benefit derived will be exponentially
greater if the functionality is delivered ahead of the competition. It can also
refer to seasonal functionality that only has value at a specific time of year.
Basis for Prioritization - Stability
Stability: the likelihood that the requirement will change, either because it
requires further analysis or because stakeholders have not reached a
consensus about it. If a requirement is not stable, it may have a lower
priority in order to minimize unanticipated rework and wasted effort.
Regulatory or Policy Compliance
Regulatory or Policy Compliance: requirements that must be
implemented in order to meet regulatory or policy demands imposed on the
organization, which may take precedence over other stakeholder interests.
Assess Requirements Changes
The Assess Requirements Changes task is performed as new needs or possible
solutions are identified. These may or may not align to the change strategy and/
or solution scope. Assessment must be performed to determine whether a
proposed change will increase the value of the solution, and if so, what action
should be taken.
Assess Requirements Changes - elements
Assessment Formality
Impact Analysis
Impact Resolution
Approve Requirements
Business analysts are responsible for ensuring clear communication of
requirements, designs, and other business analysis information to the key
stakeholders responsible for approving that information.
Approval of requirements and designs may be formal or informal. Predictive
approaches typically perform approvals at the end of the phase or during planned
change control meetings.
