Rationale means simply recording the reasons for a decision, such as to include a requirement in a release (see Prioritisation).
Rationale can be expressed in various ways, which have differing advantages. It is often worthwhile to use a combination of techniques.
Rationale has several purposes:
| Technique | Purpose | Suitable Tools | Procedure | Risks |
|
Text (Attribute or Field) |
Describe reasons for a requirement in words | Spreadsheet, Database, RM Tool | List the reasons for each requirement in a database attribute or field alongside the requirement text. | Duplication and cut-and-paste repetition (making the requirements boring to read), then failure to update all copies of a reason, leading to inconsistency. |
| Set of Traces (Traceability) | Link requirements to goals or higher-level requirements (nearer to the business), so as to justify them implicitly | Database, RM Tool, Hypertext Tool; Traditional Cross-Reference Matrix (with care) |
1) Agree the simplest Traceability scheme (see generic
Information Model --
take from it only what you need) that will work for your project. 2) Trace each requirement back to its origins with database links/hyperlinks/cross-references as appropriate. 3) Construct a view that shows the origins of each requirement. |
Failure to allow for the additional effort
involved in creating and maintaining a consistent set of traces, in
devising the information model, setting it up, and training people
to use it and the tools.
Reluctance among older / less technical project members to adopt a new tool / approach. |
| Rationale Diagram / Model | Explain arguments for and against the requirements / design decisions graphically. |
Basic Diagramming tools (eg Powerpoint, Visio); Software Modelling
tools (eg for UML); Rationale tools (eg Compendium) ScenarioPlus Rationale Model (in Diagrams toolkit for DOORS users) |
Draw a box for the conclusion and for each reason for or against it.
Label each box with a brief text. Draw an arrow from each reason to
each box it supports (label with +, green) or weakens (label with -,
red).
It is often helpful to split the diagram in half with a horizontal line. Put arguments FOR above the line, and arguments AGAINST below the line. Note that this kind of diagram shows thinking moving forwards or bottom-up from facts / Assumptions to conclusions. |
Reluctance to use diagrams or models of any kind: a belief that requirements must be pure text. |
| Goal Diagram / Model | Show graphically how the requirements come from agreed goals and objectives. |
as for Rationale Diagrams ScenarioPlus Goal Model (in Diagrams toolkit for DOORS users) |
Draw a bubble for each goal. Place the business' top-level
objectives at the top. Place goals that support those objectives
beneath them. Draw arrows between bubbles to show support (+) and
conflict (-).
If need be (optionally) show alternative subgoals eg by labelling with "OR" and joining their arrows with an arc of a circle. (It's also possible to use UML classes with subtype arrows (for OR) or composition arrows (for AND), but the syntax and semantics are tricky: and see Risks in the next column.) Note that this kind of diagram shows thinking moving backwards or top-down from Goals to subgoals. |
As for Rationale diagrams.
Reluctance among non-software people to use diagrams and techniques that seem to come from the world of software / computers. People may feel excluded by clever-looking diagrams, especially when as with UML these come with elaborate syntax and semantics. |
(c) Scenario Plus 1997-2007