IEEE 1016:2009 pdf free download – IEEE Standard for Information Technology – Systems Design – Software Design Descriptions
3.1 Software design in context
A design is a conceptualization of a design subject (the system under design or software under design) thatembodies its essential characteristics; demonstrates a means to fulfill its requirements; serves as a basis foranalysis and evaluation and can be used to guide its implementation.(See Abran and Moore [Bl] forfurther discussion.)
NOTE 1—This standard does not establish what a design subject may be. A design subject can be any software item tobe constructed or which already exists and is to be analyzed. Exampies of possible design subjects include, but are notlimited to， systems，subsystems，applications，components，libraries，application frameworks，application programinterfaces (APIs), and design pattern catalogs.
An SDD is a work product depicting some design subject of interest. An SDD can be produced to captureone or more levels of concern with respect to its design subject. These levels are usually determined by thedesign methods in use or the life cycle context; they have names such as “architectural design,””logicaldesign,” or “”physical design.””
An SDD can be prepared and used in a variety of design situations.Typically,an SDD is prepared tosupport the development of a software item to solve a problem, where this probiem has been expressed interms 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 toall interested parties. This information of interest can be used for planning, analysis，implementation andevolution 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 theterminology of its predecessor, IEEE Sid 1016-1998, and (2) to refer to a range of work products typically defined inuse. For example，software design description covers the following information items identified in ISOIEC15289:2006 [B25]:3databasc design description (10.14),database detailed design description (10.15),high-levelsoftware design description (10.22), interface description (10.27), low-level software design description(10.29), systemdescription (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 fromspecific requirements on the software, others arise from contextual constraints.Typical design concernsinclude functionality，reliability，performance， and maintainability.Typical design stakeholders includeusers,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 withconvenient inputs (design diagrams and specifications produiced by designers) and outputs (results of transformationsproduced by software tools).The design space typically contains alternative designs and design rationale in addition tothe minimal information of the current version of design.An interesting property of a design description as a system isthat its configuration is subject to dynamic evolution and the respective state space, based on its design clements, is notgiven in advance but created iteratively in a manner of system analysis by ‘synthesis. The final design synthesis isobtained via successive analysis of intermediate designs. Therefore, an SDD can be considered an open, goal-directedsystem 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.
NOTE4—The use of multiple views to achieve separation of concerns has a long history in software engineering (secRoss,Goodenough, and Irvine [B33] and Ross [B31), recently in viewpoint-oriented requirements engineering (seeNuseibeh,Kramer, and Finkelstein [B27), and particularly relevant to this standard, the use of views to rationallypresent the results of a design process (sce Parnas and Clements [B30J) and their use during design (see Gomma[B11]).The particular formulation here is derived from IEEE Std 1471 TM-2000 [B20].
Each design view is governed by a design viewpoint. Each design viewpoint focuses on a set of the designconcerns and introduces a set of descriptive resources called design elements that are used to construct andinterpret the design view.