CCBA Requirements Lifecycle Management 1 — Questions and Answers
Question 1: What does 'requirements traceability' enable a business analyst to do?
- Track the time spent on each requirement
- Link requirements to their origins and downstream deliverables to assess impact and ensure completeness (Correct answer)
- Assign requirements to specific developers
- Convert requirements into user stories automatically
Correct answer: Link requirements to their origins and downstream deliverables to assess impact and ensure completeness
Requirements traceability links each requirement to its source (business goal, regulation, stakeholder need) and to downstream deliverables (design, test cases, code), enabling impact analysis and completeness verification.
Requirements traceability maintains explicit relationships between requirements and their sources, as well as downstream work products. This allows business analysts to assess the impact of proposed changes (which designs, tests, and code will be affected), verify that all requirements have been implemented and tested, and demonstrate that the solution addresses its stated business objectives.
Question 2: In requirements lifecycle management, what is the purpose of 'baselining' a set of requirements?
- To permanently freeze requirements so no changes can be made
- To establish an agreed-upon snapshot of requirements at a point in time, enabling change control (Correct answer)
- To archive requirements that are no longer relevant
- To convert requirements into a legal contract
Correct answer: To establish an agreed-upon snapshot of requirements at a point in time, enabling change control
Baselining establishes an agreed-upon version of requirements at a specific point in time, providing a reference point for change control without permanently preventing change.
A requirements baseline is an approved, agreed-upon snapshot of requirements at a specific point in the project lifecycle. Changes after baselining go through formal change control processes. Baselining doesn't prevent change — it ensures that changes are formally evaluated, approved, and tracked, maintaining traceability and allowing the team to measure scope against the original agreement.
Question 3: Which of the following BEST describes a 'requirements attribute' in requirements lifecycle management?
- A characteristic or property assigned to a requirement to aid in management and tracking (Correct answer)
- A functional behavior that the solution must exhibit
- A measurement of the complexity of the requirement
- A type of business rule governing the requirement
Correct answer: A characteristic or property assigned to a requirement to aid in management and tracking
Requirements attributes are properties assigned to requirements (such as priority, source, status, risk, owner) that support management, prioritization, and tracking activities.
Requirements attributes are metadata associated with each requirement to facilitate management. Common attributes include: priority (MoSCoW, 1-5 scale), source (stakeholder or regulation), status (proposed, approved, deferred, deleted), acceptance criteria, complexity, risk, and owner. These attributes enable the business analyst to sort, filter, prioritize, and track requirements throughout the lifecycle.
Question 4: What is the recommended approach when a stakeholder requests a change to an approved requirement?
- Implement the change immediately to maintain the relationship with the stakeholder
- Evaluate the impact of the change on scope, schedule, and cost before approving it (Correct answer)
- Reject the change to protect the original scope
- Allow only the project manager to evaluate change requests
Correct answer: Evaluate the impact of the change on scope, schedule, and cost before approving it
All changes to approved requirements should be evaluated for their impact on scope, schedule, cost, quality, and risk before a decision is made — this is the purpose of formal change control.
When a stakeholder requests a change to an approved requirement, the business analyst should conduct a change impact assessment, examining effects on other requirements (dependencies, conflicts), design, testing, schedule, budget, and risk. The documented impact is presented to the appropriate approvers for an informed decision. This ensures changes are neither blindly accepted nor reflexively rejected.
Question 5: What is the difference between 'requirements deferral' and 'requirements deletion'?
- Deferral means the requirement is postponed to a future release; deletion means it is permanently removed from scope (Correct answer)
- Deferral requires stakeholder approval; deletion does not
- Deletion is only possible before baselining; deferral can happen at any time
- There is no meaningful difference — both remove the requirement from the current scope
Correct answer: Deferral means the requirement is postponed to a future release; deletion means it is permanently removed from scope
Deferral postpones a requirement to a later release or project phase while keeping it in the backlog, whereas deletion removes the requirement entirely from current and future scope.
Requirements deferral means the requirement will not be addressed in the current scope or iteration but is retained for consideration in a future release. Requirements deletion means the requirement has been determined to be unnecessary, out of scope, or superseded, and is permanently removed. Both decisions should be documented, communicated to stakeholders, and tracked in the requirements repository.
Question 6: In agile business analysis, how does requirements lifecycle management differ from traditional approaches?
- Requirements are never formally documented in agile
- Requirements are maintained in a living backlog and evolve iteratively rather than being frozen at a baseline (Correct answer)
- Change control is eliminated entirely in agile
- Only technical requirements are managed; business requirements are ignored
Correct answer: Requirements are maintained in a living backlog and evolve iteratively rather than being frozen at a baseline
In agile approaches, requirements are maintained as a prioritized, evolving backlog that is continuously refined, rather than being frozen at a baseline and controlled through formal change requests.
In agile environments, requirements (typically expressed as user stories) are maintained in a product backlog that is continuously refined through backlog grooming sessions. New requirements are added, existing ones are refined, and priorities are adjusted as learning occurs. This replaces traditional baseline-and-change-control with an expectation of ongoing change, though traceability and impact assessment remain important even in agile contexts.
CCBA Requirements Lifecycle Management 1
What does 'requirements traceability' enable a business analyst to do?