Avoid Requirements-related Defects in IT-Systems

Type: Principles, Rules
Sources: 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.
Referring to: Principles for Requirements Engineering Tasks.P3



Note: The sooner a defect is 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.

Principles

Concerning requirements, defects occur in 4 different steps in the process

P1: When stakeholders incorrectly or incompletely define their requirements.

P2: When analysts document the requirements incorrectly or incompletely. Writing good requirements is not too difficult.

P3: 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.

P4: When testers make sure, that the wrong requirements were implemented or that not all of the requirements were realised. Then we waste our time by testing for requirements that aren't really requirements

Rules

What do we do about it? We add feedback cycles accordingly

R1: 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)

R2: 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.

R3: intensive communication with analysts and architects helps developers while comprehending the requirements.

R4: Test cases and test data will be approved by the analysts.

Related Pages

rating: +1+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!

BlinkListblogmarksdel.icio.usdiggFarkfeedmelinksFurlLinkaGoGoNewsVineNetvouzRedditYahooMyWebFacebook

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License