Requirements engineering: seven tasks, one bridge

An action, not a phase

Requirements engineering is the whole spectrum of tasks and techniques that take you from somebody wanting something to a defensible understanding of what the software must do. Notice the category: it is a major software engineering action, one that begins inside the communication activity and continues into modelling. It is not a document, not a job title, and not a box that closes before design opens.

The metaphor worth keeping is a bridge. On one bank stand the stakeholders and a business need; on the other stand design and construction. Requirements engineering is the span. Walking it slowly is what lets you see four things you cannot see from either bank: the context the software sits in, the specific needs design has to satisfy, the priorities that decide what gets built first, and the information, function and behaviour that will shape every later decision.

The arguments for skipping it are seductive because each contains a grain of truth — things do get clearer as you build, stakeholders really do understand a requirement better once they can prod a running increment, and requirements really do change. None of that excuses you from the work. It tells you to do the work iteratively, sharing information with stakeholders as you go, rather than once and up front.

The seven tasks

1. Inception — establish a basic understanding of the problem, of who wants a solution, and of the nature of the solution wanted. Communication between the team and the stakeholders is set up here.
2. Elicitation — draw out goals, objectives, constraints and day-to-day usage from stakeholders. Sounds like asking; is not like asking.
3. Elaboration — refine what you elicited into a model of the system's function, behaviour and information. Driven by user scenarios; each scenario is parsed for the classes it implies.
4. Negotiation — reconcile the conflicting and over-ambitious. Stakeholders rank requirements, costs and risks get assessed, and requirements are cut, merged or modified until every party gets some satisfaction.
5. Specification — write it down, in whatever form fits: a document, a set of models, usage scenarios, a prototype, or some combination. Formality tracks size and complexity, not fashion.
6. Validation — review the result for ambiguity, omission, inconsistency and unachievability. The instrument is the technical review, and the review team includes the customer.
7. Requirements management — identify, control and track requirements and the changes to them, for as long as the system lives.

What the list hides

Two things. First, the boundaries are muddy and some tasks run in parallel — expect to do a little design during requirements work and a little requirements work during design. Second, requirements management is not the last stage; it is a continuous activity with the same machinery as software configuration management. Drawing it as step seven of seven is the single most common way to lose a mark on this topic.

Worked example — BorrowBox, from one sentence to a specification

BorrowBox begins as a sentence from a neighbourhood association: people should be able to borrow tools without anybody having to staff a counter. Inception turns that into a problem statement, a rough scope (power tools, one depot, smart lockers) and a list of who to talk to. Elicitation produces goals — a member should get a tool in under a minute, the depot should know where every tool is. Elaboration turns the goal into a scenario: reserve in the app, scan a one-time code at the locker bank, take the tool. That scenario implies Member, Reservation, Tool and Locker. Negotiation kills the waitlist feature for release one because the association wants an opening date more than it wants queueing. Specification for a system this size is a short document plus the use cases and a class model. Validation catches that the locker must open quickly has no number in it, and it becomes within three seconds of a valid scan. And management is what handles the change, six weeks later, when the locker vendor's firmware makes three seconds expensive.