# Functional Requirements

> Use cases, goal levels, user stories, acceptance criteria, story mapping, story splitting.

## Concepts

- [Acceptance Criterion](https://arc.fuet.ch/concepts/functional-requirements/acceptance-criteria.md): An acceptance criterion is a condition a user story must meet before the product owner accepts it as complete. Each criterion belongs to one story, and clear ones can feed test cases.
- [Agile Enterprise Backlog Model](https://arc.fuet.ch/concepts/functional-requirements/agile-enterprise-backlog-model.md): The Agile Enterprise Backlog Model arranges requirement work items in levels: themes, epics, features, stories and tasks. Tests show when items are done and whether the system meets its nonfunctional requirements.
- [Card, Conversation, Confirmation](https://arc.fuet.ch/concepts/functional-requirements/card-conversation-confirmation.md): A user story has three parts: a short card that names it, conversations that work out the details, and confirmation tests that show when the story is done as agreed.
- [Consistency of User Story and Use Case](https://arc.fuet.ch/concepts/functional-requirements/consistency-of-user-story-and-use-case.md): A user story and a use case describe one goal at different levels of detail. Keep them consistent so they never contradict each other. Treat the story as the brief, early form.
- [Epic](https://arc.fuet.ch/concepts/functional-requirements/epic.md): An epic is a large user story that is too big to finish in one iteration. It holds a place for a wanted feature until the team splits it into smaller stories.
- [Frequent Mistakes in Defining Acceptance Criteria](https://arc.fuet.ch/concepts/functional-requirements/frequent-mistakes-in-defining-acceptance-criteria.md): Acceptance criteria go wrong when they replace conversation, hide the user's goal, or drift into technical detail. Good criteria stay user-focused and testable, and they support the team's discussion of the story.
- [Goal Hierarchy to Component Mapping](https://arc.fuet.ch/concepts/functional-requirements/goal-hierarchy-to-component-mapping.md): A use case can carry a goal level, and its scope can range from a whole organization down to one component. Matching goals to components of similar size gives each building block a clear responsibility.
- [INVEST Applied to Architectural Work](https://arc.fuet.ch/concepts/functional-requirements/invest-applied-to-architectural-work.md): INVEST is a checklist for writing good user stories. Applied to architectural work, it fits unevenly: value and testability carry over well, while independence is doubtful because architectural goals and components depend on each other.
- [INVEST Criteria](https://arc.fuet.ch/concepts/functional-requirements/invest-criteria.md): INVEST is a six-point checklist for judging a user story: Independent, Negotiable, Valuable, Estimable, Small, Testable. Teams use it to check a story before planning, and to check the story they are about to split.
- [Requirement Types and Documents (Wiegers/Beatty)](https://arc.fuet.ch/concepts/functional-requirements/requirement-types-and-documents.md): Requirements exist at different levels: business, user and system. Business requirements go into a vision and scope document. The SRS holds functional and nonfunctional requirements. arc42 sections 1, 2 and 10 reuse them.
- [Requirements Difficulty and Customer Engagement](https://arc.fuet.ch/concepts/functional-requirements/requirements-difficulty-and-customer-engagement.md): Deciding exactly what to build is the hardest part of software work, and clients cannot specify it fully up front. Frequent customer contact, such as reviews and daily collaboration, corrects direction early.
- [Requirements Trawling](https://arc.fuet.ch/concepts/functional-requirements/requirements-elicitation.md): Requirements trawling means gathering requirements with several techniques, expecting that you will not find them all. Some requirements are overlooked and some only appear during building, so teams look actively and early.
- [Responsibility Allocation](https://arc.fuet.ch/concepts/functional-requirements/responsibility-allocation.md): Responsibility allocation assigns tasks and knowledge to parts of a system. Functionality alone does not fix the design, so quality requirements steer which allocation the architect picks.
- [SMART Requirements](https://arc.fuet.ch/concepts/functional-requirements/smart-requirements.md): SMART is a checklist for judging a requirement. It asks whether the requirement is specific, measurable, attainable, realistic and traceable, so teams can verify it, build it and follow it through their work.
- [Story Mapping](https://arc.fuet.ch/concepts/functional-requirements/story-mapping.md): A story map shows how users reach a goal as a picture. Activities form a backbone from left to right. Stories hang below, higher when more necessary. Horizontal lines slice the map into releases.
- [Story Splitting](https://arc.fuet.ch/concepts/functional-requirements/story-splitting.md): Story splitting breaks a large or uncertain user story into smaller ones that still deliver value. Teams use patterns such as workflow steps, operations, data, interfaces and spikes, then check the result.
- [Use Case](https://arc.fuet.ch/concepts/functional-requirements/use-case.md): A use case is a structured description of how a system responds to requests from outside actors. It organizes requirements around user goals and can be kept brief or written in detail.
- [Use Case Completeness Check](https://arc.fuet.ch/concepts/functional-requirements/use-case-completeness-check.md): A use case set is complete when it is not too small, not too large and not off target. Asking people for missing use cases is a start, but it needs a clearer measure.
- [Use Case Goal Level](https://arc.fuet.ch/concepts/functional-requirements/use-case-goal-levels.md): Use case goal level describes how high or low a use case sits in a hierarchy of goals. The user-goal level, called sea level or blue, is the most important level for writing use cases.
- [Use Case Template](https://arc.fuet.ch/concepts/functional-requirements/use-case-template.md): A use case template is a fixed form for writing a use case as text. Every use case gets the same fields, so readers can compare and review them. Teams can use a full or a short version.
- [User Stories vs. Use Cases](https://arc.fuet.ch/concepts/functional-requirements/user-story-vs-use-case.md): User stories are small, brief requirements that a team estimates and talks through. Use cases are more detailed and can be understood on their own. A story is roughly a use case at very low precision.
- [User Story](https://arc.fuet.ch/concepts/functional-requirements/user-story.md): A user story is a short requirement written from a stakeholder's point of view. It is a reminder to talk, not a full specification. Details follow through conversation and acceptance tests.
- [User Story Role Formulation](https://arc.fuet.ch/concepts/functional-requirements/user-story-role-formulation.md): A user story names a specific user role, what that role wants, and why. The "so that" part states the benefit and helps the team judge how much the story matters.
- [Working with Functional Requirements (method phase)](https://arc.fuet.ch/concepts/functional-requirements/method-phase-working-with-functional-requirements.md): 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.