By Chris McIntosh, Senior Software Developer

We 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.