BABOK Guide Notes: Chapter 5 - Requirements Life Cycle Management Notes

Overview

  • The Requirements Life Cycle Management (RLCM) knowledge area describes the tasks that business analysts perform to manage and maintain requirements and design information from inception to retirement.
  • Goals:
    • Establish meaningful relationships between related requirements and designs
    • Assess changes to requirements and designs when changes are proposed
    • Analyze and gain consensus on changes
  • Purpose: ensure that business, stakeholder, and solution requirements and designs are aligned, and that the solution implements them.
  • It involves a level of control over requirements and how they will be implemented in the actual solution to be built and delivered.
  • It also helps to ensure that business analysis information is available for future use.
  • The Requirements Life Cycle begins with representing a business need as a requirement, continues through the development of a solution, and ends when a solution and its representing requirements are retired.
  • Management of requirements continues beyond solution implementation; requirements continue to provide value if managed appropriately.
  • Key idea: The life cycle is separate from any particular methodology or process; a life cycle refers to phases or states that requirements pass through as part of any change. Requirements may be in multiple states at once.

Core Concept Model (BACCM) in Requirements Life Cycle Management

  • The Business Analysis Core Concept Model™ (BACCM™) describes the relationships among six core concepts and how they are used in RLCM.
  • Core concepts and their definitions (as used in RLCM):
    • Change: the act of transformation in response to a need; how proposed changes to requirements and designs are evaluated during an initiative.
    • Need: a problem or opportunity to be addressed; trace, prioritize, and maintain requirements to ensure the need is met.
    • Solution: a specific way of satisfying one or more needs in a context; trace requirements and designs to solution components to ensure the solution satisfies the need.
    • Stakeholder: a group or individual with a relationship to the change, the need, or the solution; work closely with key stakeholders to maintain understanding, agreement, and approval of requirements and designs.
    • Value: the worth, importance, or usefulness of something to a stakeholder within a context; maintain requirements for reuse to extend value beyond the current initiative.
    • Context: the circumstances that influence, are influenced by, and provide understanding of the change; analyze the context to support tracing and prioritization activities.
  • The BACCM concepts help guide decisions and activities across Trace, Maintain, Prioritize, Assess Changes, and Approve tasks in RLCM.

Requirements Life Cycle Management: Tasks Overview

  • The RLCM knowledge area includes the following tasks:
    • 5.1 Trace Requirements: analyze and maintain relationships between requirements, designs, solution components, and other work products for impact analysis, coverage, and allocation.
    • 5.2 Maintain Requirements: ensure requirements and designs are accurate and current throughout the life cycle and facilitate reuse where appropriate.
    • 5.3 Prioritize Requirements: assess value, urgency, and risks to ensure the most important requirements are analyzed and delivered first.
    • 5.4 Assess Requirements Changes: evaluate new and changing stakeholder requirements to determine if they should be acted on within the scope of a change.
    • 5.5 Approve Requirements: work with stakeholders to reach approval and agreement on requirements and designs.
  • A diagram (Figure 5.0.1) shows the Input/Output relationships among these tasks, illustrating how outputs from one task become inputs to others (e.g., traced requirements, maintained requirements, etc.).

