An Active Structure Approach

to

Requirements Elicitation

Abstract

An overview of the Requirements Elicitation problem, emphasising its difficulties, is followed by a description of the Active Structure approach to generating and maintaining complex specifications.

Introduction

Requirements Elicitation might be described as eliciting a specification of what is required by allowing experts in the problem domain to describe the goals to be reached during the problem resolution. This being so, we may be limited to having a vague desire at the beginning of the process, such as "We want a new aircraft carrier", and at the end of the process having a detailed description of the goals and some clear idea of the steps necessary to reach the goals.

There are several things wrong with this description. Where does the logical model reside - in people’s heads? Is there an expert with sufficient breadth and depth of domain knowledge to ensure the goal and all its subgoals are consistent and achievable? If there is not, are we merely leaving to the design stage the process of systematising the subgoals. It is very likely that many goals will be inconsistent, even deliberately contradictory. Can we say the Requirements Elicitation stage is complete while this is so? We certainly can if our methods for supporting the elicitation have no means of establishing the consistency of the goals, or even describing many of them. How precise do we need to be in specifying our goals. Is there anything left to do in the design stage, or have we gazumped it by not having a method of description that permits variability in the requirements.

Let’s use an example of a helicopter. Before the first helicopter had flown, and people had become familiar with its performance envelope, how successful would requirements elicitation have been in eliciting a consistent and achievable set of goals. An airborne vehicle which could hover, move up, down, sideways, even backwards. The models in people’s heads would have veered among : a hot air balloon, a hummingbird, a hovering hawk, a winged craft of the time, like a DC3. Until at least a rough performance envelope appeared, to shape and limit what people thought, requirements elicitation would have been unlikely to have been successful if it had relied only on the users (what users?) to provide a consistent mental model. Does it turn out that Requirements Elicitation only works well when people know almost exactly what they want, and hardly works at all when there is significant design required to move from a concept with very hazy boundaries to an object within the limits of current or very near-term technology.

Let’s go back to the aircraft carrier. It’s 20 years since we built one. How do we gather experts in the design, building and use of such an object. Are the mental models of at least some of the experts mired in the past, in terms of ship propulsion, low speed abilities of fighter aircraft, weapons systems command and control, vulnerability to attack? We can mix in experts in new fields with no integration experience, but how to get a consistent mix of old and new? One way is to build an Active Structure as we gather requirements. Some typical requirements:

Are there requirements, like why are we building it, we won’t attempt to formalise, or even mention? Will requirements that no-one chooses to mention bring the project down later on? How far will we go out into the larger system of which this is a component to understand and validate the decisionmaking?

The area receiving most attention for the use of Requirements Elicitation is software systems. We do other types of complex system badly, but their physical reality restricts the grossness of the errors we commit. Software systems can be more complex than any other system we attempt to build, but our difficulty in visualising their behaviour can lead to the grossest design errors. Even if we do them well, their nature allows a good idea to radically alter the topology of their structure, invalidating much of the analysis that was supporting them.

The end result of eliciting requirements needs to be a compromise among competing requirements. Everyone in the group may wish to have a voice, but this may leave us with a mishmash, disenfranchising those who are not present at a later point where consistency is enforced. The sooner we can impose some discipline on the requirements, the sooner people are pushed to expose what it is they really need. A way to do this is to ensure we do not allow inconsistent requirements to propagate in parallel for very long. The longer they propagate, the more elaboration, consensual agreement and frozen structure around them, the harder they are to root out. A planning system which makes no attempt to model consequences of decisions contributes to the management problem by allowing user experts to build expectations on poor foundations.

Imposing a Structure

