ISO/IEC 42010:2007

INTERNATIONAL ISO/IEC
STANDARD 42010
IEEE
Std 1471-2000
First edition
2007-07-15
Systems and software engineering —
Recommended practice for architectural
description of software-intensive
systems
Ingénierie des logiciels et des systèmes — Pratique recommandée pour
la description architecturale des systèmes exigeant beaucoup de
logiciels
Reference number
IEEE
Std 1471-2000
IEEE Std 1471-2000
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

ISO
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
ii
IEEE Std 1471-2000
IEEE Recommended Practice for
Architectural Description of
Software-Intensive Systems
Sponsor
Software Engineering Standards Committee
of the
IEEE Computer Society
Approved 21 September 2000
IEEE-SA Standards Board
Abstract: This recommended practice addresses the activities of the creation, analysis, and sus-
tainment of architectures of software-intensive systems, and the recording of such architectures in
terms of architectural descriptions. A conceptual framework for architectural description is estab-
lished. The content of an architectural description is defined. Annexes provide the rationale for key
concepts and terminology, the relationships to other standards, and examples of usage.
Keywords: architectural description, architecture, software-intensive system, stakeholder con-
cerns, system stakeholder, view, viewpoint
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 9 October 2000. Printed in the United States of America.
Print: ISBN 0-7381-2518-0 SH94869
PDF: ISBN 0-7381-2519-9 SS94869
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
written permission of the publisher.