5.1 Trace Requirements

  • 5.1.1 Purpose
    • To ensure that requirements and designs at different levels are aligned to one another and to manage the effects of change to one level on related requirements.
  • 5.1.2 Description
    • Traceability identifies and documents the lineage of each requirement, including backward traceability, forward traceability, and relationships to other requirements.
    • Traceability helps ensure the solution conforms to requirements and supports scope, change, risk, time, cost, and communication management.
    • It enables faster and simpler impact analysis, more reliable discovery of inconsistencies and gaps, deeper insights into change scope/complexity, and reliable assessment of which requirements have been addressed.
    • Traceability supports requirements allocation and release planning by providing a direct line of sight from requirement to expressed need.
    • Images illustrate: (a) Process traceability, (b) Software requirements traceability.
  • 5.1.3 Inputs
    • Requirements: may be traced to other requirements (including goals, objectives, business requirements, stakeholder requirements, solution requirements, and transition requirements), solution components, visuals, business rules, and other work products.
    • Designs: may be traced to other requirements, solution components, and other work products.
  • 5.1.4 Elements
    • .1 Level of Formality: consider the value of each link, the nature and use of the relationships, and that tracing effort grows with more requirements or higher formality.
    • .2 Relationships: several relationship types to consider when defining the traceability approach, including:
    • Derive: between two requirements (linking different levels of abstraction, e.g., a solution requirement derived from a business or stakeholder requirement).
    • Depends (dependency relationships):
      • Necessity: a requirement makes sense only if a related requirement is also implemented.
      • Effort: easier to implement if a related requirement is also implemented.
      • Satisfy: relationship between an implementation element and the requirement it satisfies.
      • Validate: relationship between a requirement and a test case or other element that can determine whether a solution fulfills the requirement.
  • 5.1.5 Guidelines and Tools
    • Domain Knowledge: business domain expertise to support traceability.
    • Information Management Approach: planning decisions about traceability.
    • Legal/Regulatory Information: regulatory rules that may affect traceability rules.
    • Requirements Management Tools/Repository: storage/management of traceability data.
  • 5.1.6 Techniques
    • Business Rules Analysis, Functional Decomposition, Process Modelling, Scope Modelling.
  • 5.1.7 Stakeholders
    • Customers; Domain Subject Matter Expert; End User; Implementation Subject Matter Expert; Operational Support; Project Manager; Sponsor; Suppliers; Tester.
  • 5.1.8 Outputs
    • Requirements (traced): clearly defined relationships to other requirements, solution components, or releases, such that coverage and change effects are identifiable.
    • Designs (traced): clearly defined relationships to other requirements, solution components, or releases, such that coverage and change effects are identifiable.

5.2 Maintain Requirements

  • 5.2.1 Purpose
    • Retain requirement accuracy and consistency throughout and beyond the change, and support reuse of requirements in other solutions.
  • 5.2.2 Description
    • A requirement representing an ongoing need must remain valid over time.
  • 5.2.3 Inputs
    • Requirements: goals, objectives, business requirements, stakeholder requirements, solution requirements, and transition requirements (these should be maintained throughout their life cycle).
    • Designs: can be maintained throughout their life cycle as needed.
  • 5.2.4 Elements
    • .1 Maintain Requirements: maintain requirements so they remain correct and current after an approved change; maintain relationships among requirements and associated information to preserve context and original intent; ensure they are clearly named/defined and accessible; use taxonomies to assist in establishing/maintaining links.
    • .2 Maintain Attributes: capture and manage attributes such as source, priority, and complexity; attributes may change as analysis progresses.
    • .3 Reusing Requirements: identify candidates for long-term reuse; store them with clear names/definitions to be retrievable; reuse can be within current initiative, within similar initiatives, within similar departments, or organization-wide; high-level requirements are more reusable when not tied to specific tools/structures; stakeholders validate proposed reuse.
  • 5.2.5 Guidelines and Tools
    • Information Management Approach: supports reuse.
  • 5.2.6 Techniques
    • Business Rules Analysis; Data Flow Diagrams; Data Modelling.
  • 5.2.7 Stakeholders
    • Domain Subject Matter Expert; Implementation Subject Matter Expert; Operational Support; Regulator; Tester.
  • 5.2.8 Outputs
    • Requirements (maintained): defined once and available for long-term organizational use.
    • Designs (maintained): may be reusable as self-contained components for future use.

