10 Critical Requirements Principles for 0-Defects-Systems

This is a guest post from Rolf Götz guest voice inside Raven’s Brain.

I like Les Hatton’s view on zero defects systems. “[…] zero-defect systems, a tantalising but unattainable product of somebody's overactive imagination some years ago. The reality is this: it is overwhelmingly unlikely that any programmer will produce a zero-defect system of any complexity in their lifetime.”

Nearly all systems I have helped develop have had a large number of defects found both during acceptance testing and while operational. Just last week a good friend told me that within 30 minutes he had found three major defects in a system that has been operational for almost 5 years now, just by playing around a bit, not by looking for defects. Several hundred defects per release still in operational software are not that unlikely, I dare to say.

As esoteric as this might seem to you, it is actually possible to build non-trivial systems with (close to) zero defects. It might be “overwhelmingly unlikely”, yes. I had the luck to be part of an “overwhelmingly unlikely” system development. We detected a mere 5 (five) defects in total during 10 years repeated user acceptance testing. The system still works with no interruptions and obviously perfectly according to the requirements. (It is a multi-user database system with about six releases over the ten-year period with strictest requirements on data integrity and data availability).

These are the five principles we (un)consciously followed, as we found out in a Lessons Learned earlier this month. I added principles P6-10 because of recent and not so recent experience in other projects. However, following these later principles (and ignoring the principles P1-5) did not lead to zero-defect systems. I guess all these principles represent useful not sufficient conditions. After all, this is anecdotal evidence.

P1: Customers and software developers who like each other.
P2: Small and easy scope of your requirements, increasing in small steps.
P3: High-value requirements are the initial focus.
P4: Acceptance criteria are paramount.
P5: Templates rule.
P6: Quality control for your requirements and detailed designs (inspections).
P7: Top management's requirements (aka objectives).
P8: Problems first (then the requirements).
P9: Performance requirements first.
P10: Replacing requirement-based estimation with planning.

Let’s look at them in greater detail.

P1: Customers and software developers who like each other.

Notes:

• If I was asked to give just one piece of advice, this would be the one.
• This is more than just 'successful communication'. You want to have a climate of friendship, at least almost. You should feel you can happily go the extra mile for peers, because they would do the same for you. When it comes down to written requirements, everybody helps improve the specification, and forgives the one or other mistake that invariably occurs when you try to be very precise, complete and so on.
• While it might be easier and faster to attain that level of collaboration if the whole team is co-located, it is possible to do this in distributed projects. The database-project mentioned above had the team spread over four different cities with meetings only every other month (but lots of phone calls :-)
• See the highly useful Dialogue Mapping technique for how to develop and save discussions
  'People are the most important asset to a project' is advice you hear every other day, so please stop thinking about tools, processes, rules (in this order :-)

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

Notes:

• This follows from the ever-so-important quick-win principle. You will have a better chance to gain credibility and therefore get more or additional budget.
• Think hard about how much project ressources you are willing to risk on a user-tested release. Literature suggests a mere 2%, including project schedule. There is immense detail on evolutionary project delivery in Tom Gilb's book Competitive Engineering, his web site and also at Niels Malotaux’ website.
• Also see Shewhart’s and Deming’s PDCA Cycle
• Only do detailed planning a few steps ahead. Take advantage of expectable learning as you implement what is most obviously valuable first.

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).

Notes:

• Chances are your stakeholders will be satisfied early. Remember, usually it is hard for stakeholders to define priorities, so help them . Strict prioritization will also help you by pushing requirements down the list that otherwise would have caused headaches to the software developers (uh, if this also is high priority, I will have to design a much more complex solution…)
• This also leads to the single most effective approach to fitting a project in a tight schedule: DO LESS. Leave out everything that will or might be superfluous anyway. This far more effective than throwing people at the project, hoping for the best, going for it, moving the deadline or any other ‘strategy’ that has proven to be non-functional in most cases.

P4: Acceptance criteria are paramount.

Note:

• I found the criteria to be useful almost to an extent where I no longer care much about the requirement itself. All the necessary details and effort towards clarity, precision, completeness … go into the acceptance criteria. The requirement becomes the gist for the acceptance criteria.
• If you write requirements in Planguage (pdf), they have acceptance criteria 'built in'.
• It helps attain testability. It beautifully integrates with test-driven development.
• During acceptance testing, you will debate over acceptance criteria - not requirements - anyway :-)

By Rolf Götz. Part 2 will follow soon with the remaining 6 Critical Requirements Principles for 0-Defects-Systems.

---

Thanks to Rolf Götz for this great piece on zero defects. Rolf wrote a guest post at Raven's Brain v1.0: Heaps of Risks (Why Managing Too Many Risks is Too Risky) that received a great response, and I've no doubt that this post will be equally informative and useful to people managing projects in the real world. Here is more about him:

In my department within the Corporate Center of Deutsche Post World Net (the world's third-largest employer that does logistics worldwide) we support the development for the MAIL-Operation's IT systems. My area of work there concerns projects and systems of the Delivery subdomain. This subdomain comprises about 10 larger IT-Systems with a total of about 40,000 users. Example projects include optimizing mail sorting, mobile devices for postmen and drivers, delivery route optimization, staff employment planning and datawarehouses. We spend 1 – 10 million EUR / yr. and project (mean close to 2), use 5 – 30 internal staff per project (mean close to 10).

I support 10-12 projects at a time, playing the roles of BA, Requirements Manager and Business Consultant for internal customer's projects. Before I joined DPWN I worked as a consultant in a company spezializing in requirements engineering and system engineering. The subject matters I worked on range from air traffic control to aircrafts to weapon systems to medical systems to health insurance to logistics. I guess my experience in software industry of more than a decade now make colleagues ask me for expert advice every now and then. That's why I started my ClearConceptualThinking.net weblog with almost 100 no-fluff-just-stuff checklists on requirements, systems and projects.

Tags: Technology and Business, Software, 0 Defects, Zero Defects, Requirements