Avoid Requirements-related Defects in IT-Systems

Name: Avoid Requirements-related Defects in IT-Systems
Type: Process
Version: 2007-04-20
Referring to: Principles for Requirements Engineering Tasks.P3
Source: Sorry, I know I used somebody else's material here but I failed to write the source down. If you feel like "hey, that's my idea" please let me know and I will be more that happy to properly credit you.

Note: The sooner a defect ist detected, the cheaper is its removal. This is a well known fact, nicely pointed out by for example by this article at Tyner Blain <…>. Why? Because in systems engineering usually things are described more than once - from different perspectives. As a rather coarse requirement, as an architecture, as a detailed requirement, as a design, as a test, as code, in manuals. The more of these artifacts have to be changed due to a defect, the more expensive. Add the cost of bringing the system to the user.
Therefore it is a good idea to avoid defects in the first place.

Concerning requirements, defects occur in 4 different steps in the process:
S1: When stakeholders incorrectly or incompletely define their requirements.
S2: When analysts document the requirements incorrectly or incompletely. Writing good requirements is not too difficult.
S3: When developers write unit tests that test the wrong implementation. Even very effective methods of continuous integration then result in very effective testing of the wrong thing.
S4: When testers make sure, that the wrong requirements were implemented or that nat all of the requirements were realised. Then we waste our time by testing for requirements that aren't really requirements

What do we do about it? We add feedback cycles accordingly:
S1: We focus on the ROI, so the stakeholders concentrate on the important requirements. Using different requirements gathering techniques on the same stakeholders help a great deal. Stakeholders oficially approve the requirements that were documented by the analysts. (BTW, that means that the requirements must be readable by stakeholders)
S2: We use a strict Specification Quality Control process to make sure we get well written requirements. One or more analysts approve the work of one other analyst. The ultimate goal in doing so is to improve the author, not the specification itself.
S3: intensive communication with analysts and architects helps developers while comprehending the requirements.
S4: Test cases and test data will be approved by the analysts.