What makes a requirement great? Is it INVEST, DEEP, or DIVE? These are great, and I suggest you follow their principles, but don't create unnecessary requirements. Instead of spending your valuable time trying to anticipate every question or mistake your team could make, you should focus on writing requirements that also follow agile principles.
Your requirements are the most efficient and effective method of communicating information (outside of face-to-face). They allow your team to deliver working software frequently, and you should trust that your team members will ask the right questions and suggest improvements. Here are a few tips that can help you do just that.
- Put the most important information at the beginning of the document
- Use images and diagrams to aid understanding
- Avoid pleonasm, i.e., the use of more words than are necessary to convey meaning
- Take advantage of technology, i.e., formatting, engaging media (videos or audio), and collaborative tools
- And most of all, deliver requirements iteratively! As many developers can tell you, three principles allow them to deliver iteratively: Small & Simple, Modular & Reusable, and Frequently Reviewed & Delivered.
Principle 1. Small & Simple
Philosophy:
All too often, we assume we need to accommodate every eventuality in great detail, but that is not true. Reduce wordiness by using bullets instead of whole sentences. Flow your requirements in a meaningful order. Use imagery to help support your text. Adopt some of the same principles you use when creating presentation slides.
Example:
Let’s look at typical acceptance criteria for a story where a user registers for an event. These are not bad, but there is room for improvement.
This change fixed three issues that make it harder for someone to read and use.
- Inconsistency: Some criteria are positive while others are negative.
- Fix: Updated each statement so that all requirements are positive
- Illogical Order: Save to the database was mentioned before checking spam and credit card payment.
- Fix: Ordered the statements as they would be checked and tested
- Too Wordy: Repeating form and submit and pleonasm to ensure sentences are grammatically correct
- Fix: Grouped items to reduce repeating words; eliminated extra words by changing from sentences to bullet points
Principle 2. Modular & Reusable
Philosophy:
Avoid writing long paragraphs and restating unnecessary information. Instead, break requirements into micro requirements that can be referenced rather than repeated.
Example:
Imagine a login form, registration form, and password reset request. These all share similar acceptance criteria – username must match the following format:
- Field is required
- Length must be 8 to 24 characters
- Alphanumeric only
- Must not contain foul language
- Must not be the user’s first or last name
Instead of restating the full acceptance criteria in each story or requirement, break out that piece into its own definition labeled "Username Validation" and then reference the Username Validation. Trust me when I say testers and developers will be grateful that you pointed out they can reuse something already created. Not to mention if the requirements change, then you only need to update it in one place.
Principle 3. Frequently Reviewed & Delivered
Philosophy:
Do not wait until you have created a ready-to-build everything requirement. Today’s technology allows us to share our information quickly and efficiently. We often say that we should be open to failing fast, which should enable us to lead by example.
Examples:
- Create an outline and confirm the direction you are going
- Get feedback early for new or complex concepts by asking someone to review a single paragraph or section
- Build it out in segments:
- Write the full, happy path, then review/deliver
- Add the title or summaries of the alternative paths or errors, then review/deliver
- Add the details for each alternative path or error, then review/deliver
Iterative Requirements Delivery is an excellent tool for adding efficiencies to your team. A few benefits you can expect include better estimates, faster technical design, earlier adjustments for technical concerns, and best of all, your team is already familiar, so they can hit the ground running!
Article Author: Deena Chadwick, The CommonSensical BA
Associated article and webinar recordings:
