Architecture Quality Assessment version 2.0

Needs differ from requirements in several ways. Needs are more stable than requirements over the life cycle of the system and thus its architecture. Whereas detailed requirements may change as the users’ day-to-day activities change,
the need for that day-to-day activity does not. A need is not necessarily testable. A single need often represents the synthesis, or abstraction, of one or more individual requirements. A need captures those concerns that will drive
key decisions by the architect, such as decisions pertaining to performance, technology or cost drivers. Examples of needs might include identification of a prescribed set of technical standards (a so-called “technical architecture”), user
interaction timelines, distribution or policy needs. The needs repository records the collected needs for the system in an orderly fashion. It captures the concerns of the client as well as all the stakeholders of the system. The needs repository also captures the environmental concerns of the stakeholders.

These concerns may include security, development environment, legacy interaction or migration. The successful capture of the needs of program will be succinct. This is critical to keep the architect from getting bogged down in excessive detail. For example, for a system which may have as many as 5,000–10,000 requirements, it would not be unusual for the needs to number under 200. For each need, the repository records a concise statement of that need, its source, its priority, and its classification based on quality measures or concerns. Needs originate from two types of sources. The first is any documentation that
is available capturing system and operational requirements of the system.

The second is the client or other contributing stakeholder with whom the need originates, such as users of the system. The prioritization communicates to the
architect the relative importance of various needs when considering potential tradeoffs. The accurate derivation of the needs for a program is critical to the definition of its architecture. A typical stage of needs analysis is to insure that the needs repository indeed “covers” the full set of requirements. Once an architecture is developed, all architectural elements may be traced back to architectural elements.