One of the ten big rules of writing a good MRD is writing consistent requirements. Consistency within an MRD has two dimensions that are important to requirements – logical consistency and grammatical consistency. There is also the element of writing an MRD that is consistent with other documentation – external consistency.
The Big Rule of Writing Consistent Requirements
From our previous article, Writing Good Requirements – Big Ten Rules:
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.
Logical Consistency
Logical consistency within an MRD requires us to pay attention to what we’re writing. Applying the big rule of atomicity (one market requirement per written requirement) simplifies this quite a bit. The biggest source of duplication comes from writing requirements that involve involve two related ideas. The duplication is obvious when we find it, but with very large systems (and documents) it can be easy to overlook.
Avoiding contradictions can be harder. We might write mutually exclusive requirements, or requirements that are independently attainable, but that neither can be realistically attained if they are both implemented. For example, we could write a requirement that specifies near instantaneous search results, and we could write a requirement to include insanely large amounts of data (like the call logs for all customers of a telecom provider for all time). While this is possible, it might not be attainable for our team, who could easily implement a relatively innefficient search algorithm, or who could set up a very large data store.
Grammatical Consistency
Use of templates can provide a way to make individual requirements consumable. They also help with the learning curve of people who regularly read the MRD – they set expectations, and when followed, make scanning of the documents more efficient. The problem with templates is that not every requirement fits the same mold, and it can be cumbersome to squeeze the requirements into a stock format.
External Consistency
An MRD is one document in the flow of requirements from market needs to product. Often, an MRD is used to drive the creation of a PRD, and it captures a vision for the product and explanation of the relevant market research and how it applies to creating our product. Occasionally, only one of the MRD / PRD documents is created. Either a Software requirements specification (SRS) is created directly from the MRD, or the PRD is created in conjunction with other strategic documents (vision, roadmap, market research). Different companies use different approaches, and there isn’t a generic best answer.
Regardless of the mix of documents we use, the documents exist to support each other. Each document is a targeted expansion of the higher-level document. We need to make sure we write each document at the same level of detail, and each supporting requirement at a level of detail “one step” beyond the requirement it supports.
This approach allows readers to know where to find the big picture view, and where to find the devil in the details.
Conclusion
We have to make sure we don’t contradict ourselves logically. We need to manage the level of detail that we use consistently within and across documents. And templates can help us with using a consistent structure within a document.
