# Working with Functional Requirements (method phase)

**In short:** Working with functional requirements means making clear what a system must do. A requirement is precise enough when developers have no more questions. Architects separate these from quality requirements, split large ones, and add detail iteratively.

## 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

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

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

```mermaid
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

- 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.

## Related

- [SMART Requirements](https://arc.fuet.ch/concepts/functional-requirements/smart-requirements.md)
- [Story Splitting](https://arc.fuet.ch/concepts/functional-requirements/story-splitting.md)
- [Story Mapping](https://arc.fuet.ch/concepts/functional-requirements/story-mapping.md)
- [Architecturally Significant Requirement](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-requirement.md)
- [Goal Hierarchy to Component Mapping](https://arc.fuet.ch/concepts/functional-requirements/goal-hierarchy-to-component-mapping.md)
- [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md)
- [arc42 Introduction and Goals](https://arc.fuet.ch/concepts/documentation/arc42-introduction-and-goals.md)
- [User Story](https://arc.fuet.ch/concepts/functional-requirements/user-story.md)

## Sources

- [Curriculum for Certified Professional for Software Architecture (CPSA)® Advanced LevelREQ4ARC – Requirements for Software Architects](https://public.isaqb.org/curriculum-req4arc/curriculum-req4arc-en.html) — public.isaqb.org, accessed 2026-11-09
- [The Humanizing Work Guide to Splitting User Stories](https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/) — humanizingwork.com, accessed 2026-11-09
- [1 - Introduction and Goals | arc42 Documentation](https://docs.arc42.org/section-1/) — docs.arc42.org, accessed 2026-11-09