|
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 :
* Correct
* Unambiguous
* Complete
* Consistent
* Ranked
* Verifiable
* Modifiable
* Traceable
* Understandable
|
