I just finished reading Writing Better Requirements by Ian F. Alexander and Richards Stevens and thought I would share their patterns and principles for creating good requirements.
Writing Better Requirements by Ian F. Alexander and Richards Stevens
Identity Stakeholders
Writing Better Requirements by Ian F. Alexander and Richards Stevens
- Identify key stakeholder core groups, e.g. pilots, navigators and flight attendants
- Prepare a list of people, name and job title, that can best speak to each core group
Gather Requirements
- Requirements express human need, e.g. the coffeepot must be made of stainless steel
- Requirements should answer questions like
- What is the purpose of that? e.g. based on our example above, a glass coffee pot will break, which begs the question, why would it break? and on and on …
- Can you explain why you need it to do that?
- What was the thinking behind that?
- What is the underlying reason for that?
- Requirements focus on the “why” and never the “how”, that’s where the specification comes in
Structuring Requirements
- Write requirements in everyday language
- Make a simple structure of sections to group the requirements
- Order the sections in time order so that they can be read in scenarios, a scenario might be adding a job order, or just job order entry
- Determine with sections as:
- Sequences, e.g. A comes first, then B
- Parallels, e.g. A and B can both happen at the same time, no dependencies
- Alternatives, e.g. a different path
- Identify sections that are exceptions, e.g. Users should not be able to reserve a plane ticket if the plane has no current seating
- Identify requirements with a number, and/or section … identify related requirements …
- Prioritize based on sequence, e.g. We can’t add contact until we have customers as we need to associate them to a customer, then based on need
Guidelines for Good Requirements
- Use simple direct sentences, e.g. The pilot shall be able to view the airspeed
- Use a limited vocabulary, avoid terms that may confuse non-technical or foreign readers
- Identify the type of user who wants each requirement, e.g. The navigator shall be able to…
- Focus on starting results, each requirement should name a single desired result, e.g. … view storm clouds by radar …
- Define verifiable criteria, each requirement must be verifiable, this can be addressed with a simple phrase to qualify a basic need, e.g. … at least 1000 kilometers ahead
If you want to write evil requirements, then just do the following:
- Be ambiguous
- Combine multiple requirements into a single requirement
- Include lots of let-out clauses, these lead to testing problems, dangerous let-outs include: if, when, but, except, unless and although.
- Let-outs are often introduced by the word always.
- Ramble
- Include the design of the system, or the “how”
- Speculate
Review Requirements
Once the requirements are written, it’s time to review with the stakeholders. The aim of the review is to improve the quality of the requirements. The requirements should define the problem as accurately as possible.
I thought the authors did a great job with this book. It was an easy read, and more importantly, it made sense. I am going to try to leverage these patterns and principles on my very next project. I’ll keep you posted on how it goes, for better or worse.
