10 Critical Requirements Principles for 0-Defects-Systems Part 2

Another guest post from Rolf Götz, guest voice inside Raven’s Brain.

Here is the second part of Rolf's article: 10 Critical Requirements Principles for 0-Defects-Systems.

To refresh your memory, the 10 Critical Requirements Principles for 0-Defects-Systems being discussed are:

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.

P5: Templates rule.

Notes:

• According to dear Dan Berry of Waterloo University, Canada, there's a pain in every approach to software development. In the sub-discipline of requirements engineering that pain is actually writing a large spec. Don't write a large spec. Write a brief general plan and more detailed single phase plans for four to ten high value improvement increments. Add more detailed plans as earlier ones are completed.
• Use initial requirements, especessially if there are more than ten or so, only to develop goals. Ask stakeholders for the business purposes of each requirement and list them. Use the top ten business goals to decide which phase to implement next.
• Using the Dryfus Model’s levels of Skills Acquisition especially the advanced beginners benefit from templates. I found these people to be the most common ones in our industry. Templates, also known as patterns, should be developed and maintained carefully as they are invented and reused; design them for easy reuse.

P6: Quality control for your requirements and detailed designs (inspections).

Inspection DEFINED AS a method of process control through sampling measurement of specification and design quality.

Notes:

• Inspections are the only known method with scientifically proven effectiveness (http://www.resultplanning.com/). However, expect to find only half of the defects. You will have to look for the remaining half elsewhere.
• Think about using inspections not to 'improve' the specification, but the person who wrote it. This facilitates self-reflection, a way of learning of which there also is scientific proof of high effectiveness (<- D. Doerner. The Logic of Failure). A well trained author who is aware of the mistakes he tends to make is more valuable than a clean spec.
• This also helps building the team.

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, the most important stakeholders

Notes:

• Make sure you (and top management) understand the objectives. To me, this is even more vital than the standard 'know your stakeholders'. If we like it or not, management is the institution that declares (sic!) success or failure (in case you live in an organization that does know the word 'failure').
• It may well be that top management wants happy users, but I would guess that in 6 out of 10 cases they don't really care (uh, that hurt!).

P8: Problems first (then the requirements).

Notes:

• Very rarely done: Specify PROBLEMS from the stakeholder’s perspective, NOT the requirements they give you. This gives the software developer the maximum freedom to find a good solution.
• Don't be fooled: like requirements you can state problems in various levels, even down to solution-level. Besides giving a new perspective, 'problem' is just a word that does not (yet) suffer from meaning-overload.
• Consider using business modelling to obtain the right understanding (<- Haim Kailov. Business Models: A Guide for Business and IT). By the way, an engineer distinguishes herself from a craftsman by using models.

P9: Performance requirements first.

Performance requirement DEFINED AS A specification of stakeholder requirements for ‘how well’ a system should perform

Notes:

• The higher up the abstraction level you climb within your spec, the higher the percentage of qualities will be. Example: quality 'high customer throughput' vs. mere functions like 'reserve a seat'. If you start with quality requirements, your functional requirements will fall into place a level down.
• Stakeholders usually want a problem to be solved, not use a function. Unfortunately IT folk have quite successfully brain-washed normal people ;-) with a reliable answer reflex, obstructing the door to satisfaction of real needs.
• Many Business analysts are a little shy when it comes to high-quality quality requirements (sic, aka good non-functional requirements). No need to. Go learn Planguage.

P10: Replacing requirement-based estimation with planning.

I. e. use some capacity throughput metric and promote the concept of variation and fluctuation.

Notes:

• While there are a number of relatively reliable prediction methods, it is at least an order of magnitude more reliable to use actual data from your organisation and your team. Even if your plan does not come true you will come away with two things:
  
  1. You learn something and you can update your empirical data.
  2. You don't put a large number or far-away date in your manager's head (but you will have to convince them to just trust you for a little while.)
  
• This advocates short iterations (remember that you don’t have to release software every cycle!), in order to provide you with hard data about your or your teams velocity use surragate users in house, instead of a full distribution release.

If you are a project manager, business analyst or a method-savvy person in general, read more about projects, systems, requirements and ways of incorporating real-life models into daily work at my blog at http://http://www.clearconceptualthinking.net/

Thanks to Sven Biedermann and Dick Karpinski for commenting the first draft of this post.

By Rolf Götz.

---

Thanks to Rolf Götz for another great article. You can learn more about him at his blog ClearConceptualThinking.net.

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