Why Do Requirements Need To Be Detailed & What Level Of Detail Is Enough?

Requirements need to be detailed (at varying levels for different types of projects) for a very important reason – Clarity. Business stakeholders need to communicate their requirements as much as developers need to understand what to build. Skipping important bits of information (like business rules and exceptions) or assuming that certain information is “given” can lead to assumptions which can in turn lead to costly mistakes down the line. On the flip side, producing these documents can be time-intensive and stifle creativity on the part of the developers, if not done appropriately.

Requirements that are delivered verbally can easily translate to different representations when it comes to coding. The same can be said for requirements delivered textually without any visual representation. Business Analysts can indeed benefit from using a combination of models (in addition to text) to communicate requirements, making it easier for stakeholders to review and for the development team to build the solution.

As development practices change, so do the reasons why we write requirements and the level of detail we go into with Requirements Specification Documents. Even seasoned business analysts have at one point or the other asked themselves, “What level of detail is enough?”. The answer to this seemingly simple question is inseparably intertwined with the reason why we write requirements in the first place: so that they can be read, understood, and implemented.

Alternative Views: When Are Detailed Requirements Necessary?

Generally speaking, the more you [and your team] know about a domain, the fewer the words needed to convey a concept (or requirement) with precision - Tyner Blain, Requirements Details – How Much is Enough?.

If you’re working with stakeholders who are actively involved in the development process and all the developers on your team have considerable domain experience, then brevity is the way to go. But if you outsource development to a team of geographically dispersed developers, more detailed requirements will be necessary, which may require more resources.

At the end of the day, the real question is who do you want to give the responsibility of making decisions related to the implementation of your requirements?

If you’re willing to defer many of the decisions on product capabilities and characteristics to the developers, you don’t need to include as much information in the requirements documentation...this can also work if subject matter experts are available to work with developers to pin down the details and make the necessary decisions - Karl Wiegers, How Detailed Should Requirements Be? - Part 1

When More Is Less

As Steve Jobs once said, “Customers don't know what they want until we show them.” Seasoned analysts and developers may have a much better understanding of what needs to be done to satisfy customers than customers themselves. Business analysts who decide to leave out key information from the requirements specification document however, give developers the freedom to make decisions based on their experience and sound judgment.

The ultimate goal of business analysis is to find the most appropriate approach to documentation based on a broad range of factors such as how the project is structured, the methodology and the complexity of the project, to mention a few. The Business Analyst must also consider the language and terminology used to describe requirements. Those who have a reasonable level of understanding of the domain will understand even highly technical terms, but everyone else should have a glossary of terms available to ensure a common understanding of what the final solution will look like.