IEEE 1016-2009 pdf download

IEEE 1016-2009 pdf download.IEEE Standard for InformationTechnology- Systems Design-Software Design Descriptions.
NOTE 2— The generic tern soutsssrrn cksign description is used in this standard (I) to retain compatibility with the terminology of its predecessor, IEEE Std 1016-19911 and (2) to refer to a range of work products typically defined in use. For example, software design description covers the following inforniaiion items identified in lSO:IE 15259:2006 [825): database design description (10.14), database detailed design description (10.15). high-level software design description (10.22). interface description (10.271. low-level software design description (10,29). system description (10.71). and system elesnent description (10.72).
A design concern names any area of interest in the design, pertaining to its development, implementation. or operation. Design concerns are expressed by design stakebolders. Frequently, design concerns arise from specific requirements on the software, others arise from contestual constraints. Typical design concerns include functionality, reliability, performance, and maintainability. Typical design stakeholders include users, developers, software designers, system integrators. maintainers, acquirers. and project managers.
NOTE 3—From a system-theoretic standpoint, an SOD captures the infornsatiott content of the design space with convenient inputs (design diagrams and specifications produced by designers) and outputs (results of tninsfonnations produced by software tools). The design space typically contains altemative designs and design rationale in addition to the minimal information of tlse current version of design. An interesting property of a design description as system is that its configuration is subject to dynamic evolution and the respective state space, based on its design elements. is not given in advance but created iteratively in a manner of system analysis by synthests. The final design synthesis is obtained via successive analysis of intermediate designs. Therefore, an 501) can he considered an open, goal-directed system whose end state is a detailed model of the system under design.
An is organized using design views. A design view addresses one or more of the design concerns.
NOTE 4 -The use of multiple views to achieve separation of concerns has a long history in software enginccnng (see
Ross, (loodeisough, and Irvine (833) and Ross [14311). recently in viewpoint-oriented requirements engineering (see Nuseit,eh. K.nuner. and Finkelstein 1827]). and particularly relevant to this standard, the use of views to rationally present the results of a design process (ice Parnaa and Clcmnenta (8301) and their use during design (see Ciununa 111111). The panicular fonnulation here is derived from IEEE Std 1471 ist2Oft(t (820).
Each design view is governed by a design viewpoint. Each design viewpoint focuses on a set of the design concerns and introduces a set of descriptive resources called design elements that are used to construce and interpret the design view.
Eeampk:
A viewpoint can introduce familiar design elements such as functions, input and outputs: these elements are used to construct a functional view.
There are four kinds of design elements: design entities, design relationships, design attributes, and design constraints. A desigtt viewpoint determines the types of design elements to be used in any design views it governs. Each design view is expressed as a collection of instances of design entities, design attributes. design relationships among design entities, and design constraints on those elements. The design information needs of stakeholders of the system under design are to be satistied through use of these elements.
NOTE 5 Although a view need not be a graph, its content is frequently described using diagrams that may be formalized as extensions or specializations of conceptual graphs of design elements (see ISO draft Conctynua! Graphs (8221).
It is sometimes useful to gather and present information that does not strictly tollow the partitioning of information by dcsign vicwpoinls. A design overlay is a mechanism to organize and present such additional design information.
Design involves the consideration and evaluation of alternatives and trade-oils among alternatives leading to decisions (see Abran and Moore [1311). Design decisions and the design rationale for decisions are captured both to aid the understanding of current design sinkeholders and to support future decision-making (see IEEE Std 12207-200K (B21J).
The key concepts of SDD are depicted in Figure Ia and Figure lb.