A requirement states what a software system is expected to do. In a traditional handoff, a business request may become a document, then code and test cases, then documentation. Each translation risks losing the original intent. Businesspeople, analysts, developers, and testers can reduce that risk by discussing the request together and testing their understanding against examples of what should—and should not—happen. section 1.1
Requirements are not necessarily precise or stable at the start of a project. Business goals may be clear while the useful feature set and its details remain uncertain. Early feedback helps a team revise its understanding before investing further in a solution that works but delivers little value. section 1.2.3 section 2.3.3
A requirement can move from an idea to evidence of value through these activities:
- Identify the business goal and candidate features; discuss concrete business rules and user journeys. section 3.1
- Turn key examples into readable, executable specifications and automated acceptance tests; use passing tests to demonstrate the implemented behavior. section 3.1 section 7.6.1
- Check the feature in use to see whether it delivers the intended business value. section 3.1
Changing a train-departure requirement
Suppose users now need the next four trains rather than the next two. First change the acceptance scenario to expect four departure times. Its failure exposes the gap between current behavior and the new requirement. Then update the relevant unit test and implementation until the new criterion passes. For a bug that existing criteria missed, add a criterion that reproduces it before fixing it. section 3.7
Passing tests alone do not show that every requirement has been addressed. Feature coverage also counts defined criteria that are not yet automated—or requirements with no automated criteria. This distinguishes completed behavior from work that remains pending, without confusing feature coverage with code coverage. section 16.2.2
Listing 16.1 The Authentication feature file
Business Need: Authentication
Registered Frequent Flyer members can access their account using their
email and password
Rule: 1) Frequent Flyers can authenticate by entering their credentials
on the login page
Scenario: Trevor successfully logs on to the Frequent Flyer app #1
Given Trevor has registered as a Frequent Flyer member
And he has confirmed his email address
Then he should be able to log on to the Frequent Flyer application
Rule: 2) Frequent Flyers can sign in with SSO using their Google or
Facebook account
Example: Trevor logs in using his Google credentials #2
Example: Trevor logs in using his Facebook credentials #2
The authentication feature file places a specified login scenario beside empty single sign-on examples, making unfinished requirements visible even when implemented tests pass. section 16.2.2
