Requirements development is a collaborative activity that involves human interaction, and thereby is imprecise and frustrated. Imprecision arises from the fact that requirements gathering will involve face to face communication, that may be limited in the time available for this activity. Frustrations include lack of engagement of the stakeholders with the correct levels of knowledge or authority, politics and hidden agendas, narrow or distorted views of requirements' priorities, lack of business knowledge, lack of control of requirements change or project scope, to mention just a few.

No other part of the software development life cycle contributes to project failure as much as poorly gathered requirements. Many third party reports have gathered evidence of this, none being more demonstrative of this than the CHAOS reports that have been published in the past couple of decades.

Whether gathering use cases, or any other form of requirements, this requirements interaction and generation phase is most successful when conducted through iterative refinement. At each iteration interviews or workshops are conducted with stakeholders. The outcome of these workshops are analysed for requirement types and structures. The results are documented (in the form of use cases for the type of requirements we are considering here), and then taken back to the stakeholders for confirmation. These four activities are known as elicitation, analysis, recording, and validation.

Elicitation

Elicitation is the process of actually capturing/negotiating requirements with stakeholders. As such, the expertise lies in forming the right combinations of questions and interview or workshop techniques to be able to construct use case descriptions. Usually this process happens over three or four successive phases for each use case. An initial interview might identify the actors and goals, together with some brief outline description of the expected sequence of interactions that reach these goals. Little or no attention is paid to alternative paths, or failure modes.

After writing up a first brief description of the use cases, these are then taken back to stakeholders so that in a follow up interview or workshop the details can be confirmed or enlarged, and so that initial consideration of alternative paths through the use case can be discussed.

Subsequent workshops would see the production of what are usually termed 'fully dressed' use cases, that conform to the more rigid template for describing all facets of the use case. This is the format that the final agreed requirement will take, in the requirements documentation.

Analysis

After interviews and workshops, usually all a requirements analyst will have will be his/her notes capturing the answers to questions asked during elicitation. The analysis phase is used by the analyst to structure the results of these interviews into a standard format requirements model. From the point of view of functional requirements, this means converting the notes into use case descriptions. Naturally there are other parts of the requirements model that need to be structured: A domain data model; a list of non-functional requirements and their correlation to functional requirements that they affect; a glossary; possibly some user interface mockups.

Recording

Possibly the most mechanical phase, this involves editing the evolving requirements documentation so that the new information is written up in the correct parts of the model.

Validation

Validation closes the loop in the iterative process. The written up requirements are used to guide the design of the set of questions or activities to be conducted in the next round of interviews or workshops. The written-up requirements are then gone through with the originating stakeholders to check for correctness, ambiguity, overlap, inconsistencies, missing extra detail. Eventually, the stakeholder will be sufficiently satisfied that a use case represents all they need a particular piece of functionality to do for them. At this point that use case is ready to progress to construction of tests, code, and other documentation.

First cut use cases

The first versions of use cases should reflect the high level style initial use cases usually have. The primary path that reaches the use case goal via the most expected sequence of interactions is written down. This primary path is written informally as a simple paragraph of text. No attempt is made to capture or document alternative paths. Often, an example of the primary path might be described with sample input and output data, or some simple pictoral representations might accompany the brief use case description.

Casual use cases

Intermediate versions of use cases written up after follow-on interviews or workshops are called casual use cases. They too are written in the form of descriptive paragraphs. However, there would typically be a refined version of the the original first cut paragraph to describe the primary path. There would then typically be an additional paragraph for each of the alternative sequences of interactions that branch off the primary path, and maybe merge back onto it again later.

Often at the same time as capturing alternative paths, we would also get some vision of what preconditions must be true before a use case is allowed to run. We also capture a list of expected testable postconditions, structured into two categories: success guarantees and minimal guarantees.

Alternative paths

An alternative path branches off the primary sequence at some point in that sequence known as the extension point. In order for the alternative path to be taken rather than staying on the original path, a branch condition must be true when the extension point is reached in the sequence. For example, our primary path description and one alternative path from the coke machine use case are given below:

"The thirsty person selects their desired drink from the selection of drinks available on the front of the coke machine. The machine responds by displaying a message, inviting the thirsty person to insert coins adding up to a displayed value. The thirsty person inserts coins to this value. The machine drops the selected can of drink into the collection hopper. The system adjusts its record of inventory, and its ledger tracking the cash balance in the machine."

"When the user is inserting coins, if the coins they insert exceed the amount required to purchase the selected drink, the machine dispenses the right amount of change into the cash tray. It continues with the original sequence by dropping the selected can of drink into the hopper."

Note how the alternative path states in written text what the extension point is, what the branch condition is, and after the description of the alternative path step(s), states where the alternative path remerges onto the primary path.

Preconditions

Use cases seldom are able to run completely independently of each other. There are usually interdependencies between them, including rules on which use cases must have previously run or reached a particular step in their sequences before a particular use case is allowed to run. System constraints or other non-functional requirements may also determine when particular use cases are allowed to run.

We capture this information as preconditions on use cases. These are written into the casual use case description templates as simple statements of things that must be true for the use case to run. For example, for our coke dispenser:

"Before a drink can be purchased, the coke machine must be enabled for use at the specified time of day, and must hold stock of at least one can of one kind of drink."

Note that preconditions should be things that are testable in an implementation, not external preconditions over which the implementation will have no control. Hence:

"The thirsty person must have sufficient funds, and must be within arms length of the coke machine."

would not be examples of meaningful preconditions!

Success Guarantees

Success guarantees are outputs or side effects that are observable or testable after a use case has finished, and has reached the use case goal. These usually include of course the goal of the use case, but often include some other observable side effects or outcomes. An example might be:

"The stock level of the selected drink in the inventory should be one less than it was on beginning the use case. The ledgered cash balance should have increased by the price of the drink dispensed."

Minimal Guarantees

Alternative paths often describe controlled ways in which the actor might fail to reach their desired goal. They ensure that the desired behaviour of the machine in the presence of erroneous input sequences or other system state is implemented. Minimal guarantees are there identify postconditions that must be true after the use case is over regardless of whether the use case succeeded or failed to reach its goal.

Why do we capture postconditions?

​Recall that use cases are most of the way to being the source of test scenarios for an implementation of the use cases. By capturing the post conditions, we can further support their role as a source of test, since any tests developed can also test that the postconditions have become true once the use case is over.