Requirements Engineering
Requirements Engineering in CTAL-ATT covers how agile teams turn intent into shared, testable understanding. The exam tests whether you can evaluate user stories, acceptance criteria and collaborative practices (ATDD, BDD, Specification by Example), not whether you can write a formal requirements specification.
Core rules and concepts
- A user story is a promise for a conversation, described by the 3 Cs: Card, Conversation, Confirmation. The written card is not the requirement; the shared understanding is.
- Good stories satisfy INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.
- Acceptance criteria provide the confirmation. Two common styles are rule-oriented (a checklist of conditions) and scenario-oriented (Given/When/Then, as in Gherkin).
- Three Amigos sessions bring business, development and testing together to expose assumptions and missing rules before coding.
- ATDD derives acceptance tests before implementation; BDD expresses them in business-readable language. Both rely on a ubiquitous language and concrete examples.
- Reviewing criteria for ambiguity, completeness and consistency is a core test analyst task; traceability links each criterion to at least one automated or manual check.
- Definition of Ready and Definition of Done make readiness and completion explicit and testable.
Worked example
Story: "As a customer I can pay with a saved card." Criterion: "Payment is fast and secure." Reasoning: neither "fast" nor "secure" is measurable, so no check can pass or fail reliably. Rewrite as "A saved-card payment is authorised within 3 seconds at the 95th percentile", add "Card data is never stored in plain text", and add a scenario for a declined card. Each rewritten criterion is now testable and traceable.
Traps
- Writing acceptance criteria after coding has started.
- Confusing acceptance criteria with detailed test cases.
- Ignoring non-functional criteria and negative paths.
- Treating the story card as the specification.