IEEE Std 1471-2000
International Standard ISO/IEC 42010:2007(E)
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 42010 was prepared by IEEE (as IEEE Std 1471-2000) and was adopted, under a special “fast-track
procedure”, by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 7,
Software and systems engineering, in parallel with its approval by national bodies of ISO and IEC. The IEEE
Computer Society will cooperate in the maintenance of this International Standard as a Category A liaison to
SC 7.
International Organization for Standardization/International Electrotechnical Commission
Case postale 56 • CH-1211 Genève 20 • Switzerland

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Com-
mittees of the IEEE Standards Association (IEEE-SA) Standards Board. Members of the committees serve
voluntarily and without compensation. They are not necessarily members of the Institute. The standards
developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as
well as those activities outside of IEEE that have expressed an interest in participating in the development of
the standard.
Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to
the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and
issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard. Every IEEE Standard is subjected to review at least every five years for
revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is rea-
sonable to conclude that its contents, although still of some value, do not wholly reflect the present state of
the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard.
Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership
affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of
text, together with appropriate supporting comments.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they
relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the
Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of
all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a
balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating
Committees are not able to provide an instant response to interpretation requests except in those cases where
the matter has previously received formal consideration.
Comments on standards and requests for interpretations should be addressed to:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
USA
Note: Attention is called to the possibility that implementation of this standard may
require use of subject matter covered by patent rights. By publication of this standard,
no position is taken with respect to the existence or validity of any patent rights in
connection therewith. The IEEE shall not be responsible for identifying patents for
which a license may be required by an IEEE standard or for conducting inquiries into
the legal validity or scope of those patents that are brought to its attention.
IEEE is the sole entity that may authorize the use of certification marks, trademarks, or other designations to
indicate compliance with the materials set forth herein.
Authorization to photocopy portions of any individual standard for internal or personal use is granted by the
Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright
Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Cus-
tomer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy
portions of any individual standard for educational classroom use can also be obtained through the Copy-
right Clearance Center.
IEEE Introduction
(This introduction is not part of IEEE Std 1471-2000, IEEE Recommended Practice for Architectural Description of
Software-Intensive Systems.)
It has long been recognized that “architecture” has a strong influence over the life cycle of a system. In the
past, hardware-related architectural aspects were dominant, whereas software-related architectural integrity,
when it existed, often was to be sacrificed first in the course of system development. Today, software-
intensive systems are pervasive. The cost of software development and the increasing complexity of software
systems have changed the relative balance. Software technology is maturing rapidly. The practice of system
development can benefit greatly from adherence to architectural precepts.
However, the concepts of architecture have not been consistently defined and applied within the life cycle of
software-intensive systems. Despite significant industrial and research activity in this area, there is no single,
accepted framework for codifying architectural thinking, thereby facilitating the common application and
evolution of available and emerging architectural practices.
The IEEE Architecture Planning Group (APG) was formed in August 1995 to address this need. The APG
was chartered by the IEEE Software Engineering Standards Committee (SESC) to set a direction for incor-
porating architectural thinking into IEEE standards. The result of the APG’s deliberations was to recommend
an IEEE activity with the following goals:
— To define useful terms, principles and guidelines for the consistent application of architectural pre-
cepts to systems throughout their life cycle
— To elaborate architectural precepts and their anticipated benefits for software products, systems, and
aggregated systems (i.e., “systems of systems”)
— To provide a framework for the colilection and consideration of architectural attributes and related
information for use in IEEE standards
— To provide a useful road map for the incorporation of architectural precepts in the generation, revi-
sion, and application of IEEE standards
In April 1996 SESC created the Architecture Working Group (AWG) to implement those recommendations.
Participants
At the time this recommended practice was completed, the Architecture Working Group had the following
membership.
Basil Sherlund, Chair
Ronald L. Wade, Vice Chair
David Emery, Vice Chair for Liaison
Rich Hilliard, Secretary and Editor
Frank C. Belz Judith S. Kerner Glenn Plonk
S. Jeromy Carriere Dwayne L. Knirk Peter T. Poon
Mark Dehlin Ron Kohl Dave Rayford
Verlynda Dobbs Alexei E. Kotov Ann Reedy
Nancy Eickelmann Philippe Kruchten Ira Sachs
Walter J. Ellis Simon Liu Thomas F. Saunders
William Gess Mark W. Maier M. Wayne Shiveley
Vladan V. Jovanovic Bill McMullen Louise Tamres
Fatima Mili
The following members of the balloting committee voted on this standard:
Hiranmay Ghosh
Edward A. Addy Pavol Navrat
Marilyn Ginsberg-Finner
Mario R. Barbacci Gerald L. Ourada
Julio Gonzalez-Sanz
Edward E. Bartlett Alex Polack
Lewis Gray
Leo Beltracchi R. Razouk
L. M. Gunther
Frank C. Belz Annette D. Reilly
John Harauz
Richard E. Biehl Helmut Sandmayr
Herbert Hecht
Edward R. Byrne Frederico Sousa Santos
Mark Henley
Lawrence Catchpole Robert J. Schaaf
John W. Horch
Leslie Chambers Carl A. Singer
George Jackelen
Keith Chow Richard S. Sky
Frank V. Jorgensen
Antonio M. Cicu Mitchell W. Smith
Vladan V. Jovanovic
Sylvain Clermont Fred J. Strauss
William S. Junk
Rosemary Coleman Sandra Swearingen
Judith S. Kerner
Darrell Cooksey Toru Takeshita
Thomas M. Kurihara
Paul R. Croll Richard H. Thayer
Helmut Kurzdorfer
Gregory T. Daich Booker Thomas
Kyoung-In Kwon
Bostjan K. Derganc Leonard L. Tripp
J. Dennis Lawrence
Perry R. DeWeese Theodore J. Urbanowicz
Thomas B. Lindahl
Verlynda Dobbs Tom Vaiskunas
Jim J. Logan
Franz D. Engelmann Ronald L. Wade
Henry A. Malec
William Eventoff Randall K. Walters
Tomoo Matsubara
Jonathan H. Fairclough Larry L. Wear
Ian R. McChesney
John W. Fendrich Charles J. Wertz
James W. Moore
John H. Fowler Scott A. Whitmire
Frederick I. Moxley
Eva Freund Paul R. Work
Francisco Navas Plano
Andrew Gabb Natalie C. Yopconka
Juan Garbajosa-Sopena Geraldine Zimmerman
iv Copyright © 2000 IEEE. All rights reserved.

