Posted by tac_admin, August 10, 2012

Why Should You Define Requirements?

Their is a high price to pay if requirements are not defined (or not defined well). This can result in requirements defects. Requirements defects are errors caused by incorrect or incomplete requirements. If their are missing requirements or even conflicting requirements those are also considered requirement defects.

Requirements defects can lead to cost overruns, rework (which will be expensive and add to cost overruns), poor quality, late delivery, unsatisfied customers, and team members that are overworked, exhausted, and dissatisfied with their work environment.

One half of the cost of software development is spent on correcting defective requirements. Defective requirements are the most expensive kind of error to fix. Because defective requirements affect coding and testing, they tend to be spread out to multiple areas of the project which is what makes them so expensive to fix.

If you properly define requirements in the analysis phase of the SDLC, you run less risk of increased cost for the project and possible project failure.

2 responses to “Why Should You Define Requirements?”

  1. […] In short, a term is a noun or noun phrase that is important to the business. Defining and using terms correctly and consistently is critical for accurate requirements. […]

  2. […] because it’s not very user-friendly or has a lot of defects, getting an EUAC together to help define the requirements for the changes will help get them back on board with using the […]

Leave a Reply

Your email address will not be published. Required fields are marked *

Get in touch today

Speak directly with The Analyst Coach
and get pointed in the right direction.

Preferred Contact EmailPhone

Subscribe to receive our free white paper on how weak requirements effect strong companies


Sign up to get your FREE Business Analyst Survival Guide

Don't worry, we hate spam too. We will never share your information to third parties.