We decide on paper, while it is still cheap

Every project my team designs moves through three documents: what the business needs, what the system must do, and how the design will deliver it. Writing them early is the cheapest decision in the whole project.

  • BRSBusiness Requirements Specification
  • SRSSystem Requirements Specification
  • SDDSoftware Design Description
See the three documents Get in touch

Why we write it down

The price of a decision is defined by how much has already been built on top of the missing answer.

From The Price of Not Deciding, my essay on requirements, 2026
What fixing one requirement defect costs
  1. 1×while it is still on paper
  2. 10×during development
  3. 100×with the system live

Barry Boehm's data from the 1980s, confirmed many times since. The multipliers change from study to study; the shape of the curve never does.

An architect knows that where a window goes decides the light and the heat of every room behind it. Where a screen sits in a funnel does the same to the whole life of the software. That is why our design starts from requirements, not from screens.

Three documents, one thread

Discovery ends in shared deliverables, written for the people who build next. Each document answers one question and hands its answer to the next.

Business Requirements Specification

What does the business need?

The Business Requirements Specification describes the business before the product: its goals, the way it works today, the people involved and the limits it works within. It keeps the client's internal processes apart from what the platform has to do, so neither is mistaken for the other.

What goes in

  • Business goals and how success will be measured
  • How the business runs today, step by step
  • Stakeholders, their roles and the decisions they own
  • Constraints: budget, dates, platforms and regulation
  • What is in scope and what is not
  • Business requirements, in order of priority
Who reads it
Client leadership, the project manager and design
Done when
The client signs off on the goals, the scope and the priorities.

Built from discovery workshops, benchmarking and a gap register of every open question.

System Requirements Specification

What must the system do?

The System Requirements Specification turns business needs into behavior the team can build and test. Every requirement has a type, an owner and a way to prove it works, so development and QA read the same promise.

What goes in

  • Purpose, scope and definitions
  • Users, their roles and their permissions
  • Functional requirements, one testable sentence each
  • Quality requirements: performance, security and accessibility
  • Interfaces with other systems and their data
  • Requirement types and who owns each one
  • Acceptance criteria
Who reads it
Development, QA, design and the project manager
Done when
Every business requirement traces to at least one system requirement, and every system requirement can be tested.

Shaped by IEEE 830 and IEEE 1233.

Software Design Description

How will the design deliver it?

The Software Design Description is where design meets the specification. It lays out how the product is put together for people who do not live inside software development: the flows, the screens and their states, the edge cases and the decisions behind them, in words that product, QA and development share.

What goes in

  • Goals and deliverables for each design area
  • User flows and information architecture
  • Screens, components and every state they can be in
  • Edge cases and failure paths
  • Design decisions, each with its reason
  • A glossary, so every team uses the same words
Who reads it
Designers, developers, QA and product managers
Done when
A developer can build a screen and a tester can check it without asking the designer what was meant.

Follows IEEE 1016. Our template comes with an interactive guide that walks a new reader through it, section by section.

How it works in practice

The documents are living. They start in the two week discovery sprint and get sharper every sprint after, as the work teaches us. Four rules keep them honest.

  • Write it the week it comes up

    Every open decision goes on paper the week it appears, with an owner and a date.

  • Rough now beats polished later

    A sentence can be refined. A blank page cannot.

  • Prioritize before detailing

    Analysis time goes to the requirements that carry the business case, not to the ones that arrived first.

  • Give every decision a deadline

    A reversible decision made this sprint is worth more than a perfect one made after the schema ships.

What it changes

63 open questions
Logged in the gap register of a two week discovery for an events and membership platform, before the first screen was designed.
2 deliverables
Splitting discovery into business requirements and system requirements gave design a clear hand off to the other teams. The team adopted it in September 2026.
13 to 1 tools
A concept of operations merged three admin portals into one CRM for Container Alliance. By my inventory it replaced 13 separate tools.

  • New designers learn on the real thing

    They study the requirement types and roles in our SRS, with three layers of support around them, until they can lead discovery on their own.

  • One vocabulary

    The glossary in the SDD gives product, QA, development and design the same words for the same things.

  • Design stops being optional

    When each screen traces back to a written requirement, other teams can see why it is there.

Starting a project? Start with the requirements.

Every engagement starts with a two week discovery sprint. It ends with the business requirements on paper, so the system can be specified before anyone draws a screen.

Get in touchSee the work