1 Comment

How to Lower Your Defect Rate Using Simple Requirements Techniques

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.

Continue reading


Leave a comment

Requirements, really?

Nadine Parmelee

by Nadine Parmelee
Senior Quality Assurance Engineer

Change is hard. Project teams frequently resist the addition of new processes and procedures, and one process frequently fought is the creation and review of requirements. The reaction is understandable—it’s most likely resistance to creating more work in the midst of already tight schedules. On the other hand, some of the consequences of not having requirements or having poorly thought out requirements are:

  • Developers guessing how the application should behave
  • Secondhand guessing: testers guessing how the developers guessed the application should behave
  • Customers not liking or having difficulty with the product
  • Spending time and money reworking a product to remove ambiguities
  • Inability to map test case to requirements, which can lead to not really knowing if the testing is complete

The benefits of creating requirements and making them clear in the first place are numerous. Here are just a few:

  • Understanding the purpose of a new feature
  • Understanding the workflow of a new feature
  • Understanding the options of a new feature
  • Understanding how a new feature integrates with existing functionality

And that’s just the beginning of what ultimately amounts to a little time spent upfront for maximum gain and minimizing stress on a project.

Creating requirements does not have to be an exercise in torture. Even the most basic requirements list is better than no requirements at all. Whenever there is functionality without requirements, developers and testers will make assumptions on how each thinks the functionality should work. Those assumptions may not match the intended behavior. By at least starting a list with the most basic of the requirements, early misunderstandings of what is expected can be avoided.

Additionally, the more people that review the requirements as early as possible, the sooner questions about functional behavior and whether certain functionality is even possible can be raised and potentially save large amounts of time and money. Reworking requirements adds delays and costs to any project, so the better the requirements are to begin with, the more efficiently the project schedule and budget can be maintained. Reworking code over and over and the subsequent testing of that code can add even more costs and delays until the project team can agree on the desired functionality. The earlier everyone has the same understanding of what needs to be done and the desired outcomes, the more quickly a project can progress and the more quickly new personnel can get up to speed on what they need to do to help complete the project.

When requirements are organized well and are succinct and clear, it is easier for developers and testers both to meet those requirements and map specifications and test cases to those requirements and improve the product quality from the beginning. By having better quality early on, the odds of getting a project completed on time and on budget are greatly improved.