5.3 Prioritize Requirements

  • 5.3.1 Purpose
    • Rank requirements in order of relative importance.
  • 5.3.2 Description
    • Prioritization is the act of ranking requirements to determine their relative importance; ongoing process with changing priorities as context evolves; inter-dependencies may drive prioritization; aims to maximize value.
  • 5.3.3 Inputs
    • Requirements: ready to prioritize (text, matrices, diagrams).
    • Designs: ready to prioritize (text, prototypes, diagrams).
  • 5.3.4 Elements
    • .1 Basis for Prioritization: agreed basis among stakeholders; typical factors include:
    • Benefit: value to stakeholders relative to goals/objectives; multiple stakeholder perspectives; may require negotiation.
    • Penalty: consequences of not implementing a requirement, including regulatory or policy impacts and customer experience impacts.
    • Cost: effort/resources to implement; provided by implementation team/vendor; may be re-evaluated.
    • Risk: likelihood the requirement cannot deliver value or be met; include feasibility and acceptance risk; high-risk items may be prioritized to minimize wasted effort; PoC may be used for high-risk options.
    • Dependencies: relationships where one requirement cannot be fulfilled without another; external dependencies may exist.
    • Time Sensitivity: best-before date; time-to-market considerations; value may increase if delivered early.
    • Stability: likelihood of changes; unstable requirements may be deprioritized to minimize rework.
    • Regulatory/Policy Compliance: statutory/compliance requirements may take precedence.
    • .2 Challenges of Prioritization: value perceptions differ among stakeholders; potential conflicts; stakeholders may try to influence priorities; some requirements may not fit the same criteria.
    • .3 Continual Prioritization: priorities shift as context/evidence evolves; initial prioritization at a high level, then finer-grained prioritization as details are refined; different bases for prioritization may apply at different stages.
  • 5.3.5 Guidelines and Tools
    • Business Constraints; Change Strategy; Domain Knowledge; Governance Approach; Requirements Architecture; Requirements Management Tools/Repository; Solution Scope.
  • 5.3.6 Techniques
    • Backlog Management; Business Cases; Decision Analysis; Estimation; Financial Analysis; Interviews; Item Tracking; Prioritization; Risk Analysis and Management; Workshops.
  • 5.3.7 Stakeholders
    • Customer; End User; Implementation Subject Matter Expert; Project Manager; Regulator; Sponsor.
  • 5.3.8 Outputs
    • Requirements (prioritized): available for additional work; highest value addressed first.
    • Designs (prioritized): available for additional work; highest value addressed first.

5.4 Assess Requirements Changes

  • 5.4.1 Purpose
    • Evaluate the implications of proposed changes to requirements and designs.
  • 5.4.2 Description
    • Assess changes when new needs or possible solutions arise; determine whether proposed changes increase solution value; assess conflicts with other requirements and overall risk; ensure each proposed change can be traced back to a need; consider alignment with strategy, value impact, delivery time/resources, and risks/opportunities/constraints.
    • Results inform decision making and change control per the Plan Business Analysis Governance task.
  • 5.4.3 Inputs
    • Proposed Change: triggers can come from business strategy changes, stakeholder input, legal or regulatory changes, etc.
    • Requirements: may need to be assessed to identify impact of modification.
    • Designs: may need to be assessed for impact.
  • 5.4.4 Elements
    • .1 Assessment Formality: determine formality based on information available, importance, and governance; some changes may be withdrawn or declined; predictive approaches may demand more formal assessment; adaptive approaches favor less formality to minimize disruption.
    • .2 Impact Analysis: performed to assess effect of a change; use traceability to review relationships to other requirements/solution components; related items may require changes; consider:
    • Benefit, Cost, Impact, Schedule, Urgency
  • 5.4.5 Guidelines and Tools
    • Change Strategy; Domain Knowledge; Governance Approach; Legal/Regulatory Information; Requirements Architecture; Solution Scope.
  • 5.4.6 Techniques
    • Business Cases; Business Rules Analysis; Decision Analysis; Document Analysis; Estimation; Financial Analysis; Interface Analysis; Interviews; Item Tracking; Risk Analysis and Management; Workshops.
  • 5.4.7 Stakeholders
    • Customer; Domain Subject Matter Expert; End User; Operational Support; Project Manager; Regulator; Sponsor; Tester.
  • 5.4.8 Outputs
    • Requirements Change Assessment: recommendation to approve/modify/deny proposed change.
    • Designs Change Assessment: recommendation to approve/modify/deny change to design components.

