Active Reviews for Intermediate Designs (ARID)
A method for performing a scenario-based stakeholder-centric review of a portion of an architecture that is typically a coherent software-invocable service. The review is focused on whether the design is sufficient for the developers of that software that will use it

Architecture description language (ADL)
A language (graphical, textual, or both) for describing a software system in terms of its architectural elements and the relationships among them

Architectural drivers
The combination of functional, quality attribute, and business requirements that "shape" the architecture or the particular element under consideration

Architectural pattern
A description of element and relation types together with a set of constraints on how they are used. The term architectural style has also been widely used to describe it

Architectural style
A specialization of element and relation types, together with a set of constraints on how they can be used. See architectural pattern

Architecture Tradeoff Analysis Method (ATAM)
A method to assess the consequences of architectural decisions in light of quality attribute requirements and business goals. The ATAM helps stakeholders ask the right questions to discover potentially problematic architectural decisions

Attribute-Driven Design (ADD) Method
An approach to defining a software architecture by basing the design process on the quality attribute requirements of the system. The ADD method enables designers to understand quality attribute tradeoffs early in the design process

Component
The principal computational element and data store that execute in a system. See also module

Connector
A runtime pathway of interaction between two or more components.

Constraint
A requirement for which the design decisions are prespecified

Cost Benefit Analysis Method (CBAM)
A method for doing architecture-based economic analyses of software intensive systems. The aim of the CBAM is to explicitly associate costs, benefits, and uncertainty with architectural decisions, as a means of optimizing the choice of such decisions

Detailed design
A term people sometimes use to mean detailed architectural design -- that is, architectural design of fine-grained elements, or fine-grained architectural design decisions such as the precise interface of an element -- and sometimes used to mean non-architectural design

Element
The architectural building block (component, connector, or module) that is native to a style

Enterprise architecture
A means for describing business structures and processes that connect business structures

Interface
See software interface

Interface specification
A statement of what an architect chooses to make known about an element in order for other entities to interact or communicate with it

Layer
A collection of code that forms a virtual machine and that interacts with other layers only according to predefined roles under the relation "allowed to use"

Module
An implementation unit of software that provides a coherent unit of functionality

Non-architectural design
Design decisions carried out subsequent to the architecture. The design of a software system comprises many design decisions. Architectural design decisions are those made by the software architect to insure that the system meets its functional, behavioral, and quality attribute goals. However, the architect leaves many design decisions to downstream designers and implementors because those decisions are either constrained sufficiently by the architecture, or because they are not critical to achieving the system's requirements. For more information, read What’s the Difference Between Architecture and Design?

Quality attribute
A property of a work product or goods by which its quality will be judged by some stakeholder or stakeholders. Quality attribute requirements such as those for performance, security, modifiability, reliability, and usability have a significant influence on the software architecture of a system

Quality attribute scenario
See scenario.

Quality Attribute Workshop (QAW)
A method that engages system stakeholders early in the life cycle to discover the driving quality attribute requirements of a software-intensive system. The QAW is aimed at eliciting, collecting, and organizing software quality attribute requirements in the form of scenarios. The QAW is used before the software architecture has been created

Reference architecture
A reference model that is mapped onto software elements that implements the functionality defined in the reference model

Reference model
A division of functionality into elements together with the data flow between those elements

Relation
A definition of how elements cooperate to accomplish the work of a system

Scenarios
"Short stories" that describe a system interaction with respect to some quality attribute. Typically, the focus would be on three kinds of scenarios: use case - anticipated uses of the system, growth - anticipated changes to the system, and exploratory - unanticipated stresses to the system (uses and/or changes)

Sensitivity point
A property of one or more components (and/or component relationships) that is critical for achieving a particular quality attribute response. Sensitivity points are places in a specific architecture to which a specific response measure is particularly "sensitive" (that is, a little change is likely to have a large impact). Unlike tactics, sensitivity points are properties of a specific system

Software architecture
The structure or structures of a system, which comprise the software elements, the externally visible properties of those elements, and the relationships among them

Software interface
A boundary across which two independent entities meet, and interact or communicate with each other

Software Product Line
A set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of reusable core assets in a prescribed way

Stakeholder
Someone who has a vested interest in an architecture

Style
See architectural style

System architecture
A means for describing the elements and interactions of a complete system including its hardware elements and its software elements

Tactic
A design decision that is influential in the control of a quality attribute response. Tactics tell you what to do in order to affect a quality attribute response measure. Unlike sensitivity points, tactics are independent of any specific system

Tradeoff
A property that affects more than one attribute and is a sensitivity point for more than one attribute

Utility tree
A top-down vehicle for characterizing the "driving" attribute-specific requirements where nodes represent important quality goals and leaves represent scenarios

View
A representation of a set of system elements and the relationships among them. A view shows a particular perspective of the system (e.g., code units, runtime elements) and may show just part or the entire system. A set of views–not a single one–convey the architecture

Views-and-beyond
An approach for documentation that holds that documenting a software architecture is a matter of documenting the relevant views, and then adding information that applies to more than one view

Viewtype
A category of views. In the SEI's Views-and-Beyond approach to architecture documentation, three viewtypes are identified: the module viewtype includes views whose elements are modules; the C&C viewtype includes views whose elements are components and connectors; and the allocation viewtype includes views that show allocation of software to structures in the software system's environment.