ISO IEC IEEE-42010-2011 pdf download Systems and software engineering — Architecture description
4.2.3 Stakeholders and concerns
Stakeholders of a system have concerns with respect to the system-of-interest considered in relation to itsenvironment. A concern could be held by one or more stakeholders. Concerns arise throughout the life cyclerom system needs and requirements, trom design choices and from implementation and operatingconsiderations. A concern could be manifest in many forms, such as in relation to one or more stakeholderneeds,goals,expectations, responsibilities, requirements, design constraints, assumptions, dependenciesquality attributes, architecture decisions, risks or other issues pertaining to the system.
EXAMPLESThe following are concerns in the terms of this lnternational Standard: functionality, feasibility, usagesvstem purposes,sstem features, system properties,known limitations, structure, behavior, performance, resourceutlization, reliability, security,information assurance, complexity, evolvability, openness, concurrency, autonomy, costschedule, quality of service,flexibility, agility, modifability, modularity, control, inter-process communication, deadlockstate chanae. subsvstem intearation, data accessiblity. privacy. compliance to requlation. assurance, business goals ancstrategies, customer experence, maintainability, affordability and disposablity. The distribution transparencies describedin the Reference Model of Open Distributed Processing (ISO/IEC 10746-1 are concerns in the terms of this internationaStandard.Software properties as described in SQUARE (ISO/IEC 25010:2011, 4.2] name concerns in the terms of thisInternational Standard.
4.2.4 Architecture views and viewpoints
An architecture description includes one or more architecture views. An architecture view (or simply, view)addresses one or more of the concerns held by the system’s stakeholders.
An architecture view expresses the architecture of the system-of-interest in accordance with an architectureviewpoint (or simply, viewpoin). There are two aspects to a viewpoint: the concerns it frames for stakeholdersand the conventions it establishes on views
An architecture viewpoint frames’ one or more concerns. A concern can be framed by more than oneviewpoint.
A view is governed by its viewpoint: the viewpoint establishes the conventions for constructing, interpretingand analyzing the view to address concerns framed by that viewpoint. Viewpoint conventions can includelanguages, notations, model kinds, design rules, and/or modelling methods, analysis techniques and otheoperations on views.
Figure 2 depicts the relations between views and viewpoints within an architecture description.
NOTE 1This International Standard does not use phrases such as“business architecture”，“physical architecture”.andtechnical architecture” ln the terms of this lntermational Standard. the architecture of a system is a holistic conception 0that system’s fundamental properties, best understood via multiple views of that architecture. Therefore, approximateequivalents of the above phrases are “business view, “physical view’, and “technical view”, respectively.
NOTE 2Clause 7 specifies requirements on architecture viewpoints. Annex B provides guidance on specifyingviewpoints
4.2.5 Architecture models
An architecture view is composed of one or more architecture models. An architecture model uses modellindconventions appropriate to the concerns to be addressed. These conventions are specified by the model kindgoverning that model. Within an architecture description, an architecture model can be a part of more thanone architecture view.
Figure 2 depicts the use of architecture models and model kinds within an architecture description
NOTEThis lnternational Standard uses the term model kind rather than “architecture model kind” to emphasize thatmodel kinds need not be useful exclusively in architecture descriptions.