# Responsibility Allocation

**In short:** 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.

## Explanation

A responsibility is an obligation to perform a task or to know some information. Allocating responsibilities means deciding which part of the system carries each one.

Some responsibilities are public: a part offers them as services to others. Others are private: they only support the public ones. Public responsibilities mark the places where parts depend on each other. So they relate to explicit coupling between elements.

Functionality alone does not decide the architecture. Quality attribute requirements (see Quality Attribute) push the design in a direction. The Attribute-Driven Design (ADD) method builds on this idea. It defines the architecture based on quality attribute requirements, not on functionality alone.

ADD is also recursive. It splits a system, or one element of it, by applying tactics and patterns that satisfy the main quality needs. Then it repeats the step on the resulting elements. So allocation is iterated, not done once. Tactics and patterns shape the design so that it reflects the architecturally significant requirements. Several tactics can pull in different directions, so trade-offs arise. See Architectural Tactic and Architecturally Significant Requirement.

The line between functional and quality concerns is blurry. ISO 25010 treats functional suitability as a quality characteristic. It describes how well a system provides functions that meet stated and implied needs. One sub-characteristic is completeness: whether the functions cover all specified tasks and user objectives. So checking that every goal has an owner is itself a quality check.

## Example

An online shop has these responsibilities: know the price of each item, take an order, and charge a card. The team first assigns each one to a part of the system. Each part publicly offers the services the others need. Then a quality need, such as handling many orders at once, leads the team to split or reshape one part. The team repeats this step on the new parts.

## Trade-offs

Choosing an allocation for a quality need can conflict with other quality needs, because tactics involve trade-offs among each other. Iterating the decomposition adds design effort but lets each element be refined against its own driving qualities.



## Checks

- Responsibilities are named explicitly, and public ones (offered as services) are distinguished from private ones.
- The decomposition is justified by quality attribute requirements, not only by the list of functions.
- Tactics or patterns used to shape the decomposition are named, with their trade-offs.
- The functions cover all specified tasks and user objectives.

## Related

- [Goal Hierarchy to Component Mapping](https://arc.fuet.ch/concepts/functional-requirements/goal-hierarchy-to-component-mapping.md)
- [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md)
- [Quality Attribute](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute.md)
- [Functional suitability](https://arc.fuet.ch/concepts/quality-attributes/functional-suitability.md)
- [Architecturally Significant Requirement](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-requirement.md)
- [Component View](https://arc.fuet.ch/concepts/documentation/component-view.md)
- [Coupling and Cohesion](https://arc.fuet.ch/concepts/principles/coupling-and-cohesion.md)
- [Working with Functional Requirements (method phase)](https://arc.fuet.ch/concepts/functional-requirements/method-phase-working-with-functional-requirements.md)

## Sources

- [Attribute-Driven Design (ADD), Version 2.0 | CMU Software Engineering Institute](https://www.sei.cmu.edu/library/attribute-driven-design-add-version-20/) — sei.cmu.edu, accessed 2026-11-09
- [Responsibility-driven design - Wikipedia](https://en.wikipedia.org/wiki/Responsibility-driven_design) — en.wikipedia.org, accessed 2026-11-09
- [Attribute-driven design - Wikipedia](https://en.wikipedia.org/wiki/Attribute-driven_design) — en.wikipedia.org, accessed 2026-11-09
- [ISO 25010](https://iso25000.com/index.php/en/iso-25000-standards/iso-25010) — iso25000.com, accessed 2026-11-08