Rationale models show how project requirement elements which have often been seen as disparate and unconnected – like goals and assumptions – make much more sense, and are far more useful in planning and decision-making, when put together.

Other elements such as scenarios have similarly long been used to explore options, to define operations, and to assist with user interface design. More recently, scenarios have appeared in new forms including the use case and the user story[i]. The deep similarity of these approaches is obscured by their diverse names – vignettes, operational scenarios, concept of operations (ConOps), concept of use (ConUse), task model and so on; and by the fact that each name and approach belongs to a separate community with its own historical background, professional skills, training, and literature. So, do not be ashamed if you have never heard of many of the scenario types just mentioned.

To take a quite different example, two of the qualities (attributes of a product or classes of requirement other than functions) that everyone agrees are necessary are safety and security. Just like the subcontractor writing the risk register in lonely isolation, the safety and security teams often work in magnificent ignorance of each other’s efforts. But as Donald Firesmith never tires of pointing out, the two are almost mirror images of each other:

·         An attacker creates a security threat, which is countered by requirements for appropriate security measures.

·         A possible failure creates a safety threat, which is countered by requirements for appropriate safety measures.

Of course the languages differ radically, but the two things should fit together. For example, if a military enemy breaches your security, your safety is directly threatened. It makes no sense for the safety team to identify certain hazards, and to specify certain functions to mitigate those; and for the security team to identify certain attacks, and to specify an overlapping set of mitigating functions.

The safety/security example throws light on another traditional argument in RE: functional and “non-functional” requirements. There is essentially just one (quality) requirement actually FOR safety or security or survivability or reliability or comfort or what have you: the system shall be safe enough, secure enough, etc.

There are many ways that a simple quality requirement works out in a system as designed. For example, jet engines have a reverse thrust mechanism (a function) to help aircraft stop safely when landing (Figure 2).

But it would be disastrous to deploy a thrust reverser in flight – there was a fatal crash with just that cause over Thailand some years ago. So an additional function puts away the reverse thrust mechanism if, somehow and against all intention, it has wrongly deployed itself while in flight. Can you see what is happening? A “non-functional” safety need has been translated into a function, which creates a safety hazard, which is mitigated by a further function to restore the required level of safety. By the way, it is really time we dropped all talk of non-functional requirements – it is a ragbag at best, a chaotic muddle at worst. Functions and qualities always dance together. So do requirements and design, as this example also suggests.

So if functions and qualities go together, while other elements such as scenarios, goals and rationale are admitted to have some value, how do they all fit together? Informally, the relationships between different elements are not hard to state. For example:

·         Each Goal should be owned by a Stakeholder

·         Each Goal should be prioritised by a Priority

·         Each Operational Stakeholder should play a role in at least one Scenario

Other elements like scenarios and interfaces may not seem to be so obviously connected. But an interface is where a system’s behaviour becomes visible to the outside world. If we take the admittedly very simple view that what happens at an interface is a boundary or business event that either comes from outside into our system, or is produced by our system and goes out from it into the world, then we can state a simple pair of rules:

·         Each Incoming Boundary Event triggers an end-to-end Scenario (which handles that event)

·         Each end-to-end Scenario produces an Outgoing Boundary Event (in order to have a visible effect on the world)

A use case, you will remember, is supposed to be just such an end-to-end scenario with respect to whatever system (or subsystem) is being defined.

If we continue in this way we arrive at a metamodel, a picture of how the elements that projects may need to build a consistent specification all fit together (Figure 3).

Figure 3: a Metamodel for Requirements Discovery

Of course there are other answers to the question “how do requirements fit together?” – such as, through prototyping and product evolution, by teamwork, through interviews and workshops, by studying project documentation, by modelling goals and so on – and those naturally form much of what Discovering Requirements is all about.

But a metamodel does put RE in a fresh light. Requirement discovery, it says, is the process of building up a single consistent model – in your head, on paper, or using modelling tools – of a system, a product, a service or a business. That model may vary enormously from one project to another, but certain questions will always be relevant, it asserts:

·         Who are the stakeholders?

·         What are their goals?

·         How do those goals co-operate or conflict?

·         What obstacles and threats are there to the goals?

·         How will we mitigate or overcome those threats and obstacles?

And so on through all the element boxes and relationship arrows of the metamodel.

The metamodel does not assert that every element is of equal importance; nor does it say anything about how much effort you should put into any particular element on your project. It may be, for example, that the goals on your project are so few and so simple that it is really not worth spending time on them; while on another project, debate on which goals are really important may rage through one critical trade-off decision after another.

It may be, though, that the elements depicted in the metamodel are quite often of some relevance to projects. If so, it would be a pity if projects continued to focus almost entirely on just one or two of the elements, such as functions and (use case) scenarios.

And perhaps we are just starting to glimpse the outlines of what an RE Body of Knowledge might look like.