Home > Ask the Software Quality Experts > Software Requirements Questions & Answers > How detailed should software requirements be?
Ask The Software Quality Expert: Questions & Answers
EMAIL THIS

How detailed should software requirements be?

Karl E. Wiegers EXPERT RESPONSE FROM: Karl E. Wiegers

Pose a Question
Other Software Quality Categories
Meet all Software Quality Experts
Become an Expert for this site


Software quality news and advice
Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


>
QUESTION POSED ON: 15 February 2007
How detailed should the requirements be?

>
EXPERT RESPONSE
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.


Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


RELATED CONTENT
Software Requirements
How to choose the right requirements tool
Why you should test requirements definitions
How to estimate change requests in requirements
Use cases: Who writes them, what data do you include?
How use cases facilitate the SDLC
Requirements engineering in an uncooperative environment
Scrum and requirements gathering
Requirements reporting beyond use cases
Requirements gathering with storyboards
How to elicit performance requirements

Software requirements management
How to choose the right requirements tool
How to estimate change requests in requirements
The Software Project Manager's Bridge to Agility: Chapter 5, Scope Management
Software Security Engineering: A Guide for Project Managers -- Chapter 3, Requirements Engineering for Secure Software
Requirements Management Using IBM Rational RequisitePro: Chapter 1, Requirements Management
Quality software performance doesn't happen accidentally
Software requirements elicitation and documentation
Outside-in Software Development: A Practical Approach to Building Successful Stakeholder-based Products -- Chapter 1, Introducing Outside-in Development
Project success: It all starts with configuration management
Business requirements drive Compuware's new application delivery management tools

Software Requirements Documentation
Use cases: Who writes them, what data do you include?
Requirements reporting beyond use cases
Test cases from requirements specifications and use cases
Software requirements sign-off essential for solid QA
Requirements discipline throughout the SDLC
Testability requirements and verification work
Poor business requirements process leads to high project costs, study finds
Software requirements elicitation and documentation
Requirements gathering for payroll application
Testers' involvement in requirements gathering important

RELATED GLOSSARY TERMS
Terms from Whatis.com − the technology online dictionary
requirements analysis  (SearchSoftwareQuality.com)

RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary



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.
Browse our Expert Advice

About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides enterprise IT professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective IT purchase decisions and managing their organizations' IT projects - with its network of technology-specific Web sites, events and magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Reprints  |  Site Map




All Rights Reserved, Copyright 2006 - 2008, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts