There is an article in an edition of Requirements Engineering from earlier in the year on Obstacle Analysis. Obstacle analysis helps work out what to do when things go wrong in the course of software processes.
An example; What do I do when a person doesn’t check agreement to the terms and conditions for an online purchase?
- How do I want the system to react?
- Do I want to progress with the order or do I want to force the customer to take the appropriate action?
- What sort of message do I want to send the potential consumer?
The richer the system the more sophisticated the reactions can be.
Six sigma analysts will think of the Failure Mode and Effects Analysis (FMEA) as a method for this activity. FMEA is where you process map out the solution and look for opportunities for failure. FMEA is less effective for situations where you aren’t analysing a process. How, for example do you analyse failure/obstacles for cases?
An approach could be as follows;
- Identify goals
- Look at interactions
- Gauge failure opportunities
- Assess failure opportunities
- Define system behaviours for each failure mode
If you are looking for a diagrammatic way to represent your failure modes, or obstacles you could try using decision trees to track and analyse your options.
Another approach may be hierarchical decompositions associated to each use case. Decompositions are good because they help you keep asking the next level ofwhat if questions.
Readers, I am interested in opinions and ideas on how to best manage this aspect of requirements management. I you have some tips, please share them.