One definition of software quality is the absence of defects. Of course, how do you know if all the defects have been found? If you can’t find any, does that mean the software is ‘good’ quality? When we talk to our clients about software quality, we try to impress the importance of detecting defects earlier in the development cycle, rather than just testing when development hands over a new build. Research shows and we all know that defects found early are cheaper to fix than those found later, so why not build early defect detection into the process. We all log defects when we are testing the software. That’s what we call ‘software testing’, but what about requirements testing (some may consider this part of software inspection as well)? That is, testing specifically to see if a requirement has defects, and rejecting a requirement just like we do a software function that is not operating as expected. The IEEE Standards Organization gives us a hint as to what a ‘quality’ requirement is via IEEE Std 830 :
Unfortunately, IEEE only provides guidelines and definitions with limited implementation specifics to actually help those on the front line. However, with today’s modern defect tracking and ALM software, we can make some configuration tweaks to begin recording requirements defects and stop coding defects in their tracks by making sure that requirements are correct, unambiguous, etc. This requires forming new habits and modifying some processes, but implementing this discipline can bear fruit in reduced defects down the road leading to increased quality all-around.