IEEE 1016-2009 pdf free downoad – IEEE Standard for Information Technology—Systems Design— Software Design Descriptions.
3. Conceptual model for software design descriptions This clause establishes a conceptual model for SDDs. The conceptual model includes basic terms and concepts of SDD, the context in which SDDs are prepared and used, the stakeholders who use them, and how they are used.
3.1 Software design in context A design is a conceptualization of a design subject (the system under design or software under design) that embodies its essential characteristics; demonstrates a means to fulfill its requirements; serves as a basis for analysis and evaluation and can be used to guide its implementation. (See Abran and Moore [B1] for further discussion.)
NOTE 1—This standard does not establish what a design subject may be. A design subject can be any software item to be constructed or which already exists and is to be analyzed. Examples of possible design subjects include, but are not limited to, systems, subsystems, applications, components, libraries, application frameworks, application program interfaces (APIs), and design pattern catalogs.
An SDD is a work product depicting some design subject of interest. An SDD can be produced to capture one or more levels of concern with respect to its design subject. These levels are usually determined by the design methods in use or the life cycle context; they have names such as “architectural design,” “logical design,” or “physical design.” An SDD can be prepared and used in a variety of design situations. Typically, an SDD is prepared to support the development of a software item to solve a problem, where this problem has been expressed in terms of a set of requirements. The contents of the SDD can then be traced to these requirements. In other cases, an SDD is prepared to understand an existing system lacking design documentation. In such cases, an SDD is prepared such that information of interest is captured, organized, presented and disseminated to all interested parties. This information of interest can be used for planning, analysis, implementation and evolution of the software system, by identifying and addressing essential design concerns.
NOTE 2—The generic term software design description is used in this standard (1) to retain compatibility with the terminology of its predecessor, IEEE Std 1016-1998, and (2) to refer to a range of work products typically defined in use. For example, software design description covers the following information items identified in ISO/IEC 15289:2006 [B25]: 5 database design description (10.14), database detailed design description (10.15), high-level software design description (10.22), interface description (10.27), low-level software design description (10.29), system description (10.71), and system element 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 stakeholders. Frequently, design concerns arise from specific requirements on the software, others arise from contextual 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 SDD captures the information content of the design space with convenient inputs (design diagrams and specifications produced by designers) and outputs (results of transformations produced by software tools). The design space typically contains alternative designs and design rationale in addition to the minimal information of the current version of design. An interesting property of a design description as a 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 synthesis.
The final design synthesis is obtained via successive analysis of intermediate designs. Therefore, an SDD can be considered an open, goal-directed system whose end state is a detailed model of the system under design. An SDD 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 engineering (see Ross, Goodenough, and Irvine [B33] and Ross [B31]), recently in viewpoint-oriented requirements engineering (see Nuseibeh, Kramer, and Finkelstein [B27]), and particularly relevant to this standard, the use of views to rationally present the results of a design process (see Parnas and Clements [B30]) and their use during design (see Gomma [B11]). The particular formulation here is derived from IEEE Std 1471™-2000 [B20]. Each design view is governed by a design viewpoint.IEEE 1016 pdf download.