Requirements vs. Designs
In short A requirement captures a need in a form people can work with; a design does the same for a solution. Keeping the two apart helps you avoid locking in a solution too early, while still using sketches and models to discover what people really need.
Based on: IIBA, BABOK® Guide v3, section 2.5 and section 11 (Information Technology perspective).
On this page
Key ideas#
Two kinds of representation#
The BABOK® Guide draws an explicit distinction:
- A requirement represents a need. Its focus is the value you will get when it is met.
- A design represents a solution. Its focus is how the solution will deliver that value once built.
The BABOK Guide calls both “representations” that must be usable: something written, drawn or modeled that other people can understand, discuss and act on. A requirement can be a sentence, a user story or a business objective. A design can be a screen mockup, a process model, a dashboard sketch, a data model or a prototype.
The same techniques serve both#
You elicit, model and analyze requirements and designs with the same techniques: interviews, workshops, prototyping, Process Modelling and others. That is one reason the line between them is hard to see in practice.
The relationship is recursive#
A requirement prompts a design. Showing that design to stakeholders prompts new or corrected requirements. Those lead to a revised design, and so on. The focus often shifts from “need” to “solution” and back without anyone noticing. The BABOK Guide notes that as you get closer to understanding and meeting the need, the distinction matters less.
Analysts always do some design#
The BABOK Guide is clear that business analysts are responsible for design to some degree. How much depends on the perspective. In the Information Technology perspective, for example, the word “design” is often reserved for architects and developers; the analyst defines solution requirements and leaves technical design to them. In process or business architecture work, the analyst may own the process models and capability maps, which are designs.
How to apply it#
- Label your artifacts. For each document, model or sketch, note whether it states a need or proposes a solution. A process model of the future state is a design; the goal it serves is a requirement.
- When you receive a design, extract the requirement. Stakeholders often express needs as solutions (“add a dropdown”, “build an app”). Record the proposal as a design option, then ask what it is for. See Why? What? How?.
- Use designs to elicit. Show a rough mockup or a prototype early. Reactions to something concrete surface requirements that abstract questions miss.
- Keep traceability from design to requirement. Each screen, report or process step should point to the requirement it satisfies. A design element that traces to nothing is scope creep or a missing requirement.
- Agree who owns which designs. On each project, settle which designs the analyst produces (for example, process models, wireframes) and which belong to architects, UX designers or developers.
- Allow more than one design per requirement. A requirement that only one design can satisfy is probably a design in disguise.
Example#
At The Workshop, a fictional chain of 12 bike-repair workshops, the analyst sorts early material into pairs:
| Requirement (need) | Design (one possible solution) |
|---|---|
| Customers can find out repair status without phoning. | Text-message templates for each job status, plus a status page mockup. |
| Managers can see parts stock across all 12 workshops in one place. | A dashboard sketch with one row per workshop and a low-stock highlight. |
| Front-desk staff spend less time taking bookings. | A future-state booking process model with online self-service. |
| Mechanics record parts used on each job at the time of repair. | A tablet screen with a parts search field and a quantity button. |
When the analyst shows the tablet screen to mechanics, they point out that their hands are usually greasy and they would rather scan a barcode on the part. That reaction produces a new requirement (parts can be recorded without typing) and a different design (barcode scanning). The requirement stays stable while the design changes.
Pitfalls#
- Signing off a mockup as “the requirements.” A screen captures one solution. When the screen changes, nobody knows which parts were essential. Record the underlying needs separately.
- Refusing to sketch. Some analysts avoid designs entirely to “stay neutral.” You lose a powerful elicitation tool. Sketch, but label it as an option.
- Over-specifying in the requirement. “The system shall display a red banner at the top of the screen” is a design. Ask what the banner is for.
- Treating the distinction as a rule to enforce. The goal is clarity about what is fixed (the need) and what can change (the solution), not a policing exercise.
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Section 2.5 (requirements and designs); section 11 (Information Technology perspective).