When the IEEE-SA Standards Board approved this standard on 21 September 2000, it had the following
membership:
Donald N. Heirman, Chair
James T. Carlo, Vice Chair
Judith Gorman, Secretary
Satish K. Aggarwal James H. Gurney James W. Moore
Mark D. Bowman Richard J. Holleman Robert F. Munzner
Gary R. Engmann Lowell G. Johnson Ronald C. Petersen
Harold E. Epstein Robert J. Kennelly Gerald H. Peterson
H. Landis Floyd Joseph L. Koepfinger* John B. Posey
Jay Forster* Peter H. Lips Gary S. Robinson
Howard M. Frazier L. Bruce McClung Akio Tojo
Ruben D. Garzon Daleep C. Mohla Donald W. Zipse
*Member Emeritus
Also included is the following nonvoting IEEE-SA Standards Board liaison:
Alan Cookson, NIST Representative
Donald R. Volzka, TAB Representative
Noelle D. Humenick
IEEE Standards Project Editor
Contents
1. Overview. 1
1.1 Scope. 1
1.2 Purpose. 1
1.3 Intended users . 2
1.4 Conformance to this recommended practice. 3
2. References. 3
3. Definitions. 3
4. Conceptual framework. 4
4.1 Architectural description in context. 4
4.2 Stakeholders and their roles. 6
4.3 Architectural activities in the life cycle . 6
4.4 Uses of architectural descriptions . 8
5. Architectural description practices . 8
5.1 Architectural documentation. 8
5.2 Identification of stakeholders and concerns. 9
5.3 Selection of architectural viewpoints. 9
5.4 Architectural views . 10
5.5 Consistency among architectural views. 11
5.6 Architectural rationale . 11
5.7 Example use. 11
Annex A (informative) Bibliography. 13
Annex B (informative) Notes on terminology. 14
Annex C (informative) Examples of viewpoints . 17
Annex D (informative) Relationship to other standards. 20
vi Copyright © 2000 IEEE. All rights reserved.

IEEE Recommended Practice for
Architectural Description of
Software-Intensive Systems
1. Overview
1.1 Scope
This recommended practice addresses the architectural description of software-intensive systems. A
software-intensive system is any system where software contributes essential influences to the design,
construction, deployment, and evolution of the system as a whole.
The scope of this recommended practice encompasses those products of system development that capture
architectural information. This includes architectural descriptions that are used for the following:
a) Expression of the system and its evolution
b) Communication among the system stakeholders
c) Evaluation and comparison of architectures in a consistent manner
d) Planning, managing, and executing the activities of system development
e) Expression of the persistent characteristics and supporting principles of a system to guide acceptable
change
f) Verification of a system implementation’s compliance with an architectural description
g) Recording contributions to the body of knowledge of software-intensive systems architecture
1.2 Purpose
The purpose of this recommended practice is to facilitate the expression and communication of architectures
and thereby lay a foundation for quality and cost gains through standardization of elements and practices for
architectural description.
Despite significant efforts to improve engineering practices and technologies, software-intensive systems
continue to present formidable risks and difficulties in their design, construction, deployment, and evolution.
Recent attempts to address these difficulties have focused on the earliest period of design decision-making
and evaluation, increasingly referred to as the architectural level of system development. The phrases archi-
IEEE
Std 1471-2000 IEEE RECOMMENDED PRACTICE FOR
tectural level and architecture are widely, if imprecisely, used. Their use reflects acceptance of an architec-
tural metaphor in the analysis and development of software-intensive systems. A key premise of this
metaphor is that important decisions may be made early in system development in a manner similar to the
early decision-making found in the development of civil architecture projects.
Many innovations are resulting from this attention to the architectural level, among them architectural
description languages and associated tools and environments; architectural frameworks, models, and
patterns; and techniques for architectural analysis, evaluation, and architecture-based reuse. While these
efforts differ considerably in important aspects, sufficient commonality exists to warrant the development of
a recommended practice to codify their common elements.
These innovations are occurring, and maturing, rapidly within many research and application communities,
and they reflect differing interests, influences, insights, and intentions. There is a general consensus on the
importance of the architectural level of systems development, and that that level consists of early decision-
making about overall design structure, goals, requirements, and development strategies. However, there has
not yet emerged any reliable consensus on a precise definition of a system’s architecture, i.e., how it should
be described, what uses such a description may serve, or where and when it should be defined. The bound-
aries and relationships between architectural trends and practices, and other practices; and between architec-
tural technology and other technology, are not yet widely recognized.
In such situations, progress often depends on mediating influences. Potential adopters of architectural
practices and technology need a frame of reference within which to address implementation and adoption
decisions. Technology developers need a frame of reference within which to communicate the motivating
concepts of their technology, and to accumulate and appreciate feedback from early adoption.
To these ends, this recommended practice is intended to reflect generally accepted trends in practices for
architectural description and to provide a technical framework for further evolution in this area.
Furthermore, it establishes a conceptual framework of concepts and terms of reference within which future
developments in system architectural technology can be deployed. This recommended practice codifies
those elements on which there is consensus; specifically the use of multiple views, reusable specifications
for models within views, and the relation of architecture to system context.
1.3 Intended users
The principal class of users for this recommended practice comprises stakeholders in system development
and evolution, including the following:
— Those that use, own, and acquire the system (users, operators, and acquirers, or clients)
— Those that develop, describe, and document architectures (architects)
— Those that develop, deliver, and maintain the system (architects, designers, programmers, maintain-
ers, testers, domain engineers, quality assurance staff, configuration management staff, suppliers,
and project managers or developers)
— Those who oversee and evaluate systems and their development (chief information officers, auditors,
and independent assessors)
A secondary class of users of this recommended practice comprises those involved in the enterprise-wide
infrastructure activities that span multiple system developments, including methodologists, process and pro-
cess-improvement engineers, researchers, producers of standards, tool builders, and trainers.
2 Copyright © 2000 IEEE. All rights reserved.

