Q
Problem solve Get help with specific problems with your technologies, process and projects.

How detailed should software requirements be?

As is usual in software development, how detailed your requirements are depends on many factors. Expert Karl Wiegers offers some guidelines.

How detailed should the requirements be?
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.
This was last published in February 2007

Dig Deeper on Software Requirements Management

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close