How detailed should the requirements be?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
As is usual in software development, the correct response is, "It depends." The central question to consider is: Who do you want to have making decisions about the requirements details and when? The more important it is to convey specific information about the product's desired capabilities and characteristics to the developers, the more detailed the requirements need to be.
There are several conditions under which it might be appropriate to have less detail in the requirements. If you have customers interacting closely with analysts and developers, you don't need as much written requirements documentation. You can also write less-detailed requirements if the developers have extensive experience with the application domain. If you are building a system that is based on or derived from an existing application, such as when reengineering a current system, you might not need comprehensive requirements. If your project intends to acquire a commercial package solution to meet some or all of the project's needs, there's no point in writing detailed functional requirements because the people who built the package have already done that (at least we hope they did).
In contrast, if you plan to outsource development, plan to have highly detailed requirements. With outsourced development you don't have the many opportunities for day-to-day interactions between developers with questions and customers with answers. You have no choice but to provide richer information in written form. If your team is geographically dispersed, you need to develop a richer shared repository of requirements and project information. To perform comprehensive requirements-based testing, those requirements need to be detailed enough so that the testers know what the expected system behavior is under many circumstances.
No requirements specification will fully describe every product detail. Nor will even the best requirements specification replace human dialogue. But the factors I listed here will help you decide when your requirements are detailed enough to avoid unnecessary risk.
There are several conditions under which it might be appropriate to have less detail in the requirements. If you have customers interacting closely with analysts and developers, you don't need as much written requirements documentation. You can also write less-detailed requirements if the developers have extensive experience with the application domain. If you are building a system that is based on or derived from an existing application, such as when reengineering a current system, you might not need comprehensive requirements. If your project intends to acquire a commercial package solution to meet some or all of the project's needs, there's no point in writing detailed functional requirements because the people who built the package have already done that (at least we hope they did).
In contrast, if you plan to outsource development, plan to have highly detailed requirements. With outsourced development you don't have the many opportunities for day-to-day interactions between developers with questions and customers with answers. You have no choice but to provide richer information in written form. If your team is geographically dispersed, you need to develop a richer shared repository of requirements and project information. To perform comprehensive requirements-based testing, those requirements need to be detailed enough so that the testers know what the expected system behavior is under many circumstances.
No requirements specification will fully describe every product detail. Nor will even the best requirements specification replace human dialogue. But the factors I listed here will help you decide when your requirements are detailed enough to avoid unnecessary risk.
This was first published in February 2007