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.
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. A healthy story has one to three acceptance criteria, each independently testable.
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.
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.
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. A healthy story has one to three acceptance criteria, each independently testable.
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.