From a stated need to an accepted feature
What a stakeholder asks for and what the business needs are related but rarely identical. Elicitation narrows that gap, analysis writes the result in a form someone can build and test, and traceability keeps each requirement tied to where it came from and to how it will be checked.
The recording tools follow the approach. Predictive projects keep a documented requirements set and trace it in an RTM. Adaptive teams hold requirements as user stories in the product backlog and refine them shortly before delivery. Use cases suit flows with several actors and alternate paths; user stories suit small slices of value written from the user’s side.
Process flow diagrams
A process flow diagram, also called a workflow chart, maps the steps, decisions and handoffs of a piece of work, either as it runs today or as it should run after the change. Swimlanes, one lane per role, show where work changes hands, and handoffs are where most delays and misunderstandings sit. In elicitation the diagram gives stakeholders something concrete to correct, which is easier for most of them than describing their job from memory.
- 01 source
- 02 elicited
- 03 traced to design
- 04 verification
- 05 validation
Elicitation techniques at a glance
| Technique | Gives you | Costs you |
|---|---|---|
| Interview | Depth from one person, including the reasoning behind a need | Calendar time; one viewpoint per session |
| Facilitated workshop | Agreement across groups, with conflicts surfaced in the room | Preparation, and a facilitator who keeps it on topic |
| Survey or questionnaire | Breadth at a low cost per respondent | Little depth; the questions have to be right the first time |
| Observation | The task as performed, including steps people forget to mention | Time on site; people may work differently while watched |
| Prototype | Reactions to something concrete | A mockup can be mistaken for a finished product |
| Document analysis | Existing rules, forms, reports and contracts | Documents describe the intended process and may be out of date |
| Focus group | Attitudes of a defined set of users | Group dynamics can drown out quieter voices |
| Lessons learned | What went wrong with similar requirements before | Only as good as the records that were kept |
Traceability and acceptance: what to be able to do
- Plan elicitation before running it: who, which technique, in what order, with what materials.
- Classify requirements as business, stakeholder, solution (functional and nonfunctional) or transition requirements.
- Choose between a user story and a use case for a scenario.
- Say what an RTM links: each requirement back to its source and forward to design, tests and acceptance.
- Separate verification (built to specification) from validation (meets the need).
- Tell acceptance criteria, which belong to one item, from the definition of done, which applies to all of them.
- Decide whether work is ready for delivery from the RTM or the backlog, as task 4.6 puts it.
Cards on this topic
Several cards ask what to do first. The best option is the one the situation needs now, which is not always the most thorough one.
Practice cards here are written for study, not taken from PMI. The real CAPM mixes multiple choice with drag-and-drop, hot spot, comic-strip and video items.
Card 01 of 25 · 0 done · 0 right
To do 25
Doing
Card 01 of 25
A project is preparing for a change control board review and must demonstrate not only how much of each requirement is complete but also why the requirement exists and how it will be verified. Which artifact provides that traceability rather than status tracking alone?
Note on A
A progress log of weekly percentages tracks status only; it does not link a requirement to its source or its verification.
Note on B
A percent-complete dashboard reports status but shows neither why a requirement exists nor how it will be tested.
Note on C
A burnup chart shows how many requirements are delivered over time, not where each came from or how it is verified.
Note on D
Correct: A requirements traceability matrix links each requirement back to its business source and forward to the tests that verify it.
Card 02 of 25
An agile team is building a regulated medical device. Auditors require that every delivered feature be traceable to a regulatory clause and to the evidence proving the feature satisfies it. Which approach best maintains this traceability within the agile way of working?
Note on A
Retrospective notes record lessons about how the team works; they are not a structured audit trail from features to regulations.
Note on B
Correct: Linking each story to its regulatory clause and verification evidence builds traceability into the backlog without abandoning the agile approach.
Note on C
Switching to a predictive life cycle is unnecessary, because traceability can be maintained inside agile practices.
Note on D
Automated tests provide evidence, but without links to regulatory clauses they do not show auditors which requirement each test covers.
Card 03 of 25
During integrated change control, a change that alters the payment feature is approved, but the request omits the response-time threshold that was part of the original nonfunctional acceptance criteria. What is the primary risk of approving the change as written?
Note on A
Not every test needs to be rerun; the problem is that a key performance criterion has gone missing.
Note on B
Correct: Without the response-time threshold, the changed feature has no measurable performance criterion, so its acceptance can no longer be objectively tested.
Note on C
Rebaselining can follow some changes, but it is not the main risk created by a missing acceptance criterion.
Note on D
The change was approved through integrated change control, so it did not bypass the review.
Card 04 of 25
A project manager is leading a predictive, plan-based project. While the Requirements Traceability Matrix (RTM) is maintained as a living artifact during change control, at which specific lifecycle milestone should it first be formally baselined?
Note on A
Baselining at the end of execution is too late to control changes to requirements.
Note on B
At charter approval, requirements are not yet detailed enough to baseline.
Note on C
Closure is far too late; the matrix should already have guided the work.
Note on D
Correct: In a predictive approach, requirements and their traceability are baselined at the end of planning, after which changes go through change control.
Card 05 of 25
During elicitation, the finance manager and the operations manager request conflicting approval rules for the same invoice workflow. What should the business analyst do FIRST?
Note on A
Correct: Understanding each manager’s underlying need often reveals a way to satisfy both, or at least makes the trade-off clear before anyone decides.
Note on B
Recording both conflicting rules as requirements leaves the solution internally inconsistent.
Note on C
Asking someone to choose before the needs are understood risks discarding a real business need.
Note on D
Escalating is premature; the analyst should first understand the conflict and try to resolve it through analysis.
Card 06 of 25
Late in elicitation, a business analyst discovers that the customer support team, never consulted, will rely heavily on the new system. What should the analyst do FIRST?
Note on A
The support team is clearly a stakeholder, so asking whether to include them only delays necessary work.
Note on B
A change request may follow, but first the analyst needs to know what the support team needs and how it affects the solution.
Note on C
Correct: The analyst should elicit the missed group’s needs and assess their impact before deciding how to handle them.
Note on D
Deferring their needs without knowing what they are could leave the system unusable for a group that relies on it.
Card 07 of 25
A business analyst is evaluating a requested scope change to a core application module. They immediately estimate that all fifty downstream test cases and user manuals will require extensive updates, resulting in a high-effort, high-risk recommendation. What critical error did the analyst most likely commit during the impact analysis?
Note on A
Updating the business case is not a prerequisite for finding which artifacts are affected.
Note on B
Risk probability matters, but leaving it out is not what caused the inflated impact estimate.
Note on C
Correct: Impact analysis should follow trace links to find the artifacts actually affected, not assume every downstream item changes.
Note on D
The schedule baseline has nothing to do with how the impact analysis was performed.
Card 08 of 25
A business analyst on a new procurement-system project has identified the stakeholders and reviewed the existing process documents. Before scheduling any interviews or workshops, what should the analyst do NEXT?
Note on A
Requirements cannot be baselined before they have been elicited and analyzed.
Note on B
Writing user stories comes after elicitation, once needs are understood.
Note on C
Correct: After identifying stakeholders and reviewing documents, the analyst plans elicitation, choosing techniques, participants, and timing before holding sessions.
Note on D
Building a prototype is itself an elicitation technique and should be chosen as part of planning, not started first.
Card 09 of 25
A new inventory management system successfully passes all unit, integration, and performance testing phases without generating any errors. However, during the initial pilot deployment at a regional warehouse, warehouse staff are unable to use the system because the workflow requires data they cannot access on the floor. Which of the following best describes the root cause of this failure?
Note on A
Integration testing passed without errors, so the gap is not in how the components connect.
Note on B
Correct: The system meets its specifications but does not fit how users actually work, which is a validation failure: it was built right, but it is not the right fit for the need.
Note on C
Verification checks that the system matches its specification, and all of those tests passed.
Note on D
Performance testing passed, and the problem is inaccessible data in the workflow, not speed.
Card 10 of 25
In the requirements traceability matrix, a business analyst finds a requirement with no link to any business objective or source. What should the BA do?
Note on A
Leaving an untraced requirement in place keeps possible scope creep in the baseline.
Note on B
Correct: A requirement without a source may not be needed, so the business analyst confirms its origin and value with stakeholders before deciding what to do.
Note on C
Forcing a link to the nearest objective fakes traceability instead of confirming it.
Note on D
Deleting it without checking could remove a valid requirement whose link was simply missed.
Card 11 of 25
Experienced warehouse staff cannot clearly explain how they handle exceptions, although they do it every day. Which technique will BEST reveal how the work is actually done?
Note on A
A questionnaire depends on people describing their work, which these staff cannot do clearly.
Note on B
An interview also relies on staff explaining how they handle exceptions, which is the very difficulty here.
Note on C
A focus group gathers opinions through discussion, which does not reveal tacit, hands-on practice.
Note on D
Correct: Observation lets the analyst watch the work as it is done, revealing tacit steps people cannot easily put into words.
Card 12 of 25
A change request to add a bulk export feature to a reporting application is approved by the change control board. The request describes the feature only as a high level capability, and the development team is ready to start work. Which action best preserves the testability of the requirement?
Note on A
A developer’s informal check is not an objective, agreed standard for acceptance.
Note on B
Updating the schedule addresses timing, not whether the requirement can be tested.
Note on C
Logging the change and starting work leaves the feature without any criteria to test against.
Note on D
Correct: Adding measurable acceptance criteria turns the high-level capability into a requirement that can be objectively tested.
Card 13 of 25
During a traceability review, a business analyst finds a delivered feature that does not trace back to any approved requirement. What should the BA do FIRST?
Note on A
The feature may work correctly, so calling it a defect assumes facts not yet known.
Note on B
Removing it before understanding where it came from may throw away something stakeholders actually requested.
Note on C
Adding a requirement after the fact legitimizes unapproved scope without checking it.
Note on D
Correct: An untraced feature may be gold plating or an unrecorded request, so the business analyst first finds out where it came from.
Card 14 of 25
Midway through an iterative project, a change request was approved and implemented, but no one updated the requirements traceability matrix because the team considered the change too small to track. What is the most likely impact of leaving the matrix stale?
Note on A
Correct: The matrix no longer shows which tests cover the changed requirement or what it touches, so later coverage checks and impact analysis rest on wrong links.
Note on B
A stale matrix does not change the scope baseline by itself; baseline updates still go through change control and approval.
Note on C
The cost performance index comes from earned value and actual cost, not from the traceability matrix.
Note on D
Nothing reverses an approved change automatically; a phase gate reviews work, it does not undo implemented changes.
Card 15 of 25
An executive sponsor can spare only 30 minutes and must confirm one specific decision about how the new billing system will validate customer identity. Which elicitation technique is most appropriate for obtaining this requirement?
Note on A
A multi-day workshop does not fit a 30-minute window or a single focused decision.
Note on B
A focus group gathers opinions from many users, but the decision belongs to the sponsor.
Note on C
Correct: A short, scheduled one-on-one interview fits the sponsor’s limited time and targets the one decision needed.
Note on D
An anonymous survey of users cannot capture a specific decision from one executive.
Card 16 of 25
A requirement in the approved specification states: ‘The system shall protect user credentials.’ During backlog refinement the team must rewrite this as an acceptance criterion that a tester can objectively verify. Which acceptance criterion makes the requirement objectively testable?
Note on A
Strong cryptography and secure at all times are vague terms with no measurable test condition.
Note on B
Correct: Hashing passwords with bcrypt at cost factor 12 before storage is specific, so a tester can objectively check it.
Note on C
This restates a security goal without saying how a tester would verify it.
Note on D
Full compliance with industry standards does not name which standard or what to check, so it cannot be objectively tested.
Card 17 of 25
An agile team wants acceptance criteria that describe a starting situation, an action and an expected, testable result. Which format should it use?
Note on A
INVEST is a checklist for well-formed user stories, not a format for acceptance criteria.
Note on B
Correct: Given/When/Then states a starting context, an action, and an expected result that can be tested.
Note on C
MoSCoW is a prioritization technique, not a way to write acceptance criteria.
Note on D
As a/I want/So that is the user story format, describing who wants what and why, not a testable scenario.
Card 18 of 25
A team builds a clickable prototype of a new customer portal and walks end users through it, asking them to confirm whether the proposed solution will satisfy their business needs before construction begins. This activity is best classified as which type of assessment?
Note on A
Quality control inspects the finished product against requirements, but nothing has been built yet.
Note on B
Correct: Asking users whether the proposed solution meets their business needs is validation, which confirms fitness for purpose.
Note on C
Verification checks that a component matches its specification, not whether it meets users’ real needs.
Note on D
A configuration audit checks that items match their baselined documentation, not user needs.
Card 19 of 25
A business analyst needs input from 400 users in six countries on which report features they use most, and wants results that can be compared numerically. Which elicitation technique is MOST appropriate?
Note on A
Job shadowing gives deep insight into a few people’s work but cannot reach 400 users in six countries.
Note on B
A workshop suits small groups that need to reach agreement, not large, dispersed populations.
Note on C
A focus group involves a small sample and produces qualitative opinions, not comparable numbers.
Note on D
Correct: A questionnaire or survey reaches many dispersed users efficiently and produces results that can be compared numerically.
Card 20 of 25
At a release readiness review, one requirement fails its acceptance criteria and the release date is fixed. What should the business analyst do?
Note on A
Finishing development does not mean the requirement is accepted, since it failed its criteria.
Note on B
Correct: The analyst should explain the gap and its impact so the decision maker can make an informed choice about the fixed release date.
Note on C
Relaxing the criteria to match the build hides the gap and defeats the purpose of acceptance criteria.
Note on D
Releasing and logging a defect afterward makes the decision without the decision maker knowing about the gap.
Card 21 of 25
Stakeholders cannot describe what they want in a new sales dashboard and say they will “know it when they see it.” Which elicitation technique is BEST?
Note on A
Structured interviews depend on stakeholders describing what they want, which they say they cannot do.
Note on B
Document analysis reviews existing materials and will not help stakeholders picture a new dashboard.
Note on C
Correct: Prototyping gives stakeholders something concrete to react to, which suits people who will know it when they see it.
Note on D
A questionnaire also relies on people stating their needs in advance, which these stakeholders cannot do.
Card 22 of 25
During Validate Scope, the customer rejects a deliverable that meets every documented requirement. What is the MOST likely root cause?
Note on A
Detailed acceptance criteria normally make acceptance easier, not harder.
Note on B
Nothing in the scenario suggests unapproved changes, and the deliverable matches the documented requirements.
Note on C
Correct: When a deliverable meets every documented requirement and is still rejected, the requirements most likely failed to capture the customer’s real needs.
Note on D
Skipped quality control would show up as defects against requirements, but the deliverable meets all of them.
Card 23 of 25
In a use case for online checkout, the customer enters an invalid card number and the payment cannot be completed. Which part of the use case describes what happens next?
Note on A
A postcondition states the system’s condition after the use case ends, not the steps after an error.
Note on B
Correct: An exception flow describes what happens when an error prevents the goal, such as an invalid card stopping payment.
Note on C
The main success scenario describes the normal path where payment succeeds.
Note on D
An alternate flow is a different path that still reaches the goal, while here the payment cannot be completed.
Card 24 of 25
A project team is reviewing a newly submitted performance requirement for a financial reporting dashboard. The requirement states: ‘The dashboard must load customer transaction histories rapidly during peak business hours.’ As a business analyst, what critical element is missing from this nonfunctional requirement?
Note on A
Database architecture is a design decision, not part of stating what the requirement must achieve.
Note on B
UI design guidelines concern functional presentation, not the measurable performance this requirement lacks.
Note on C
Correct: ‘Rapidly’ cannot be tested, so a nonfunctional requirement needs a measurable threshold, such as a load time, and the conditions under which it applies.
Note on D
Personas help the team understand users, but they do not make a performance requirement measurable.
Card 25 of 25
A product team is writing acceptance criteria for a new search feature. The product owner wants the criteria to be verifiable during system testing and to hold up in an audit of the requirements traceability matrix. Which acceptance criterion best defines the nonfunctional performance requirement?
Note on A
Highly responsive and consistently good are subjective words that a tester cannot measure.
Note on B
Correct: A 2-second response for queries of up to 1,000 items at the 95th percentile is measurable, testable, and easy to trace.
Note on C
Quickly, reliably, and most users are vague terms with no threshold a tester can verify.
Note on D
Fast enough to satisfy stakeholders depends on opinion rather than a measurable standard.
Done 0