Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Software design description.
Nothing was collected or created yet.
Software design description
View on Wikipediafrom Wikipedia
 | This article needs additional citations for verification. (September 2014) |
| IEEE software life cycle |
|---|
A software design description (a.k.a. software design document or SDD; just design document; also Software Design Specification) is a representation of a software design that is to be used for recording design information, addressing various design concerns, and communicating that information to the design’s stakeholders. [1] An SDD usually accompanies an architecture diagram with pointers to detailed feature specifications of smaller pieces of the design. Practically, the description is required to coordinate a large team under a single vision, needs to be a stable reference, and outline all parts of the software and how they will work.
Composition
[edit]The SDD usually contains the following information:
- The Data-driven design describes structures that reside within the software. Attributes and relationships between data objects dictate the choice of data structures.
- The architecture design uses information flowing characteristics, and maps them into the program structure. The transformation mapping method is applied to exhibit distinct boundaries between incoming and outgoing data. The data flow diagrams allocate control input, processing and output along three separate modules.
- The interface design describes internal and external program interfaces, as well as the design of the human interface. Internal and external interface designs are based on the information obtained from the analysis model.
- The procedural design describes structured programming concepts using graphical, tabular and textual notations.
These design mediums enable the designer to represent procedural detail, that facilitates translation to code. This blueprint for implementation forms the basis for all subsequent software engineering work.
IEEE 1016
[edit]IEEE 1016-2009, titled IEEE Standard for Information Technology—Systems Design—Software Design Descriptions,[2] is an IEEE standard that specifies "the required information content and organization" for an SDD.[3] IEEE 1016 does not specify the medium of an SDD; it is "applicable to automated databases and design description languages but can be used for paper documents and other means of descriptions."[4]
The 2009 edition was a major revision to IEEE 1016-1998, elevating it from recommended practice to full standard. This revision was modeled after IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-intensive Systems, extending the concepts of view, viewpoint, stakeholder, and concern from architecture description to support documentation of high-level and detailed design and construction of software. [IEEE 1016, Introduction]
Following the IEEE 1016 conceptual model, an SDD is organized into one or more design views. Each design view follows the conventions of its design viewpoint. IEEE 1016 defines the following design viewpoints for use:[5]
- Context viewpoint
- Composition viewpoint
- Logical viewpoint
- Dependency viewpoint
- Information viewpoint
- Patterns use viewpoint
- Interface viewpoint
- Structure viewpoint
- Interaction viewpoint
- State dynamics viewpoint
- Algorithm viewpoint
- Resource viewpoint
In addition, users of the standard are not limited to these viewpoints but may define their own.[6]
IEEE status
[edit]IEEE 1016-2009 is currently listed as 'Inactive - Reserved'.[7]
See also
[edit]References
[edit]- ^ IEEE Standard for Information Technology--Systems Design--Software Design Descriptions. IEEE STD 1016-2009. July 2009. pp. 1–35. doi:10.1109/ieeestd.2009.5167255. ISBN 978-0-7381-5925-6.
- ^ IEEE Standard for Information Technology--Systems Design--Software Design Descriptions. IEEE. 2009-07-20. doi:10.1109/IEEESTD.2009.5167255. ISBN 978-0-7381-5925-6.
- ^ IEEE 1016, Abstract.
- ^ IEEE 1016, Abstract.
- ^ IEEE 1016, Clause 5.
- ^ IEEE 1016, sub-clause 4.5.
- ^ IEEE Standard for Information Technology--Systems Design--Software Design Descriptions. IEEE STD 1016-2009. July 2009. pp. 1–35. doi:10.1109/IEEESTD.2009.5167255. ISBN 978-0-7381-5925-6.
External links
[edit]
Software design description
View on Grokipediafrom Grokipedia
A software design description (SDD) is a representation of a software design that records and communicates design information to stakeholders, serving as a key artifact in software engineering to document the architecture, components, and decisions of a software system.[1] Standardized primarily by IEEE Std 1016-2009, the SDD establishes requirements for its content, organization, and use of design languages to ensure completeness, consistency, and effective communication throughout the software life cycle.[2] It applies to diverse software types, including commercial, scientific, and military systems, and can be presented in formats such as paper documents, automated databases, or specialized tools.[1]
The SDD typically includes sections on identification (covering scope, authorship, and dates), design stakeholders and their concerns, multiple design views organized by viewpoints (such as context, composition, and logical views among 12 defined viewpoints), design elements (including entities, relationships, attributes, and constraints), and design overlays with rationale for decisions.[1] This structure supports traceability from requirements to implementation and facilitates maintenance, verification, and evolution of software systems.[3] Originating from the 1987 IEEE recommended practice and revised in 1998 and 2009, the standard aligns with broader software engineering frameworks like ISO/IEC/IEEE 12207 for life cycle processes and emphasizes conformance through specified clauses on content and viewpoints.[4] In practice, such as in U.S. Department of Defense acquisitions, the SDD describes computer software configuration items (CSCIs), detailing high-level and detailed designs to guide development and integration.[5]
This pseudocode illustrates a bubble sort, with rationale for selection based on performance. Constraints, such as performance thresholds or security measures, guide development.[1]
Design overlays (Clause 4.7) present additional information tied to specific viewpoints, such as variability or deployment details, enhancing the primary views without altering their structure.[1]
The design rationale section (Clause 4.8) captures the reasoning behind decisions, including issues addressed, options considered, trade-offs, and justifications, supporting traceability and maintenance. It links design choices back to stakeholder concerns and requirements.[1]
The design languages section (Clause 4.9) specifies the standardized languages or notations used (e.g., UML), including syntax, semantics, and any custom definitions, ensuring consistent representation.[1]
Traceability is ensured throughout these sections, often via a tabular mapping (traceability matrix) that links design elements to requirements. Typically presented as a table, it includes columns for requirement ID, description, design element(s) addressing it, and verification method. For example:
This matrix confirms all requirements are addressed and identifies gaps, though not a standalone required section.[1]
Definition and Purpose
Definition
A Software Design Description (SDD) is a formal document that provides a comprehensive textual and diagrammatic representation of the design of a software system, capturing its architecture, components, interfaces, and data structures to guide development. It acts as a critical bridge between the software requirements and the implementation phases, transforming high-level requirements into a structured blueprint for construction.[6][5] Essential characteristics of an SDD include unambiguity, ensuring that design elements are described clearly to avoid misinterpretation; traceability, which links each design decision or component directly to originating requirements for validation; and verifiability, allowing the design to be assessed against predefined goals through review, simulation, or prototyping. These attributes enable effective communication among stakeholders and support subsequent development activities.[4] In contrast to a Software Requirements Specification (SRS), which delineates what the software must achieve in terms of functions and performance, an SDD focuses on how the system will be architected and operate, including internal structures, algorithms, and inter-component behaviors.[5][6]Purpose and Benefits
The software design description (SDD) serves as a critical bridge between software requirements and implementation, providing a structured representation of the design that guides the transition from high-level specifications to executable code.[7] Its primary purposes include communicating design decisions to diverse stakeholders, such as developers, testers, and project managers, to ensure alignment on the system's architecture and functionality.[4] The SDD also directs implementation teams by detailing algorithms, data structures, and interfaces, thereby streamlining the coding process and minimizing deviations from intended designs.[1] Furthermore, it establishes a baseline for ongoing maintenance and system evolution, allowing teams to reference and update the design as requirements change over time.[4] Key benefits of an SDD encompass improved traceability, which links design elements directly to requirements for easier verification and validation during development.[1] It reduces ambiguity by clarifying complex decisions and assumptions, fostering consistency across the project and preventing costly rework due to misunderstandings.[7] The document facilitates thorough reviews and testing by providing a comprehensive view of the design, enabling early identification of flaws through structured inspections.[7] Additionally, it supports risk management by highlighting potential issues in architecture or interfaces before implementation, thereby lowering overall project risks and enhancing long-term maintainability.[1] In practice, SDDs are essential for large-scale projects, where coordinating multiple teams demands clear documentation to maintain coherence.[5] They are particularly vital in safety-critical domains, such as aerospace software, where NASA guidelines mandate SDDs to describe configuration items and ensure compliance with rigorous verification processes. Similarly, in regulated medical device software under IEC 62304, design documentation details software units and interfaces to meet lifecycle requirements for safety and reliability.[8]Historical Development
Origins in Software Engineering
The concept of software design description emerged during the 1960s and 1970s amid the growing recognition of a "software crisis," characterized by escalating costs, delays, and reliability issues in large-scale software projects.[9] This crisis was prominently discussed at the 1968 NATO Conference on Software Engineering in Garmisch, Germany, where participants highlighted the urgent need for systematic documentation practices to manage complexity in systems like IBM's OS/360, which demanded thousands of man-years of effort yet suffered from persistent errors and inefficiencies.[9] Conference proceedings emphasized that inadequate documentation contributed to these problems, advocating for early and hierarchical documentation of modular interfaces and designs to facilitate review, maintenance, and production quality.[9] Parallel to these discussions, structured programming practices in the late 1960s and early 1970s provided foundational influences by promoting disciplined, modular code organization to replace unstructured approaches like unrestricted use of goto statements.[10] Edsger Dijkstra's influential 1968 letter, "Go To Statement Considered Harmful," argued that such unstructured coding led to incomprehensible programs, underscoring the need for clear, hierarchical design descriptions to ensure readability and verifiability before implementation.[10] These ideas, echoed in the NATO conference's calls for predocumentation and layered design notations, laid the groundwork for formalizing software design as a distinct, documented phase separate from coding.[9] A key milestone came in 1970 with Winston Royce's paper "Managing the Development of Large Software Systems," which introduced the waterfall model as a sequential methodology emphasizing comprehensive design documentation prior to coding.[11] Royce advocated documenting the program design completely during preliminary phases, including system and detailed design, to mitigate risks in large projects and ensure traceability from requirements to implementation.[11] This approach addressed the era's prevalent issues, such as underestimation of design and documentation efforts, which often resulted in scheduling failures and unmaintainable code.[11] The lack of formal design processes in early software development frequently produced tangled, error-prone systems that were difficult to maintain or modify, prompting the evolution of software design descriptions as a structured response to enforce rigor and communication among teams.[9] By formalizing design artifacts, these early practices aimed to combat the software crisis's core symptoms, setting the stage for later standardization efforts.[11]Evolution of Standards
Formal standardization of software design descriptions (SDDs) began with the IEEE Std 1016-1987, a recommended practice that outlined the essential information content and organization for communicating software designs without restricting methodologies.[12] This early standard provided a dedicated guideline for SDDs and influenced subsequent military and international lifecycle standards in the mid-1990s. The U.S. Department of Defense's MIL-STD-498, released in 1994, established uniform requirements for software development and documentation across the acquisition lifecycle, mandating detailed design artifacts such as interface design descriptions and software design descriptions to ensure traceability and maintainability.[13] This standard directly referenced the existing IEEE 1016 as a foundational practice for SDDs, influencing subsequent civilian adaptations by promoting consistent documentation in complex, mission-critical systems. Similarly, the ISO/IEC 12207 standard, published in 1995, introduced a comprehensive framework for software lifecycle processes, including explicit requirements for design processes that necessitate documented representations of software architecture, interfaces, and components to support verification, validation, and reuse.[14] IEEE 1016 was revised in 1998 as IEEE Std 1016-1998, refining the structure to accommodate diverse media and emphasizing hierarchical decomposition, interface details, and design rationale for broader applicability in software engineering projects.[15] The standard evolved further with the 2009 revision, IEEE Std 1016-2009, which elevated it from recommended practice to a full standard and incorporated provisions for modern paradigms such as object-oriented design and component-based architectures, enabling more flexible representations of complex systems like distributed and service-oriented applications.[2] For broader international applicability, IEEE 1016 has been aligned with ISO lifecycle standards, particularly through harmonization efforts with ISO/IEC/IEEE 12207:2008, ensuring that SDDs integrate seamlessly into global software process frameworks for acquisition, development, and maintenance.[16] This alignment facilitates cross-border adoption by mapping SDD elements to ISO-defined design outcomes, such as architectural views and behavioral models. The standard's current status is inactive-reserved, as designated by IEEE in 2020, indicating it remains a valid reference without active maintenance.[2]IEEE 1016 Standard
Overview
The IEEE Standard for Information Technology—Systems Design—Software Design Descriptions, known as IEEE 1016-2009, serves as the primary guideline for creating software design descriptions (SDDs) in software engineering. Published on July 20, 2009, by the IEEE Standards Association, this standard provides a structured framework for documenting software designs, emphasizing clarity and completeness to support effective communication among stakeholders.[2] The scope of IEEE 1016-2009 encompasses the documentation of both high-level and detailed software designs, applicable to any software project regardless of its size, complexity, criticality, or development methodology. It is suitable for commercial, scientific, and military applications on digital computers, and extends to traditional software construction as well as reverse engineering efforts. The standard remains neutral on specific design methodologies, configuration management practices, or quality assurance processes, while permitting flexibility in the choice of design languages or notations.[2] The primary objectives of the standard are to ensure that SDDs are consistent, complete, and readily usable for activities such as verification, validation, and maintenance of software systems. By establishing requirements for the content and organization of SDDs, it facilitates their preparation in diverse formats, including paper documents, automated databases, or specialized software tools, thereby enhancing design communication and long-term project sustainability. This version builds on the historical evolution of the standard, which originated as a recommended practice in 1987 and was revised in 1998 to align with emerging software engineering norms.[2][4]Key Provisions
The IEEE 1016-2009 standard mandates that a software design description (SDD) incorporate multiple design views to comprehensively represent the software from diverse perspectives, ensuring that each view addresses specific stakeholder concerns such as functionality, structure, and data handling.[2] These views are governed by defined viewpoints, including examples like the context viewpoint for external interactions, composition viewpoint for hierarchical structure, logical viewpoint for functional elements (e.g., via UML class diagrams), and information viewpoint for data modeling (e.g., using IDEF1X).[2] This multi-view approach facilitates a holistic understanding of the design without redundancy, as specified in Section 4.4 and detailed in Section 5 of the standard.[2] Traceability and consistency form core requirements for SDDs, requiring explicit linkages between design elements and the corresponding software requirements specification (SRS) to demonstrate how requirements are addressed.[2] Internal coherence must be maintained, with no conflicts among design views or elements, and design rationale sections must justify decisions by tracing them back to requirements (Sections 3.2.1, 4.4, and 4.8).[2] This ensures the SDD serves as a verifiable bridge between requirements and implementation, supporting subsequent development and maintenance activities. The standard provides guidelines for notations in SDDs, recommending the use of formal, well-defined design languages with precise syntax and semantics to enhance clarity and interoperability.[2] Preferred notations include standardized ones such as UML for diagrammatic representations and IDEF0 for process modeling, supplemented by textual descriptions to explain diagrams and avoid ambiguity (Section 4.9).[2] Annex B further outlines how to uniformly describe any selected design language for consistent application. Customization is explicitly allowed in the standard to adapt the SDD's content and organization to the project's scale, complexity, and type, without restricting applicability to specific software domains (Section 1.1).[2] This flexibility permits the definition of additional viewpoints or notations as needed (Sections 4.5 and 4.9), promoting practicality while upholding essential informational requirements.[2] The provisions align with broader software lifecycle processes outlined in IEEE Std 12207-2008, integrating SDDs into requirements analysis, verification, and validation phases (Section 3.2).[2][1]Document Structure and Composition
Required Sections
The required sections of a Software Design Description (SDD) form the core structure mandated by IEEE Std 1016-2009 Clause 4, ensuring that the document comprehensively captures the design's essential elements to facilitate understanding, verification, and implementation. These sections include SDD identification, design stakeholders and concerns, design views, design viewpoints, design elements, design overlays, design rationale, and design languages, each addressing specific aspects of the software design to align with stakeholder needs and requirements traceability.[1] The SDD identification provides foundational metadata and context for the document, including the date, status, scope, organization, authorship, references to related documents (such as requirements specifications or predecessor designs), and any key definitions or acronyms. It also covers the design languages used, body structure, summary, glossary, and change history. This section establishes the SDD's dependencies and boundaries, specifying what is included (e.g., specific modules or subsystems) and excluded, ensuring readers quickly grasp the document's relevance without delving into technical details.[1] The design stakeholders and concerns section identifies relevant stakeholders and articulates their specific design concerns, ensuring that the SDD addresses all pertinent perspectives, such as performance needs for end-users or maintainability for developers. This promotes completeness by mapping concerns to subsequent design views.[1] The design overview is presented through design views and viewpoints, providing a high-level abstraction of the software architecture. Design views (Clause 4.4) organize the design into multiple perspectives selected from the 13 predefined viewpoints in Clause 5 (such as context, composition, logical, process, and interface views), describing major components, their interactions, and system partitioning into subsystems or layers. Design viewpoints (Clause 4.5) specify the name, concerns addressed, elements, languages, methods, evaluation criteria, and rationale for each selected viewpoint. Assumptions—such as hardware constraints or environmental factors—and dependencies on external elements (e.g., third-party libraries or hardware interfaces) are explicitly stated, often illustrated with diagrams like block diagrams or data flow charts. This overview bridges requirements and detailed implementation.[1] The design elements section (Clause 4.6) elaborates on implementation specifics for reproducibility and verifiability, detailing entities (e.g., modules or classes), relationships, attributes (such as name, type, purpose), and constraints. Component descriptions cover purpose, inputs/outputs, and internal behavior, using hierarchical decomposition. Interfaces specify protocols, data formats, and error handling (e.g., API signatures). Data structures define attributes, types, relationships, and persistence (e.g., a user database schema with ID as integer, name as string). Algorithms are described step-by-step, including pseudocode; for instance, a sorting algorithm might be outlined as:Algorithm SortArray(input: array A of elements)
1. For i from 0 to length(A)-2
2. For j from 0 to length(A)-1-i
3. If A[j] > A[j+1]
4. Swap A[j] and A[j+1]
5. End For
6. End For
Return A
Algorithm SortArray(input: array A of elements)
1. For i from 0 to length(A)-2
2. For j from 0 to length(A)-1-i
3. If A[j] > A[j+1]
4. Swap A[j] and A[j+1]
5. End For
6. End For
Return A
| Requirement ID | Requirement Description | Design Element(s) | Verification Method |
|---|---|---|---|
| REQ-001 | System shall authenticate users securely | UserAuth Component, Login Interface | Unit Testing |
| REQ-002 | Data shall be stored in relational DB | DatabaseSchema Data Structure | Integration Testing |