IEEE
ARCHITECTURAL DESCRIPTION OF SOFTWARE-INTENSIVE SYSTEMS Std 1471-2000
1.4 Conformance to this recommended practice
An architectural description conforms to this recommended practice if that description meets the require-
ments listed in Clause 5.
2. References
This recommended practice shall be used in conjunction with the following publications. When the follow-
ing standards are superseded by an approved revision, the revision shall apply.
IEEE Std 610.12−1990, IEEE Standard Glossary of Software Engineering Terminology.
IEEE/EIA Std 12207.0−1996, IEEE/EIA Standard—Industry Implementation of ISO/IEC 12207: 1995,
Information Technology—Software life cycle processes.
3. Definitions
For the purposes of this standard, the following terms and definitions apply. The IEEE Standard Dictionary
of Electrical and Electronics Terms [B2], IEEE Std 610.12−1990, or IEEE/EIA Std 12207.0−1996 should
be referenced for terms not defined in this clause.
3.1 acquirer: An organization that procures a system, software product, or software service from a supplier.
(The acquirer could be a buyer, customer, owner, user, or purchaser.)
3.2 architect: The person, team, or organization responsible for systems architecture.
3.3 architecting: The activities of defining, documenting, maintaining, improving, and certifying proper
implementation of an architecture.
3.4 architectural description (AD): A collection of products to document an architecture.
3.5 architecture: The fundamental organization of a system embodied in its components, their relationships
to each other, and to the environment, and the principles guiding its design and evolution.
3.6 life cycle model: A framework containing the processes, activities, and tasks involved in the develop-
ment, operation, and maintenance of a software product, which spans the life of the system from the defini-
tion of its requirements to the termination of its use.
3.7 system: A collection of components organized to accomplish a specific function or set of functions.
3.8 system stakeholder: An individual, team, or organization (or classes thereof) with interests in, or con-
cerns relative to, a system.
3.9 view: A representation of a whole system from the perspective of a related set of concerns.
IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway,
NJ 08855-1331, USA (http://standards.ieee.org/).
The numbers in brackets correspond to those of the bibliography in Annex A.
IEEE
Std 1471-2000 IEEE RECOMMENDED PRACTICE FOR
3.10 viewpoint: A specification of the conventions for constructing and using a view. A pattern or template
from which to develop individual views by establishing the purposes and audience for a view and the tech-
niques for its creation and analysis.
4. Conceptual framework
This clause introduces a conceptual framework, or frame of reference, for architectural description. The
framework establishes terms and concepts pertaining to the content and use of architectural descriptions.
These terms and concepts will be used in subsequent clauses.
4.1 Architectural description in context
For the purposes of this recommended practice, the term system encompasses individual applications, sys-
tems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enter-
prises, and other aggregations of interest.
A system inhabits an environment. A system’s environment can influence that system. The environment, or
context, determines the setting and circumstances of developmental, operational, political, and other influ-
ences upon that system. The environment can include other systems that interact with the system of interest,
either directly via interfaces or indirectly in other ways. The environment determines the boundaries that
define the scope of the system of interest relative to other systems.
A system has one or more stakeholders. Each stakeholder typically has interests in, or concerns relative to,
that system. Concerns are those interests which pertain to the system’s development, its operation or any
other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system
considerations such as performance, reliability, security, distribution, and evolvability.
A system exists to fulfill one or more missions in its environment. A mission is a use or operation for which
a system is intended by one or more stakeholders to meet some set of objectives.
Every system has an architecture, in the terms of this recommended practice. An architecture can be
recorded by an architectural description (see Figure 1). This recommended practice distinguishes the
architecture of a system, which is conceptual, from particular descriptions of that architecture, which are
concrete products or artifacts. Architectural descriptions (ADs) are the subject of this recommended
practice.
In the conceptual framework of this recommended practice, an architectural description is organized into
one or more constituents called (architectural) views. Each view addresses one or more of the concerns of the
system stakeholders. The term view is used to refer to the expression of a system’s architecture with respect
to a particular viewpoint.
NOTE—This recommended practice does not use terms such as functional architecture, physical architecture, and
technical architecture, as are frequently used informally. In the conceptual framework of the recommended practice, the
approximate equivalents of these informal terms would be functional view, physical view, and technical view,
respectively.
Other information, not contained in any constituent view, may appear in an AD , as a result of an organiza-
tion’s documentation practices. Examples of such information are the system overview, the system context,
the system stakeholders and their key concerns, and the architectural rationale.
A viewpoint establishes the conventions by which a view is created, depicted and analyzed. In this way, a
view conforms to a viewpoint. The viewpoint determines the languages (including notations, model, or prod-
uct types) to be used to describe the view, and any associated modeling methods or analysis techniques to be
4 Copyright © 2000 IEEE. All rights reserved.

IEEE
ARCHITECTURAL DESCRIPTION OF SOFTWARE-INTENSIVE SYSTEMS Std 1471-2000
applied to these representations of the view. These languages and techniques are used to yield results rele-
vant to the concerns addressed by the viewpoint.
An architectural description selects one or more viewpoints for use. The selection of viewpoints typically
will be based on consideration of the stakeholders to whom the AD is addressed and their concerns.
A viewpoint definition may originate with an AD, or it may have been defined elsewhere. A viewpoint that is
defined elsewhere is referred to in this recommended practice as a library viewpoint.
A view may consist of one or more architectural models. Each such architectural model is developed using
the methods established by its associated architectural viewpoint. An architectural model may participate in
more than one view.
NOTE—In a complex system, ADs may be developed for components of the system, as well as for the system as a
whole. In this case, it may be that one AD will have a view corresponding to a particular viewpoint and another AD will
have a view corresponding to the same viewpoint. Although the system being described by these two views has the
whole-part relationship, this is not an instance of multiple views corresponding to one viewpoint. The ADs are consid-
ered separate even though they are related by the systems they describe.
Mission
fulfills 1.*
influences has an
Environment System Architecture
inhabits
described by
has 1.*
is important to identifies
1.* provides
1.*
Architectural
Stakeholder Rationale
Description
is addressed to
participates in
1.*
organized by
has identifies
selects 1.*
1.* 1.*
1.*
conforms to
Concern Viewpoint View
used to
cover 1.*
participates in consists of
has source 1.* 1.*
aggregates
0.1
1.*
Library
establishes methods for Model
Viewpoint
1.*
Figure 1—Conceptual model of architectural description
NOTE—Figure 1 provides an informative summary of the key concepts introduced by this recommended practice and
their inter-relationships. The figure presents these concepts in the context of an architecture for a particular system and
an associated architectural description. This is not to assume or require that a system has only one architecture or that
there is only one architectural description depicting that architecture. In the figure, boxes represent classes of things.
Lines connecting boxes represent associations between things. An association has two roles (one in each direction). A
IEEE
Std 1471-2000 IEEE RECOMMENDED PRACTICE FOR
role can optionally be named with a label. The role from A to B is closest to B, and vice versa. For example, the roles
between SYSTEM and ENVIRONMENT can be read: A SYSTEM inhabits an ENVIRONMENT, and an ENVIRONMENT influences
a SYSTEM. In the figure, roles are one-to-one unless otherwise noted. A role can have a multiplicity, e.g., a role marked
with “1.*” is used to denote many, as in a one-to-many or many-to-many association. A diamond (at the end of an
association line) denotes a part-of relationship. For example, VIEWS ARCHITECTURAL DESCRIPTION
are a part of an . This
notation is from the Unified Modeling Language Specification [B5].
4.2 Stakeholders and their roles
Stakeholders have various roles with regard to the creation and use of architectural descriptions. Stakehold-
ers include clients, users, the architect, developers, and evaluators. Two key roles among stakeholders are the
acquirer (or client) and the architect.
The architect develops and maintains an architecture for a system to satisfy the acquirer. The architect may
work from requirements provided by an acquirer or may be responsible for eliciting and developing require-
ments as part of the architecture development. The role of the acquirer can be filled by a buyer, customer,
owner, user, or purchaser (see IEEE/EIA Std 12207.0−1996 ). The role of the architect can be filled by dif-
ferent persons, teams, or organizations throughout the life cycle of the architecture.
The architect records the architecture for the system’s stakeholders in the form of an architectural descrip-
tion. In this form, the architecture serves to guide the system’s developers.
4.3 Architectural activities in the life cycle
Architecting contributes to the development, operation, and maintenance of a system from its initial concept
until its retirement from use. As such, architecting is best understood in a life cycle context, not simply as a
single activity at one point in that life cycle.
Architecting is concerned with developing satisfactory and feasible system concepts, maintaining the
integrity of those system concepts through development, certifying built systems for use, and assuring those
system concepts through operational and evolutionary phases.
Detailed systems engineering activities, such as detailed requirements definition and interface specification
and the architecting of major subsystems are tasks that typically follow development of the system
architecture.
This recommended practice neither assumes nor prescribes a specific life cycle model—a life cycle model is
to be separately chosen by users of the recommended practice. The scenarios in 4.3.1–4.3.4 are intended to
suggest the range of uses of the recommended practice within a system life cycle.
4.3.1 Scenario: architecture of single systems
For new system construction, in cases where the user and the acquirer are identical, architecting is carried
out in response to the user-acquirer’s vision for the system, the system goals, and stakeholders’ needs and
constraints. The primary stakeholders are the user-acquirer and the system developers.
The architectural description can be used throughout the life cycle to predict the fitness for use of a system
whose architecture conforms to the architectural description. In addition, the AD will typically evolve
throughout the life cycle, and can thus act as a means for assessing changes to the system.
Information on references can be found in Clause 2.
6 Copyright © 2000 IEEE. All rights reserved.

IEEE
ARCHITECTURAL DESCRIPTION OF SOFTWARE-INTENSIVE SYSTEMS Std 1471-2000
4.3.2 Scenario: iterative architecture for evolutionary systems
Under this scenario, the architecture, the delivered systems, and the stakeholders coevolve. An initial archi-
tecture is prepared in response to current and expected user needs using current and estimated technological
capabilities. Initial systems are delivered using this architecture. As the architecture evolves in response to
new stakeholders’ needs, systems are delivered based on the architecture current at the time of development.
Likewise, the set of stakeholders in the systems and architecture will change as the architecture evolves.
For evolutionary systems, the architectural description is used for system development and evaluation, but its
uses and development are concurrent. Stakeholder needs are reassessed with each iteration of the architec-
ture; the AD is used to guide each system as it moves through development, and appropriate AD versions are
used to evaluate each system on delivery. Architectures developed under this scenario will naturally empha-
size flexibility and adaptability more strongly than single system architectures. Architectural descriptions for
evolving systems will typically be developed in an iterative pattern, or rhythm, of version changes.
The architecture development will normally be carried out by the developer as part of the overall activity of
developing a sequence of systems. The architecture can also be established by the acquirer as a way of orga-
nizing the acquisition and evolution of a sequence of systems. This approach is one way to evolve a product
line architecture. Evolution of the architecture will normally be sponsored by the acquirer as a part of the
overall activity of sequential development or, in the case of commercial-off-the-shelf software, deployment
of systems.
4.3.3 Scenario: architecture of existing systems
A third scenario occurs when system development has taken place without an architectural description, or
when the AD, and perhaps the architect, are no longer available. The built system will have an architecture
(since every system has an architecture, whether known or not) but it will lack an architectural description.
In this case, an AD can be created through a reverse-engineering effort.
Using this recommended practice, an architectural description of the existing system is first constructed.
This AD is then used to develop a new system, to guide maintenance or evolution activities, or to establish an
evolutionary architecture as in the scenarios above (see 4.3.1 and 4.3.2).
In some cases, a new AD is needed because the original description does not provide views that are neces-
sary later in a system’s life cycle.
4.3.4 Scenario: architectural evaluation
The purpose of evaluation is to determine the quality of an architectural description and to predict the quality
of systems whose architectures conform to the architectural description.
Quality of an architectural description refers to its capability to meet the needs and concerns of the stake-
holders for whom it was constructed. Such concerns typically include understandability, consistency, com-
pleteness, and analyzability of the description.
Prediction of the quality of systems resulting from the architectural description includes such qualities as
feasibility, efficiency, and reliability.
In order to evaluate conformance of an architecture to an architectural description, a process for reverse
engineering an architectural description from an implementation is needed (see 4.3.3).
IEEE
Std 1471-2000 IEEE RECOMMENDED PRACTICE FOR
4.4 Uses of architectural descriptions
Architectural descriptions are applicable to a variety of uses, by a variety of stakeholders, throughout the life
cycle. These uses include, but are not limited to the following:
a) Analysis of alternative architectures
b) Business planning for transition from a legacy architecture to a new architecture
c) Communications among organizations involved in the development, production, fielding, operation,
and maintenance of a system
d) Communications between acquirers and developers as a part of contract negotiations
e) Criteria for certifying conformance of implementations to the architecture
f) Development and maintenance documentation, including material for reuse repositories and training
materials
g) Input to subsequent system design and development activities
h) Input to system generation and analysis tools
i) Operational and infrastructure support; configuration management and repair; redesign and mainte-
nance of systems, subsystems, and components
j) Planning and budget support
k) Preparation of acquisition documents (e.g., requests for proposal and statements of work)
l) Review, analysis, and evaluation of the system across the life cycle
m) Specification for a group of systems sharing a common set of features, (e.g., product lines)
5. Architectural description practices
This clause defines practices of architectural description that enable the uses outlined in 4.4. An architectural
description conforming to this recommended practice meets the requirements set forth in this clause. Con-
forming architectural descriptions include the following elements (as delineated in the remainder of this
clause):
a) AD identification, version, and overview information (see 5.1)
b) Identification of the system stakeholders and their concerns judged to be relevant to the architecture
(see 5.2)
c) Specifications of each viewpoint that has been selected to organize the representation of the architec-
ture and the rationale for those selections (see 5.3)
d) One or more architectural views (see 5.4)
e) A record of all known inconsistencies among the architectural description’s required constituents
(see 5.5)
f) A rationale for selection of the architecture (see 5.6)
NOTE—This recommended practice does not specify a delivery format for an architectural description.
5.1 Architectural documentation
An AD shall contain the following information pertaining to the AD as a whole:
a) Date of issue and status
b) Issuing organization
8 Copyright © 2000 IEEE. All rights reserved.

