Bleach & Soap 1: Magic Bullets 0

or, what Requirements Analysts really need to do

The American Journal of Tropical Medicine and Hygiene allegedly recently reported a major success -- a 71% reduction in a major killer disease among children (2 million deaths per year) in a trial area, using two chemical preparations: sodium hypochlorite, and a mix of stearic, palmitic, and oleic acid. Or bleach and soap as experts prefer to call them; the killer disease was diarrhoea. Glamorous? Hardly. Effective? Certainly, but people seem to prefer magic bullets to scrubbing floors and washing hands.

Bleach and soap have the following very dull characteristics:

  1. unexciting
  2. older than God (well, almost)
  3. cheap
  4. yes, they work
  5. no short cuts, you get down and scrub
  6. no special tools needed
  7. and did I mention that they work?

What are the RE equivalents of soap and bleach, plain things that are known to work? The RE equivalent of magic modern drugs that will abolish infectious disease within 5 years is unfortunately all too easy to identify; it makes a fine pub game. But if you prefer practicality to fashion, here are ten simple things that certainly do the job.

Find out and document (as simply as you can manage):

  1. the mission & scope
  2. who the stakeholders are
  3. their goals
  4. how those goals conflict
  5. scenarios to deliver those goals
  6. requirements to get those scenarios
  7. justification for each requirement (why it's needed)
  8. assumptions underlying the requirements (existing systems, interfaces, competition, market, risks, etc)
  9. agreed priorities on the goals/ scenarios/ requirements (to resolve the conflicts) – this means review (I told you this wouldn't be exciting)
  10. acceptance criteria for the requirements (how you know you've got what you asked for).

All of these can be written down with nothing more elaborate than a whiteboard, or a pen and paper. They can, if things get large and complicated, be written down using RM tools, or modelled in more elaborate ways. The point may be worth labouring, if only to emphasize that further research is NOT needed – the bleach works just fine, thankyou, as long as you scrub the bathroom with it regularly. So here is a table showing how the ten things might look on small and large tasks.

Requirement Element

Activity
on Simple Project

Activity
on Complex Project
Mission &
Scope

write one statement, draw a context diagram

characterise the mission, draw a context diagram, agree it at the top (political) level across all decision-making stakeholders
Stakeholders

list them, maybe using a template

make an onion model; identify roles in each slot
Goals

list the goals, maybe make a hierarchy using Word outliner

make a goal model, indicate and/or decomposition, show support and obstacles (+/-)
Conflicts

list any conflicting goals, disagreements

classify conflicting viewpoints from the onion model, possible goal conflicts from the goal model by type and seriousness
Scenarios

write the essential operational scenarios as basic stories

create a set of scenarios at each level (business, system down to sub-sub-…system as appropriate); possibly structure them as use cases; consider negative and hostile scenarios, and counter them
Requirements

write a list of things the contractor /supplier/ programmers etc have to make the system do (and don’t forget required qualities and constraints)

write and organize the requirements into a suitable structure, including functions, interfaces, qualities, and constraints; model the required behaviour to demonstrate its correctness and feasibility; trace back to goals and scenarios; allocate to suppliers / subcontractors etc
Justifications

write a few words justifying each requirement

make a cost/benefit model, simulations of performance, etc as needed to justify each requirement
Assumptions

list things that have to be true for the system to work

model the argumentation for and against the system, including but not limited to its safety case, showing assumptions, evidence
Priorities

rank the requirements into vital-desirable-nice to have (or 1-2-3, etc). Do the vital ones first

identify dependency classes (eg requirements involved in the same scenario); prioritise each dependency class; trade-off requirements against design options, etc
Acceptance
Criteria

identify how you’ll know when the system meets each requirement

as for the simple project, but also plan the test campaign based on the scenarios and the environmental conditions and non-functional requirements; trace the test cases to the requirements

There’s nothing terribly new here, is there? But it isn’t soft scented soap; it’s more like the hard, old-fashioned blocks of ‘Savon de Marseilles’ that granny used to grate into the washing-bowl, than anything fancy from a chic boutique. Does your chosen gadget reach into all those germ-harbouring corners? It’s interesting to take a patent RE method or two and see how many of the ten simple things they don’t even consider. Try it.

It’s also instructive to consider what happens when any of the ten simple things are overlooked.

  1. No Mission & Scope? The scope steadily enlarges; the project zigzags from one possible purpose to another. Until it falls over.
  2. No Stakeholders? Whole chunks of requirements are missed, only to be expensively inserted later; or else the project fails.
  3. No Goals? The requirements are a disorderly unstructured ragbag, probably full of contradictions.
  4. No Conflicts? They’ll turn up later, at the most awkward moment, just as the project is running out of time and money.
  5. No Scenarios? The system is probably unusable; it either never gets accepted, or it is shelved immediately on delivery. Even if the needed functionality is in there somewhere, it’ll never work the way anybody wants it to.
  6. No Requirements? Hrrm. You’ll build the wrong thing. You’ll have done that which you ought not to have done, and you’ll have left undone that which you ought to have done, and there’ll be no health in you, miserable offenders. Amen.
  7. No Justifications? You’ll probably build a whole lot of pointless features into the system because someone thought them up over coffee. You’ll have made a whole lot of assumptions that seemed obvious to you but were invisible to your customer; and the users would at once have told you were wrong, if only you’d stated them.
  8. No Assumptions? You and everybody else have certainly made some, and as the old business modelling joke has it, each one you make helps to make an ASS of U and ME. Assumptions are at their most dangerous when tacit, as everybody can then suppose that everybody else shares their assumptions (a particularly unlikely Utopia). In smarter language, any broken load-bearing assumption causes a failure.
  9. No Priorities? Either the hard men will just chop your favourite requirements when the cash runs out, or they’ll chop the whole project. You’ll wish you’d make the real priorities clear from the start, and completed the vital bits before the axe fell.
  10. No Acceptance Criteria? You’ll have a whole lot of wishy-washy suggestions that won’t be testable in place of requirements. You won’t know when the project is complete, so contractual wrangling is likely. It’ll end in tears.

There. Told you it would be old-fashioned. Or would you prefer some lilac-scented management consultant-talk about endogenous quality-building and total responsibility-driven design going forward, in fact the last thing in soft soap?

© Ian Alexander 2005

Other Articles