A user story is a delivery work item for a small outcome valuable to a user. A use case narrates how an actor reaches a goal, including the alternatives. A requirement is a usable representation of a need.
The buyer, the finance team, and several documents
Fictional Lantern Works is adding tax to checkout. Finance writes why the change started, and what buyers need from it. A designer writes "As a buyer, I want the tax shown before I pay, so I am not surprised". An analyst writes the steps, including the timeout. Same checkout. Not copies of one requirement.
Four classes of requirement
The classes of a requirement are a business requirement, a stakeholder requirement, a solution requirement, and a transition requirement. A user story often represents a stakeholder need. Link them with requirement work item when both are recorded. They are not the same record. A use case is not one of these classes. An acceptance criterion is a condition for accepting a story, a requirement, or a service. The work item does not replace the requirement.
A business requirement states why a change has been initiated: the goals, objectives, and outcomes. It can apply to the whole organization, a business area, or one initiative. In this invented initiative: "Lantern can sell to European Union (EU) buyers and collect the tax those sales owe."
A stakeholder requirement states what a stakeholder needs so those outcomes can be achieved. It bridges business requirements and solution requirements. "An EU buyer sees the tax they will pay before confirming the order." A user story often represents one of these needs and remains a work item.
A solution requirement states a capability or quality the solution must have, in enough detail to build it. A functional requirement is the behavior and information the solution will manage: "Checkout shows the tax before payment is possible." A non-functional requirement is a condition or quality, such as speed, resistance to misuse, availability, or usability. The Business Analysis Body of Knowledge (BABOK) also calls these quality of service requirements. "The tax line appears within a second." Availability stated as a need is this kind of requirement. Measured availability, and a service level objective, are different concepts. Service level agreement (SLA) vs service level objective (SLO) vs service level indicator (SLI) is that split. The objective is not the requirement.
A transition requirement is needed only while moving from the current state to the future state: converting data, training people, or keeping work going. "Open carts are repriced once during the cutover weekend." It is not needed once the change is complete, and it is not a functional requirement of the future solution.
Requirement priority, including MoSCoW (must, should, could, and won't), says how important the need is relative to others. It does not grade a running failure. Severity vs priority keeps that scale off the incident. The source is a stakeholder, who need not be the user in every story.
A stakeholder might be a team
A stakeholder is a person, a group, or an organization. BABOK includes groups. Record a buyer as the stakeholder person, finance as the stakeholder team, and a whole organization as the stakeholder organization. The user in a story may be one stakeholder among others.
A use case narrates the interaction
The use case includes the main sequence as well as the alternatives. The actor may be a person, an organization, or another system. In the example the buyer enters an address, checkout calls the tax service, and the tax line appears before Pay. On timeout, Pay stays disabled. That narrative can span more than one story. A business process is how the organization does a piece of work, whether or not that work is one session with a system. Filing an EU tax return is a process. The checkout conversation is a use case.
The use case actor is the name in the narrative, not a reference to one kind of party. Another system can be an actor, so an actor need not be a stakeholder.
Checks can hang off the story, the requirement, or the service
Epic vs user story vs task places the story under an epic and above the delivery task. "The tax line is visible before Pay can be pressed" can be the acceptance criterion user story, or the acceptance criterion requirement when it checks the functional requirement. "Checkout shows a tax line for an EU address" as a condition of the running service is the acceptance criterion service. The Information Technology Infrastructure Library (ITIL) states acceptance criteria for a service. Business analysis uses them for what key stakeholders will accept. Delivery teams attach them to a story. The plural is the same concept. A criterion is not an evaluation criterion, which ranks alternative solutions.
A business rule is a specific, practicable, testable directive under the control of the business. "An EU order above the threshold needs a tax id." The threshold is not a real legal figure. It is a placeholder so the rule has a shape. The rule holds whether or not this solution is built. A requirement may exist so a solution upholds the rule. The rule can outlive the requirement and the story.
| Document | Question | Invented tax example |
|---|---|---|
| Business requirement | Why was the change initiated? | Sell to EU buyers and collect the tax those sales owe |
| Stakeholder requirement | What does a stakeholder need? | An EU buyer sees the tax before confirming |
| Solution requirement | What capability or quality? | Show the tax before payment, within a second |
| Transition requirement | What is needed only during the move? | Reprice open carts once during the cutover |
| Use case | What is the interaction, including alternatives? | Address, tax call, line, or a timeout |
| User story | What backlog increment will we deliver? | Show the tax before pay |
| Acceptance criterion | What must be true of the story, the requirement, or the service? | Pay stays disabled until the line is visible |
| Business rule | What directive holds even if this solution is never built? | An EU order above the threshold needs a tax id |
The documents can share a trace. They should not share a title. The threshold, the second, and the cutover weekend are made up.
