In this Lightning Cast, I discuss requirements quality – What is it and how you can increase the quality of your requirements.
A Lightning Cast is a shorter form episode modeled after lightning talks. You’ll get valuable content in 8 minutes or less.
Quality . . . I can’t tell you what it is, but I know when I see it.
There’s a lot of talk about producing high-quality requirements but what does it really mean? Quality is a standard against which something is measured. It’s a degree of excellence or the ability to satisfy a need or expectation.
When it comes requirements, people often talk about the characteristics of good requirements. The most common characteristics mentioned are: complete, concise, correct, clear, testable, traceable, and prioritized.
- Are your requirements complete? Do they contain all the necessary information to convey a shared understanding?
- Are they concise? Do they contain enough information but not too much information or unnecessary information?
- Are they correct? Can they help us to achieve the right business outcome?
- Are they clear and unambiguous? If you use terms like fast or user-friendly, those are ambiguous terms and open to interpretation.
- Are the requirements testable? Instead of saying ‘fast’, you can say ‘the screen refreshes in 10 milliseconds.
- Are they traceable? Do we know where those requirements came from and can we trace it to a higher need or goal?
- Are they prioritized? Do we understand the value behind each one and are we able to make trade-off decisions?
With user stories, we often talk about INVEST criteria. INVEST stands for independent, negotiable, valuable, estimable, small, and testable. There’s some overlap between regular requirements and user stories.
Both are independent. User stories and requirements should be independent in that you should be able to implement each one without dependencies on others.
Requirements and user stories are valuable. They generate some kind of desired outcome.
They should both be estimable. They are well enough understood and small enough to be estimated. Additionally, both are small. They’re small so as to fit within a single iteration or least be completed quickly. We want to create things in small increments so that we can use feedback loops to adapt and adjust.
Finally, both requirements and user stories are testable.
Upon reflecting about the characteristics of good requirements, I started thinking about SMART goals. You may remember SMART stands for specific, measurable, achievable, realistic, and time bound. By making a slight change, we get SMART requirements.
- Specific: They are clear, concise, and help us work towards a specific outcome
- Measurable: They can be tested (possibly with metrics identified)
- Achievable: The requirements are feasible and realistic. We have to consider the organization’s current capabilities and resources for this.
- Results-focused: They are correct, traceable, lead to a higher goal, and help us to achieve a desired outcome
- Time-bound: The cost of delay is understood. This leads to the ability to order your backlog or break a project into phases.
In the end, high-quality requirements create a shared understanding. They help us get clarity on steps toward achieving a goal. You can spend months trying to craft the perfect requirements or you could spend very little time and do a quick and dirty requirement. Think about your goal. We need to focus on the outcomes, not just requirements.
Do your requirements lead to the right objectives that help propel your mission and vision forward?
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.