How to Lower Your Defect Rate Using Simple Requirements Techniques

1 Comment

By Chris McIntosh, Senior Software Developer

Chris McIntoshWe have all seen the various studies of software development and the causes of failures to deliver on time and cost overruns. The original Chaos report stated that a mere 16.2% of projects finished on time and budget. There have also been numerous studies surrounding the cost of defects and how it varies depending on when in the lifecycle they are discovered. The consensus, first reported on by Barry Boehm in the 80’s, is that the later in the software process a defect is discovered, the more expensive it becomes. There is some debate as to whether or not this is a hard and fast rule, but suffice to say, defects are rarely free to fix. Agile has cropped up to try and address some of these issues. It has certainly helped. A more recent report on software project failures puts it at 50% – 70% of projects are finishing on time and budget, with the projects using more agile techniques in the upper end of the spectrum. Agile practices are successful in reducing the failure rate by, in part, making the team test the development more frequently and elicit requirements more often. This is wholly dependent on your team’s ability to gather, record, and test requirements efficiently.

Here are some simple techniques that you can slowly introduce to decrease the defect rate due to poor requirements.

Document your change process

Whether you are doing strict agile and your detailed requirements come later in the form of Use Cases, or you are doing waterfall with a well-defined requirement phase towards the beginning of the project, document what your process is. This ensures that the product owners as well as the team have a place to look so that they are all following the same process, as well as many other benefits. IBM has a good guide on documenting processes that can help get you started with this.

Determine the minimum attributes necessary for a requirement to be considered complete

Document what a requirement is to your organization. Make sure to include the “obvious” technical bits like unique identifiers, or traceability to related requirements as well as the more abstract attributes like verification criteria. This will save you time when reviewing or implementing your requirements so that you don’t discover crucial missing information later in the process. If we look at the attributes that some popular Requirements Management Systems (RMSs) provide, we can get a good idea of some important ones:

  • Unique Identifier
  • Traceability Information
  • Priority
  • Risk
  • Status
  • Definition

Create a review process for your requirements

Create a responsibility matrix detailing how different members of the team can review the requirements based on their personal strengths. There are many attributes to review and it would be great to have multiple people review all of them for each requirement, but that would be too costly. Start by reviewing attributes your team has had difficulty with and see if it yields some improvement, and then add or remove reviews where you see value. Wikipedia has a good example of how to set up a responsibility matrix.

Record your requirements in a Requirement Management System (RMS)

Consider migrating to a Requirements Management System. This is by no means a small change if you have a large backlog of requirements, but if you are on a new project that is projected to last for a long time, then it may make sense. Using an RMS will allow you to trace your requirements to corresponding ones, save the history of the requirements as they change, and allow contextual discussion on the requirements. This has the added benefit of potentially clearing up test or development questions later down the line as the team can see how a decision was made. This blog has some info to get you started on what RMSs are, and this blog has a short comparison of some of the different offerings. There are tools that support Enterprise level rollouts on down to simple open source tools for small teams with a limited software budget that can help with your requirements management.

These should be some relatively quick changes you can adopt to improve the quality of your requirements that should in turn improve the quality of your end product while reducing time spent on clarifying unclear requirements.

Author: bridge360blog

Software Changes Everything.... Bridge360 improves and develops custom application software. We specialize in solving complex problems at every phase of the software development lifecycle, removing roadblocks to help our clients’ software and applications reach their full potential in any market. The Bridge360 customer base includes software companies and world technology leaders, leading system integrators, federal and state government agencies, and small to enterprise businesses across the globe. Clients spanning industries from legal to healthcare, automotive to energy, and high tech to high fashion count on us to clear a path for success. Bridge360 was founded in 2001 (as Austin Test) and is headquartered in Austin, Texas with offices in Beijing, China.

One thought on “How to Lower Your Defect Rate Using Simple Requirements Techniques

  1. All good points. Great job, Chris. One thing I would add is to read and follow RFC 2119. If followed, the requirements will be much more clear for all consumers. http://www.faqs.org/rfcs/rfc2119.html

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s