Writing Good Requirements – The Big Ten Rules
Pragmatic Marketing has a training seminar called Requirements That Work. In support of that, they provide a list of 8 characteristics of good requirements. We change one and add two more to round it out to The Big Ten Rules. Combine this with Michael’s ten tips for writing MRDs, and we’ve got a good handle on how to create a great MRD.
Pragmatic’s List (1-8) + Two Three Four More
NecessaryValuable- Concise
- Design Free
- Attainable
- Complete
- Consistent
- Unambiguous
- Verifiable
- Atomic
- Passionate
- Correct
- Stylish
Looking at each rule of writing good requirements…
1. Valuable
Pragmatic uses necessary as a criteria of good requirements. We believe that valuable requirements are good requirements. When prioritizing requirements, we should do the must-have requirements first. But other valuable requirements are critically important – even if they aren’t mandatory. Prioritization and release scheduling should stress necessary requirements first, and then the most valuable requirements next.
Requirements that can differentiate our product from the competition are by definition not necessary – or the competition would have done it already.
[Update: Our detailed article on Writing Valuable Requirements ]
2. Concise
Easy to read and understand. If only it were that easy. For whom is it easy to read? A market requirements document (MRD) is written for several different people on the team. It provides a vision of what problems our product solves. It provides clarification to the implementation team. It also sets expectations with stakeholders. Different people on the team have different domains of expertise – we have to write requirements that are easily understood by all of them.
[Update: Our detailed article on Writing Concise Requirements]
3. Design Free
Generally, a requirement should not specifiy any of the implementation choices. From a product manager’s perspective the requirement is the ‘what’ and the spec is the ‘how’. To a system designer or architect or lead developer, the requirement serves as a ‘why’.
[Update: Our detailed article on Writing Design-Free Requirements]
4. Attainable
The requirement must be realistically achievable. Barbara and Steve make great points about understanding the cost of implementing something as expressed in the requirements. As we pointed out in our thoughts about good requirements management, there is an optimal tradeoff between costs and benefits for any given company or project. We can formally approach this using the techniques identified for more is better requirements using a Kano framework. In short, the investment must have an ROI that exceeds the opportunity costs by the hurdle rate.
Looking at cost-benefit tradeoffs also supports the argument that valuable should replace necessary.
[Update: Our detailed article on Writing Attainable Requirements]
5. Complete
Simply put, if the requirement is implented as written, the market need is completely addressed. No additional requirements are required. When writing a specification, we may use decomposition to break individual requirements into more manageable, less abstract criteria.
[Update: Our detailed article on Writing Complete Requirements]
6. Consistent
Pragmatic highlights that the requirement must be logically consistent with the other requirements in the document – no overlaps, no contradictions, no duplications. This is certainly the most important point of consistency.
There is also benefit to consistent writing in an MRD. We can use templates to provide a consistent framework, but more importantly the prose needs to be consistent. This consistency makes it easier on the readers.
[Update: Our detailed aricle on Writing Consistent Requirements]
7. Unambiguous
A great requirement has a single interpretation. A good requirement has a single reasonable interpretation. As part of our development process, we will use listening skills like active listening to make sure that our engineering team understands the requirement we intended to write. The better the requirements, the less expensive and risky this communication process will be. Writing unambiguously is critically important when using outsourcing models that limit our interactions with other team members.
[Update: Our detailed article on Writing Unambiguous Requirements]
8. Verifiable
We use a process that starts with market requirements, and then decomposes them into software requirement specifications. the market requirements must be written in a way that we can verify that the associated requirements specification will meet the market need.
[Update: Our detailed article on Writing Verifiable Requirements]
9. Atomic
Every requirement should be a single requirement. If we can say “Half of this requirement is implemented” then this needs to be two or more requirements. If a requirement read “Sales reps can manage their client list and generate custom reports” it expresses two atomic ideas (list management and report generation). Those ideas need to be separated
[Update: Our detailed article on Writing Atomic Requirements]
10. Passionate
Nothing great has been born from complacency, lethargy or mediocrity. When we are defining requirements, we must be passionate about what we’re doing. If we’re just going through the motions, it shows up in the writing. If we aren’t excited about a requirement, the problem is either with us or with the requirement. Either way, it won’t inspire the rest of the team to do something great.
[Update: Our detailed article on Writing Passionate Requirements]
11. Correct
[Update: Added 30 Oct 2006]
In addition to all of the analyses above, a requirement must actually further the objective it supports, and must be neccessary to meeting that objective, given a particular approach to solving the problem.
Our detailed article on Writing Correct Requirements.
12. Stylish
[Update: Added 5 Jan 2007]
Style can also be the difference between a well-crafted requirement and one that is hard to read. And style, applied consistently across requirements makes it easier to view them as a whole, and identify gaps and inconsistencies. This ease of comprehension matters when trying to achieve correct, consistent, complete requirements.
Our detailed article on Writing Stylish Requirements.
Summary
There isn’t really anything to summarize – this article is one big summary.
I would like to take a moment to thank everyone who has been subscribing, reading, commenting, and sharing Tyner Blain. We started this site six months ago and I am continually surprised, flattered, and thankful for all of the readers and support we have.
Thank you very much!
Scott
Recommended Reading
(7 votes, average: 4.71 out of 5)
Loading ...
May 26th, 2006 at 9:13 am
Let me propose another: Object-Oriented.
Here is a great essay by Edward V. Berard that does a much better job than my feeble attempt.
February 19th, 2007 at 5:09 pm
Thanks James! I’ve added a link to his collection of essays to the top of the page, I think other folks will really like it too!
July 5th, 2007 at 7:32 am
Great overview!
I need to work through the detailed articles and reconcile with my own list of requirem1ent questions. This is a checklist I use to validate a requirement. I have a separate checklist for specifications in general, which covers the more general points like conciseness and unambiguousness.
At least we agree to put value at the top of the list! Do we agree to judge the merit of all the others using this criterion? To give one example: how much more value does a concise requirement add than a verbose one? My most concise requirements generally lack the immediacy of some of my more verbose ones. And requirements full of redundancy have an interesting characteristic, in my experience: they are less likely to be completely wrong!
July 5th, 2007 at 8:49 am
Thanks Alan, both for reading and commenting!
The original list order comes from pragmatic marketing’s list of eight characteristics. That said, I think valuable is the most important – no reason to waste time on requirements without value. Correctness is the next most important characteristic – if we get it wrong, it doesn’t matter how well it is understood. I would follow that with unambiguous – even if we document the right stuff, and write it down accurately, it is worthless if our writing is misunderstood.
I would follow those with completeness and consistency, then attainable and verifiable. Then design-free, atomic, passionate, concise, and stylish.
I break it down into “stuff we must do to have a chance” and “stuff that makes us better / more efficient.”
How would you (or anyone else) prioritize these elements relative to one another?
August 14th, 2007 at 8:15 am
Valuable first, of course!
Then, of similar importance: attainable, verifiable and complete.
Then: unambiguous and consistent.
Then: correct!!
Then: design freee and atomic.
Then: passionate and stylish
Finally: concise.
So… we agree about the most important and the least important, but we diverge interestingly in between.
I rank attainable more highly because it is closely linked to valuable: What use is a hugely valuable and otherwise “perfect” requirement if it is simply unattainable?
I rank correctness less highly because much of the value of correctness is delivered by the higher priority properties. The definition above says the requirement “must actually further the objective it supports”, for example. In my view, the proposition that the requirement is valuable ensures this. So it is valuable, attainable, verifiable, complete, unambiguous and consistent… but also incorrect… Can’t be very incorrect, it seems to me!
August 14th, 2007 at 9:37 am
Thanks very much, Alan.
On attainable vs. valuable. A bit of a catch-22. It must be both. But I think it is easier to redefine a valuable requirement (perhaps eroding the value) until it is attainable, than it it is to redefine an attainable requirement until it is valuable.
Good point about correctness versus value. I think about it in terms of context. A valuable goal might have been for the USA to “beat” the Soviets in the geopolitical realm. Two requirements may have been “be first to the moon” and “devalue their ICBMs.” Those requirements embody some ideation – a strategy towards achieving the objective. Both have a ‘value’ and both have ‘correctness’ – but as you say, those notions are intertwined.
Really fun to think about it with this level of rigor, especially when revisiting (for me, anyway) these earlier articles. Thanks!