10 Critical Requirements Principles for 0-Defects-Systems

Type: Principles
Sources: A 2-part article on the subject at Raven's Brain: Part 1, Part 2. Go there for more detail!
If you need a PDF, go to The Requirements Network.


It might sound esoteric to you, but it is actually possible to build non-trivial systems with (close to) zero defects. At the very least, we should try to get close to zero defects as early in the development cycle as possible, because of the relative defect removal costs (factors 1-10-100-1000, remember?).
I had the luck to be part in such a system development (a multi-user database system with about six releases over a ten-year period with strictest requirements on data integrity and data availability. We detected 5 (five) defects in total during user acceptance testing. The system still works with no interruptions and obviously perfectly according to the requirements). These are the top ten rules we (un)consciously followed, as we found out in a Lessons Learned earlier this month. I added principles P7-10 because of recent and not so recent experience in other projects. However, following these later principles (and ignoring the principles P1-6) did not lead to zero-defect systems. I guess all these principles represent necessary not sufficient conditions. After all, this is anecdotal evidence (like almost everything we know from "sources").

Principles and Notes

P1: Customer and software developer who like each other.

P2: Small and easy scope of your requirements, increasing in small steps.

P3: High-value requirements are the initial focus.
High-value DEFINED AS anything that is more important to a primary stakeholder than other things (relative definition intentional).

P4: Acceptance criteria are paramount.

P5: Templates rule.

P6: Quality control for your requirements (inspections).
Requirements inspection DEFINED AS a method of process control through sampling measurement of specification quality.
Note: There is a presentation I did the other day with detailed financial and quality data on an effort to establish extreme inspections. Amazing savings!

P7: Top management's requirements (aka objectives).
Top management DEFINED AS every manager that is higher up in the food chain than the project manager and has impact on project success or failure

P8: Goals and values first (then the requirements).

P9: Performance requirements first.
Performance requirement DEFINED AS specifies the stakeholder requirements for 'how well' a system should perform

P10: Replacing requirement-based estimation with planning.
I. e. use some capacity throughput metric and promote the concept of variation and fluctuation.



Related Pages

rating: +1+x

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


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