Skip to content
Software Architecture Guide

Working with Functional Requirements (method phase)

Explanation

Section titled “Explanation”

Functional requirements describe what a system must do. Architects handle them in a few connected activities.

Know what you are looking at. Architects learn to tell functional requirements apart from quality requirements and constraints. A quality requirement says how well the system must work. A constraint limits the choices open to the team. Mixing the three makes each one harder to handle. See Architectural Constraint and arc42 Quality Requirements.

Make them precise enough, not perfect. A functional requirement is precise enough once the development team has no more questions about its meaning. This is a practical test. It does not demand a formal specification.

Split coarse requirements. Large requirements are broken into smaller parts. Each part should still offer business value. Such a hierarchy can be drawn as a story map (see Story Mapping).

When you split a workflow, avoid cutting it one step at a time from beginning to end. Build the simple end-to-end case first. Then add the middle steps. See Story Splitting.

Start from goals. Visions and business goals sit at the top of the requirements hierarchy. Impact Mapping is one named technique for breaking business goals down systematically.

Go deep only where it matters. Requirements are gathered iteratively and incrementally. Architects need detail only for the subset that drives architectural decisions. These are the Architecturally Significant Requirements. The rest can be gathered later, in small rounds.

Use tools. The curriculum lists several kinds of requirements tools, including issue trackers. It also notes tools that connect Given-When-Then behavior specifications to the system’s source code, in the style of Cucumber and Gherkin.

Document it. The first arc42 section asks for a short description of the functional requirements. If requirements documents already exist, that overview should refer to them. See arc42 Introduction and Goals.

Example

Section titled “Example”

A team builds an online booking system. The business goal is “more customers book without calling us.” The coarse requirement “customers can book an appointment” is too big. The team first builds the simplest complete path: pick a slot, confirm, receive a booking. Later they add the middle steps, such as payment or reminders. Each piece still gives customers something useful. The team stops refining a piece when developers say they have no open questions about it. Only the requirements that shape big technical choices get extra detail early.

Trade-offs

Section titled “Trade-offs”

Gathering requirements in rounds keeps effort low and lets understanding grow. The cost is that some details stay open for a while. Architects must pick carefully which requirements are significant enough to detail early. Splitting requirements also takes effort. Cutting a workflow step by step is the obvious split, but the sources call it the wrong way to go.

From goals to requirements that are precise enough

Diagram source 
flowchart TD
  A[Vision and business goals] --> B[Coarse functional requirement]
  B --> C[Part 1 with business value]
  B --> D[Part 2 with business value]
  C --> E{Developers have no more questions?}
  D --> E
  E -- No --> B
  E -- Yes --> F[Precise enough]

Checks

Section titled “Checks”
  • The document briefly describes the functional requirements and refers to existing requirements documents.
  • Functional requirements are kept apart from quality requirements and constraints.
  • Detailed requirements exist for the subset needed for architectural decisions.
  • Large functional requirements are broken into parts that each still offer business value.
Section titled “Related”

Sources

Section titled “Sources”