How detailed should software requirements be? |
 |
EXPERT RESPONSE FROM: Karl E. Wiegers
|
|
|
|
| > |
QUESTION POSED ON: 15 February 2007
How detailed should the requirements be?
|
|
|
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
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.
|
|
|
|
|
|
|
|
Search and Browse the Expert Answer Center
Search and browse more than 25,000 question and
answer pairs from more than 250 TechTarget industry experts.
|
|
|
|
|
|
|
|
|
|
|
|