5.5 Approve Requirements

  • 5.5.1 Purpose
    • Obtain agreement and approval of requirements and designs so business analysis work can continue and/or solution construction can proceed.
  • 5.5.2 Description
    • Clear communication of requirements and designs to stakeholders responsible for approvals; approvals can be formal or informal; adaptive approaches may approve only when construction can begin; BA facilitates consensus and communicates outcomes; manage risks if consensus is incomplete.
  • 5.5.3 Inputs
    • Requirements (verified): requirements verified to be of sufficient quality for further specification/development.
    • Designs: designs ready for further specification/development.
  • 5.5.4 Outputs
    • Outputs include: Requirements (approved); Designs (approved).
  • 5.5.5 Guidelines and Tools
    • Change Strategy; Governance Approach; Legal/Regulatory Information; Requirements Management Tools/Repository; Solution Scope.
  • 5.5.6 Techniques
    • Acceptance and Evaluation Criteria; Decision Analysis; Item Tracking; Reviews; Workshops.
  • 5.5.7 Stakeholders
    • Customer; Domain Subject Matter Expert; End User; Operational Support; Project Manager; Regulator; Sponsor; Tester.
  • 5.5.8 Outputs (continued)
    • Final outputs: Requirements (approved) and Designs (approved) ready for subsequent business analysis efforts or solution development.

Additional Notes and Cross-References

  • Figure references:
    • Figure 5.0.1: Requirements Life Cycle Management Input/Output Diagram
    • Figure 5.1.1: Process Traceability
    • Figure 5.1.2: Software Requirements Traceability
    • Figure 5.1.3: Input/Output Diagram for Trace Requirements
    • Figure 5.2.1: Maintain Requirements Input/Output Diagram
    • Figure 5.3.1: Prioritize Requirements Input/Output Diagram
    • Figure 5.4.1: Assess Requirements Changes Input/Output Diagram
    • Figure 5.5.1: Approve Requirements Input/Output Diagram
  • Information flow idea: Outputs from one task serve as inputs to subsequent tasks; e.g., traced/maintained requirements feed into prioritization and change assessment.
  • Relationships and traceability are central to ensuring coverage, change impact analysis, risk management, and alignment with business goals.
  • Reuse and organizational asset considerations: maintained requirements and designs can become organizational process assets and support future initiatives.

Quick Reference: Key Terms and Concepts

  • Traceability: documenting lineage of each requirement, including backward, forward, and relationships to other requirements and work products.
  • Maintain: keep requirements/designs accurate, current, and ready for reuse.
  • Prioritize: rank requirements by value, urgency, risk, and constraints to maximize delivery of high-value items first.
  • Assess Changes: analyze proposed changes for alignment with strategy, impact on value, time/resources, and risk; determine action.
  • Approve: obtain consensus and formal/informal sign-off from stakeholders with authority; track approval status and maintain audit history.
  • Stakeholders: diverse groups including customers, end users, SMEs, testers, regulators, sponsors, project managers, and others who influence or are affected by requirements.
  • Guidelines and Tools: repositories, governance, domain knowledge, regulatory information, and management tools to support RLCM tasks.
  • Techniques: a broad set of methods (e.g., Business Rules Analysis, Process Modelling, Data Modelling, Interviews, Workshops) used across the tasks to perform analyses and produce outputs.

Equations and Models (illustrative)

  • Traceability enables impact analysis, coverage, and allocation through direct linkage from requirements to needs and solutions:
    • Impact Analysis: depends on traceability links {Requirements → Related Requirements, Solution Components, Tests, etc.}
  • Basis for prioritization combines multiple criteria, often needing negotiation across stakeholders:
    • Prioritization score = f(Benefit, Penalty, Cost, Risk, Dependencies, Time Sensitivity, Stability, Regulatory/Policy Compliance)

End of Notes