Given a business situation, the learner can elicit requirements and write a clear specification, then self-check it against the requirement-quality checklist.
From situation to specification: the full cycle
From situation to specification: the full cycle
Every analyst engagement starts with a situation, not a solution. A business situation describes what is happening, who is affected, and what the pain is — it does not prescribe technology or features. From that raw situation you move through a chain of steps: identify the real problem (not the first solution someone mentions), name the stakeholders who are affected or whose buy-in you need, elicit and classify requirements, and finally write a specification entry that passes the quality checklist.
Requirement quality in BABOK is described by nine characteristics: atomic (one thing per requirement), complete (no 'TBD'), consistent (no contradictions), concise (no padding), feasible (actually buildable within constraints), unambiguous (exactly one interpretation), testable (you can write a pass/fail test), prioritized (the business has ranked it), and understandable (readable by its audience). The most common defects are vague words like 'fast', 'user-friendly', or 'etc.' — these make a requirement untestable and therefore unverifiable.
From situation to specification
- 11. Situation
what happens, who suffers — no solution yet
- 22. Problem
the real need behind the first suggested solution
- 33. Stakeholders
who is affected, who must agree
- 44. Requirements
business → stakeholder → solution (FR + NFR) → transition
- 55. Quality check
unambiguous, testable, atomic, consistent, feasible
- 66. Hand over
only when a developer and a tester need no follow-up questions
Lesson notes
From situation to specification: the full cycle
Every analyst engagement starts with a situation, not a solution. A business situation describes what is happening, who is affected, and what the pain is — it does not prescribe technology or features. From that raw situation you move through a chain of steps: identify the real problem (not the first solution someone mentions), name the stakeholders who are affected or whose buy-in you need, elicit and classify requirements, and finally write a specification entry that passes the quality checklist.
Requirement quality in BABOK is described by nine characteristics: atomic (one thing per requirement), complete (no 'TBD'), consistent (no contradictions), concise (no padding), feasible (actually buildable within constraints), unambiguous (exactly one interpretation), testable (you can write a pass/fail test), prioritized (the business has ranked it), and understandable (readable by its audience). The most common defects are vague words like 'fast', 'user-friendly', or 'etc.' — these make a requirement untestable and therefore unverifiable.
Stories, criteria and the final self-check
A well-formed user story follows the Connextra template — 'As a <role>, I want <action>, so that <value>' — and is paired with Given-When-Then acceptance criteria: Given describes the precondition or context, When describes the action the actor takes, Then describes the observable, testable outcome. Each acceptance criterion must be independently testable; a long list of them usually means the story should be split.
When you have written a deliverable — a requirement, a story, or an SRS section — run it through the quality checklist before handing it over. Ask: Can a developer build exactly this without asking follow-up questions? Can a tester write a pass/fail test for it? Does it conflict with any other requirement? If the answer to any question is 'no' or 'maybe', rewrite before delivering.