IEEE
ARCHITECTURAL DESCRIPTION OF SOFTWARE-INTENSIVE SYSTEMS Std 1471-2000
c) Change history
d) Summary
e) Scope
f) Context
g) Glossary
h) References
The detailed form and content of the corresponding information items shall be determined by the using orga-
nization. These items were selected to allow users to satisfy the requirements of IEEE/EIA Std 12207.0–
1996.
5.2 Identification of stakeholders and concerns
An AD shall identify the stakeholders considered by the architect in formulating the architectural concept for
the system.
At a minimum, the stakeholders identified shall include the following:
a) Users of the system
b) Acquirers of the system
c) Developers of the system
d) Maintainers of the system
An AD shall identify the concerns considered by the architect in formulating the architectural concept for the
system.
At a minimum, the concerns identified should include the following:
— The purpose or missions of the system
— The appropriateness of the system for use in fulfilling its missions
— The feasibility of constructing the system
— The risks of system development and operation to users, acquirers, and developers of the system
— Maintainability, deployability, and evolvability of the system
The specific intent of the terms mission, appropriateness, and feasibility will vary from system to system. An
AD shall further specify the concerns identified in the context of the system of interest.
5.3 Selection of architectural viewpoints
An AD shall identify the viewpoints selected for use therein.
Each viewpoint shall be specified by
a) A viewpoint name,
b) The stakeholders to be addressed by the viewpoint,
c) The concerns to be addressed by the viewpoint,
d) The language, modeling techniques, or analytical methods to be used in constructing a view based
upon the viewpoint,
IEEE
S
...