After having done a brainstorming on use cases and activities, it’s time to formulate these in textual form.
Shall, should, can
For requirement engineering often the pattern “if …, the … shall/should/can do …” is used.
- If logged in, the user shall be able to interact with the software
- If not logged in, the user shall be redirected to the login page
- If user does not have an account, the user can create a new account
This already breaks down a otherwise big block of text into smaller patternized atomic actions and features. Further allowing grouping some of them and mapping them to components in following steps of design.
Gherkin
An alternative is to use Gherkin, which is a specific language for behavior driven design (BDD), designed by Cucumber.
In Gherkin single requirements are “Scenario’s” made of steps written in a specific form.
- Given – What is the (static) precondition
- When – Define a Trigger
- Then – Observable resulting behavior
This pattern pretty much matches the brainstorming we started with.
The benefit, that let’s hearts of testers jump higher is, it’s an standardized format that already has multiple implementations for Testframeworks. So a tester can use the requirements directly as input for tests and can focus on implementing the necessary steps.