# Step 3: Capture the key functional requirements

## What you get from this step

You get a short list of the functional requirements that shape the architecture. A functional requirement says what the system must do. This list is not the full backlog. It holds the few use cases or user stories where a design decision depends on the detail.

A [user story](https://arc.fuet.ch/concepts/functional-requirements/user-story.md) is a short requirement written from a stakeholder's point of view. It reminds the team to talk. A [use case](https://arc.fuet.ch/concepts/functional-requirements/use-case.md) describes how the system responds to requests from outside actors. You can use either form, or both. Keep them consistent, as described in [Consistency of User Story and Use Case](https://arc.fuet.ch/concepts/functional-requirements/consistency-of-user-story-and-use-case.md).

You describe the result briefly in arc42 section 1 and point to your existing requirements documents. See [Working with Functional Requirements](https://arc.fuet.ch/concepts/functional-requirements/method-phase-working-with-functional-requirements.md).

## What you need first

- A short statement of the business goals. [Requirement Types and Documents](https://arc.fuet.ch/concepts/functional-requirements/requirement-types-and-documents.md) puts business requirements in a vision and scope document, separate from detailed software requirements.
- Access to users or their representatives.
- Any requirements documents that already exist.

## If something is missing

- **No vision and scope document.** Write a few lines of business requirements first. Keep them apart from the software requirements.
- **No direct access to users.** Name the customer representatives. State whether they speak for the wider customer side. [Requirements Difficulty and Customer Engagement](https://arc.fuet.ch/concepts/functional-requirements/requirements-difficulty-and-customer-engagement.md) also asks you to say how often you get feedback.
- **The current process is wasteful.** Fix or remove wasteful steps before you plan to automate them. Take requirements from the target-state process. See [Process Automation Magnifies Efficiency](https://arc.fuet.ch/concepts/principles/process-automation-magnifies-efficiency.md).
- **The requirements feel incomplete.** They are. [Requirements Trawling](https://arc.fuet.ch/concepts/functional-requirements/requirements-elicitation.md) says you will not find them all. Write down that they will change.

## How to do it

1. **Gather candidates with more than one technique.** Use interviews, observation, questionnaires or workshops. Look beyond what users say. Note how you looked for overlooked requirements. See [Requirements Trawling](https://arc.fuet.ch/concepts/functional-requirements/requirements-elicitation.md).
2. **Write each candidate as a story with a named role.** Name a specific role, a goal and a reason. Avoid "As a user". See [User Story Role Formulation](https://arc.fuet.ch/concepts/functional-requirements/user-story-role-formulation.md).
3. **Split big stories.** A story too big for one iteration is an [epic](https://arc.fuet.ch/concepts/functional-requirements/epic.md). Split it before implementation. Use the patterns in [Story Splitting](https://arc.fuet.ch/concepts/functional-requirements/story-splitting.md). Split a story with the word "manage" by operation. Each part should still offer business value.
4. **Choose the stories that matter for the architecture.** Ask which stories are touched by a quality requirement or a constraint. [Responsibility Allocation](https://arc.fuet.ch/concepts/functional-requirements/responsibility-allocation.md) explains that quality requirements steer how you divide the work among parts. Also check your set against the quality requirements and domain concepts, not only against what stakeholders ask for. See [Use Case Completeness Check](https://arc.fuet.ch/concepts/functional-requirements/use-case-completeness-check.md).
5. **Find the first thin slice.** A [story map](https://arc.fuet.ch/concepts/functional-requirements/story-mapping.md) arranges user steps left to right and puts the more necessary ones higher. Its first slice is a thin end-to-end walking skeleton. Start with one simple case, then add variations in data or interface.
6. **Write the chosen ones in more detail.** Use the [Use Case Template](https://arc.fuet.ch/concepts/functional-requirements/use-case-template.md). It asks for a primary actor, a trigger, preconditions, a numbered main success scenario, extensions, postconditions, scope and goal level. Aim at the user-goal level. See [Use Case Goal Level](https://arc.fuet.ch/concepts/functional-requirements/use-case-goal-levels.md).
7. **Add acceptance criteria.** An [acceptance criterion](https://arc.fuet.ch/concepts/functional-requirements/acceptance-criteria.md) is a condition a story must meet before the product owner accepts it. Write it in the user's language. Make it testable. Avoid the mistakes in [Frequent Mistakes in Defining Acceptance Criteria](https://arc.fuet.ch/concepts/functional-requirements/frequent-mistakes-in-defining-acceptance-criteria.md).
8. **Keep functional and quality requirements apart.** Do not hide quality goals inside stories. Arc42 section 1 lists only the top quality goals and points to section 10 for the full list. See [Requirement Types and Documents](https://arc.fuet.ch/concepts/functional-requirements/requirement-types-and-documents.md).
9. **Optional: draw an overview.** A [use case diagram](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram.md) shows the actors and the functions in scope. Draw actors outside the system boundary. Avoid the errors in [Common Use Case Diagram Errors](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram-modeling-mistakes.md).

## Example: ClinicBook

ClinicBook is an online appointment booking system for 40 small medical practices. The team starts with the epic "Manage appointments". They split it by operation: book, move and cancel. They add stories for reminders and calendars.

Then they ask which stories touch the main forces. These are privacy and security, morning peaks, legacy integration, a small team and a fixed launch date.

| Story | Why it matters for the architecture |
|---|---|
| As a patient, I want to book an appointment online, so that I do not have to call the practice. | Needs data from practice-management software of different vendors. Handles health data. Peaks in the morning. |
| As a patient, I want a reminder by SMS or e-mail, so that I do not forget the appointment. | Needs two external channels. |
| As a practice staff member, I want to see changes in my calendar, so that I can plan the day. | Needs the practice's own software to stay in step with ClinicBook. |

Cancel and move are kept as short stories. They follow the same pattern as booking. The team does not give them a detailed use case yet.

For "book an appointment", the team writes a short use case:

- **Scope and goal level:** ClinicBook system, user goal.
- **Primary actor:** patient.
- **Precondition:** the patient is signed in.
- **Main success scenario:** the patient picks a practice and a free slot. The patient confirms. ClinicBook asks the practice's software to reserve the slot. ClinicBook shows the confirmation.
- **Extension:** the slot is taken before confirming. The patient picks another slot.
- **Extension:** the practice's software does not answer. ClinicBook tells the patient and does not show a false confirmation.
- **Postcondition:** the slot is taken in the practice's calendar.

One acceptance criterion: "Given a signed-in patient and a free slot, when the patient confirms the booking, then the slot shows as taken in the practice's calendar."

The walking skeleton is the simplest case. A patient books on the web at one practice with one vendor's software. The mobile app and further vendors come in later slices.

In arc42 section 1, the team writes a brief description of these stories and links to the story map. The top quality goals are listed there too. The morning-peak and privacy detail goes to section 10.

## Done when

- You used more than one technique to gather requirements, and you state that the list is incomplete. ([Requirements Trawling](https://arc.fuet.ch/concepts/functional-requirements/requirements-elicitation.md))
- Each chosen story names a specific role, a goal and a reason. ([User Story Role Formulation](https://arc.fuet.ch/concepts/functional-requirements/user-story-role-formulation.md))
- Large stories are split, and the first slice is a simple end-to-end case. ([Story Splitting](https://arc.fuet.ch/concepts/functional-requirements/story-splitting.md))
- Each architecture-relevant use case has a primary actor, a scope, a goal level and extensions. ([Use Case Template](https://arc.fuet.ch/concepts/functional-requirements/use-case-template.md))
- Each story has acceptance criteria that a tester can check. ([Acceptance Criterion](https://arc.fuet.ch/concepts/functional-requirements/acceptance-criteria.md))
- Functional requirements are kept apart from quality requirements and constraints. ([Working with Functional Requirements](https://arc.fuet.ch/concepts/functional-requirements/method-phase-working-with-functional-requirements.md))
- You checked the set against quality requirements and domain concepts. ([Use Case Completeness Check](https://arc.fuet.ch/concepts/functional-requirements/use-case-completeness-check.md))

## Learn more

- [User Story](https://arc.fuet.ch/concepts/functional-requirements/user-story.md)
- [Card, Conversation, Confirmation](https://arc.fuet.ch/concepts/functional-requirements/card-conversation-confirmation.md)
- [User Stories vs. Use Cases](https://arc.fuet.ch/concepts/functional-requirements/user-story-vs-use-case.md)
- [INVEST Criteria](https://arc.fuet.ch/concepts/functional-requirements/invest-criteria.md)
- [INVEST Applied to Architectural Work](https://arc.fuet.ch/concepts/functional-requirements/invest-applied-to-architectural-work.md)
- [SMART Requirements](https://arc.fuet.ch/concepts/functional-requirements/smart-requirements.md)
- [Use Case Goal Hierarchy with Include Relationships](https://arc.fuet.ch/concepts/modeling-uml/use-case-goal-hierarchy-with-include-relationships.md)
- [Goal Hierarchy to Component Mapping](https://arc.fuet.ch/concepts/functional-requirements/goal-hierarchy-to-component-mapping.md)
- [Story Mapping](https://arc.fuet.ch/concepts/functional-requirements/story-mapping.md)
- [Agile Enterprise Backlog Model](https://arc.fuet.ch/concepts/functional-requirements/agile-enterprise-backlog-model.md)
- [Functional suitability](https://arc.fuet.ch/concepts/quality-attributes/functional-suitability.md)
- [Process Analysis](https://arc.fuet.ch/concepts/modeling-bpmn/process-analysis.md)
- [Capturing Business Behavior via Process Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/capturing-business-behavior-via-process-modeling.md)
- [Process Analysis and Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/purpose-of-process-analysis-and-modeling.md)