Introduction and Goals

Describes the relevant requirements and the driving forces that software architects and development team must consider. These include

  • underlying business goals, essential features and functional requirements for the system

  • quality goals for the architecture

  • relevant stakeholders and their expectations

The goal of the Home Entertainment system is let people watch TV programs via satellite or stream content from the internet.

A TV on a sidebar
Figure 1. source: example home entertainment system (source: flickr)

Requirements Overview


Short description of the functional requirements, driving forces, extract (or abstract) of requirements. Link to (hopefully existing) requirements documents (with version number and information where to find it).


From the point of view of the end users a system is created or modified to improve support of a business activity and/or improve the quality.


Short textual description, probably in tabular use-case format. If requirements documents exist this overview should refer to these documents.

Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.

The main system requirements are:

  • HE-SYS-01: Convert satellite television program into video and audio signal

  • HE-SYS-02: Change television program using a remote control

  • HE-SYS-03: Stream video/audio content from the internet

  • HE-SYS-04: Control streaming content via LAN connected device e.g. smartphone

  • HE-SYS-05: Automatically check for updated software

Quality Goals


The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. We really mean quality goals for the architecture. Don’t confuse them with project goals. They are not necessarily identical.


You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. Make sure to be very concrete about these qualities, avoid buzzwords. If you as an architect do not know how the quality of your work will be judged …


A table with quality goals and concrete scenarios, ordered by priorities

The following diagram shows the weighted SQuaRE model of ISO25010 (Systems and software Quality Requirements and Evaluation - System and software quality models).


The main focus of the system lies on Usability by the Owner and Viewer. Security aspects are relevant to the extent that neither the system integrity nor the Owners privacy may be compromised. The third category of important quality attributes concerns the compatibility of the entire system that should allow easy installation and a certain degree of fault tolerance towards errors in individual system components.

As the system is a consumer good with relatively short lifespan, maintainability is not of high importance.



Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that

  • should know the architecture

  • have to be convinced of the architecture

  • have to work with the architecture or with code

  • need the documentation of the architecture for their work

  • have to come up with decisions about the system or its development


You should know all parties involved in development of the system or affected by the system. Otherwise, you may get nasty surprises later in the development process. These stakeholders determine the extent and the level of detail of your work and its results.


Table with role names, person names, and their expectations with respect to the architecture and its documentation.

Role Expectations