Use cases, negotiating requirements, and validating them

A use case is a story with an actor in it

A use case is a short, deliberately tidied account of one episode of use: somebody outside the software, occupying a named role, sets out to get something done, and the account follows that attempt from the conditions in force at the start through to the outcome. The form varies — narrative text, a task outline, a template, a diagram — but the constant is the viewpoint: a use case depicts the system from the end user's point of view, not the developer's.

Writing one starts with the actors. An actor is anything external to the system that communicates with it, and it represents a role rather than a person — one individual may play several roles at different moments, and a device or another system that talks to yours is an actor too. Primary actors are the roles the system exists to serve: they drive the interaction, touch the software directly and often, and walk away holding whatever value the function delivers. Secondary actors are the ones the system leans on to make that possible — they supply or absorb something on the primary actor's behalf and would have no reason to be in the story otherwise. Because elicitation is evolutionary, you will not find every actor on the first pass — that is expected, not a failure.

With the actors named, a use case answers a standard set of questions: who the primary and secondary actors are, what the actor's goal is, what preconditions must hold, what main tasks the actor performs, what exceptions might arise, and what information the actor acquires, produces or changes. The fuller template that formalises those answers belongs to the next module.

Negotiating to a win-win

Requirements engineering rarely ends with everything everyone asked for: stakeholders routinely ask for more than the budget allows and propose requirements that conflict, each side certain that theirs is essential. Negotiation reconciles that. Stakeholders rank the requirements and then discuss the conflicts in priority order, and you iterate — prioritising, assessing cost and risk, addressing internal conflicts — until requirements have been eliminated, combined or modified so that every party gets some measure of satisfaction.

The rule is no winner and no loser. Both sides win when the deal is one both can live with: stakeholders get a system that satisfies most of what they need, and the team gets a budget and a deadline it can meet. One practical mechanism is priority points: every stakeholder gets a fixed budget of points to spend across the requirement list, spent points cannot be reused, and the totals reveal collective importance rather than the loudest voice. Another is handshaking, which replaces the one-way hand-off of a specification with a two-way exchange: the team proposes solutions and describes their impact, the customer reviews them for missing features and queries the novel ones, and the requirements are good enough once the customer accepts the proposal.

Validating what you have

Validation examines each element of the requirements model for inconsistency, omission, ambiguity and error — including on agile projects, where the requirements are user stories and acceptance tests. Its primary mechanism is the technical review, whose team deliberately includes engineers, customers, users and other stakeholders, because the errors being hunted include errors of interpretation, which only a customer can see.

The review asks a standard battery of questions of each requirement. Is it consistent with the overall objectives? Is it pitched at the right level of abstraction, or has it smuggled in technical detail that does not belong yet? Is it necessary, or an add-on? Is it bounded and unambiguous? Does it have attribution — can you name the person it came from? Does it conflict with another requirement? Is it achievable in the environment that will house it? And, decisively, is it testable once implemented?

That last question is the sharpest instrument here. The software should be user friendly fails it outright: there is nothing to assess. A quantified requirement can fail more subtly — the probability of a successful unauthorised intrusion shall be below 0.0001 has a number, but demonstrating it is expensive enough to be worth asking whether complementary security requirements would serve better.

Worked example — collect a reserved tool, negotiated and validated

The BorrowBox use case Collect a reserved tool has one primary actor, the Member, whose goal is to leave with the reserved tool without speaking to anybody. The Locker Controller and Payments Gateway are secondary actors; the Librarian appears only in an exception. The precondition is a reservation in the held state whose hold has not expired; the trigger is the member arriving at the locker bank. The scenario: request the release code, present the one-time code at the bank, the controller opens the assigned door, the member takes the tool, the reservation becomes checked out. Exceptions: an expired hold, a locker reporting a jam, a copy already marked collected.

Negotiation then does its work. The members want the hold to last all afternoon; the depot admin wants two hours so tools circulate. Priority points show the members spending heavily on extend a hold from the app and barely at all on the initial hold length — which reframes the argument: the hold stays at two hours and an extend-from-the-app requirement enters release one. Both sides can live with that.

Validation then catches two things. Locker reports a jam is a sound exception, because the software can both detect and handle it; the member is confused is not, because nothing detects it. And the app should feel responsive goes straight back — no test could ever fail it.