Skip to content
Software Architecture Guide

Working with Tactics and Quality Attributes

Explanation

Section titled “Explanation”

A quality attribute is a property such as speed or security that the system must have. A quality scenario describes one such need in a concrete situation. A tactic is a small design decision that helps meet a specific quality attribute (see Architectural Tactic).

Start with measurable scenarios. Scenarios must be specific and measurable. Then the team knows what is good enough and can check whether a tactic works. arc42 separates two kinds. Usage scenarios describe how the running system reacts to a stimulus. Change scenarios describe the effect of a modification or extension.

Pick tactics from catalogues. Tactics are grouped into taxonomies. Security tactics, for example, are organized as detect, resist, react and recover. Look in the catalogue for the quality attribute you are working on. Choose tactics that address the scenario.

Record each decision with its reasoning. A good architectural decision record (ADR) resolves at least one architecturally significant requirement. That ties every tactic to a ranked quality need. Base the rationale on actual requirements and trace it back to them. Consider at least two options per issue.

Show the link in a table. arc42 suggests one consolidated table in the solution strategy (section 4). It links quality goal, scenario, solution approach and details. It answers the question: which tactics, approaches or decisions address each scenario? Section 1.2 then only refers to this table.

Iterate. Revise decisions as design work moves on and knowledge of requirements grows. Revisit them at the end of each stage.

Evaluate. Quality scenarios can also feed an ATAM review (see Architecture Tradeoff Analysis Method (ATAM)). A table of quality goal, scenario, solution approach and risk supports a qualitative evaluation.

Example

Section titled “Example”

A team has the scenario: “When 500 users search at once, results appear within 2 seconds.” The scenario is measurable. The team looks in a performance tactic catalogue and considers two options. They choose one and write an ADR that names the scenario as the reason. They add a row to the solution-strategy table: goal, scenario, approach, details. After the first release they revisit the decision with what they learned.

Trade-offs

Section titled “Trade-offs”

Tactics interact. Favoring one quality attribute can come at the expense of another. A tactic that helps speed may hurt something else. Tactic catalogues can record these impacts on other attributes, for example using the ISO 25010 quality model. Check the side effects before you commit to a tactic. Keeping the table and ADRs current also takes ongoing effort.

The iterative loop from scenarios to recorded tactic decisions.

Diagram source 
flowchart LR
 A[Ranked, measurable scenarios] --> B[Select tactics from catalogues]
 B --> C[Write ADR with rationale]
 C --> D[Review in solution architecture and tests]
 D --> E[Revisit as knowledge changes]
 E --> A

Checks

Section titled “Checks”
  • Each quality scenario is specific and has a measurable criterion.
  • A table in the solution strategy links each quality goal and scenario to its tactics or approaches.
  • Each tactic decision is recorded as an ADR that traces back to a requirement.
  • At least two options were considered for each decision issue.
  • The impact of chosen tactics on other quality attributes is noted.
Section titled “Related”

Sources

Section titled “Sources”