There have been many attempts to impose some particular structure on the high level planning process. The chosen structures are often those that people happen to be familiar with, whether or no they are relevant to the problem - from decision trees to expert systems to object oriented hierarchies. While it is certainly worthwhile to systematise what we do, the imposition of a structure which is rigid can drive the planning process in undesirable directions. As example, a rich and detailed hierarchy for motor vehicle design may be specifying the glove box material before the engine placement or even type is decided. The apparent rapidity and completeness of the design process masks the fact that the design was already implicit in the structure we adopted - that is, no new design above the trivial level can occur because cross connections are not permissible in the hierarchical structure. Successful designs come from a rethink of the requirements to avoid what seems necessary but is not, or a realisation that new materials or configurations or processes are economically viable - a nonstick frypan, an east-west engine, the cellular phone. The topology of a logical model of the requirements is so fluid in the early stages of specification that any attempt to impose an alien structure is doomed to failure.

It may be that the requirements elicitation process is of its nature limited to copying an existing design or choosing among a few well known alternatives. Then a simple predetermined structure may be possible. Even here, the structure will need to adapt as competing requirements are compromised out. In all but the simplest cases, the variability in the topology defeats rigid preconceived notions of a directed decision structure, because there is no stage to which we may not be driven back in the search for a solution. There is a structure, the structure of the relationships that make up the problem. Using it may require us to think more flexibly than we might like, because nothing is certain.

The Planning Spectrum

The initial requirements starts at one, "We want a new carrier", has some outline by the time the number of requirements is ten or fifty, and the final detailed requirements might number fifty thousand, and require continual maintenance through the entire planning process. What method is available to support the move from one end of the spectrum to the other, or at least to the point where all variability has gone? Do we need a tool for Requirements Elicitation, another for high level design, another for monitoring development. All of these steps are affecting the requirements.

In the later stages we may not be able to handle the sheer weight of detail in a flexible way, but that does not mean we cannot handle the control aspects with the same tool that supported the RE step. In the diagram, we are ignoring the step before Requirements Elicitation, the step that added the proposal to the program in the first place. Planning support can extend back to encompass this stage as well. At each stage boundary, we are passing across, and can pass back, a web of constraints on what is proposed at the particular stage.

What Are The Requirements

Why not elicit the requirements for the Requirements Elicitation process?

We would like to build a logical/existential model as we go, with continuous Truth Maintenance so inconsistent requirements are weeded out as soon as possible.

We need a language of approximate discourse with designers and other stakeholders. We want to tell people where we would like to be on the cost/capability curve, not screw everything down to precise values that take on holy writ, then turn out to be unachievable or wrong.

We should be able to quantify things, but may wish to approximate, so a range can be accepted and used for computation of alternatives. We might be specifying integers, 40-70 aircraft, or real numbers, 123.3-140.7 tons of fuel per hour.

Not everything we want to specify will be analysable - sometimes it will be preferable to use stochastic methods of specification instead of researching relationships, sometimes we will have no choice. We should be able to smoothly integrate analysis with piecewise approximation and probabilistic methods.

What structure should we use? Why not just use the structure of the requirements, because any other structure will either be restrictive, or we will need to change it as we go along. Adding requirements changes the topology of the structure. If we choose to link aircraft numbers to hull speed, that is what we want. There may be a carrier solution with 40 planes and fifty knots, as well as the conventional solution with 75 planes and 20 knots, but we want to rule out 40 planes and 20 knots.

We may wish to hinge one requirement off another or link them together in some way, if this then that, but still at the tentative stage, exercising logical or existential control over one or more requirements by outcomes of other requirements, and vice versa.

The requirements may start off planar, a few scribbled on a whiteboard, but will rapidly develop a layered structure, where subgroups of experts are defining requirements for reasonably independent components. The highest level requirements that we are working on may well turn out to be a component of some even higher level requirement (someone has to sell the acquisition budget, of which our carrier is a part), so the language of requirements description should permit unlimited layering, both up and down from where we notionally started.

We should be able to link across components from any level to any level. There is a weak form of inheritance in the structure - the propulsion inherits the weight and the hull shape, but in most cases the inheritance is circular - the weight is assumed to be in the range of the proposed propulsion. It is the long range connections among largely independent entities that are the most valuable to describe, as they are likely to be least understood by experts in the particular specialty.

We would like to start with one requirement and reach tens of thousands. As the outlines firm up, we want to keep the potential variability in the components. Occasionally we will need to back out of a dead end, where what we thought possible is found not to be so within the cost/time frame allowable. That means requirements that have long since been frozen anywhere in the overall specification may need to become as malleable as they were at first, while we search for another consistent configuration to which to jump. This is typical of design - there are small islands of success in an ocean of failure.

Time and money are fundamental requirements, just as much as speed and range. Their specification should not have the rigidity of conventional project planning methods, certainly not while we are determining whether an outcome is even possible.

The requirements should encompass everything that will lead to success or failure, and allow a wide range of stakeholders to see that their requirements are influencing the outcome.

The Network Approach

A logical network (we mean a network combining logic and existence and time) of analytic operators acting as undirected agents would seem to meet all of the requirements stated. This assumes that analysis of the requirements is worthwhile or even possible. Some of the requirements will not be analysable - they may still be modellable in an analytic system, using approximation methods.

The structure of the logical network comes only from the structure of the statements used to represent the requirements. The statements link objects through analytic operators under logical control. A seemingly simple change to the requirements can drastically change the topology of the network by causing two objects in logical space that were notionally far away to be adjoining, just as it can completely recast the structure of the requirements.

The statements in the logical network can be seen as constraints - that is, after all, what requirements are. At an early stage, there is no sense of solving the constraints, but there is a sense of reasoning about them. The statements are more than just constraints, they form a web of logical control over what is being described. Statements can also add two numbers together to get a third, that is, they are extensible into areas that are not constraints. If we attempt to maintain consistency of specification with a paper-based approach, we rapidly get inconsistencies creeping in, someone or something else having to attend to all the connections.

Numbers in the network can be represented as singular values or ranges, either of integers or reals, and these ranges can be propagated through the structure and used for calculation or logical reasoning.

Time and money can be represented in a flexible way, using ranges and logical control of variability. Alternatives and contingencies fit easily into the network structure, just as they should in any well thought out set of requirements. [1].

Layering of Knowledge

Every field of knowledge has its specialties - whether medicine, aircraft design or physics. There are areas which are largely independent, but still need a few connections to other specific areas or to general facts. This problem of structuring knowledge in shells might be shown diagrammatically as

There are conduits at interfaces, the surfaces of these shells of knowledge, with still a need to penetrate the shell for a more detailed connection, one that had not been thought of when the boundaries of the particular knowledge were established. The boundaries keep changing as the knowledge contained in the shells changes - too many intrusive connections and the boundaries need to be re-established to minimise intrusion on the specialist knowledge, but intrusions there will be. For a detailed specification of a complex entity, fifty levels of knowledge shelling can be easily reached.

The environments in a logical network provide unlimited layering, while retaining the ability to connect in an undirected way across any boundary.

Conclusion

Requirements Elicitation demands flexibility of description.

The undirected logical network of Active Structure can provide support across the stages of Requirements Elicitation, high level design, development, manufacture. It can do this because it uses the structure of the problem, not some preconceived directed structure. The lack of directionality in its connections allows anything to be the current subgoal of its analysis. The undirectedness provides Consistent Reasoning, that is, maintenance of consistency, throughout the structure. The network propagates messages to operators which can change the topology of the network and show the results of decisions and new requirements at every stage of the planning process. It appears to be an appropriate support tool for any phase of high level planning.

The Next Step

Requirements Elicitation can be extended to the reading of text - this allows people to describe, in a flexible way, exactly it is that they require. The machine converts what it reads into a form capable of extension by other text, and it becomes capable of checking for validity among several descriptions at different levels of granularity - see The “Swing Space” – Understanding the meaning of a complex paragraph (the example is for property leases, the principle is universal). There is a cost for preparing the machine to read in a particular domain, but where the cost of what is described is in the many millions or billions, this cost is trivial.

Technical Papers

Related Areas

Synthesis Management
Program Management
Project Management
Requirements Management