logo Use SA10RAM to get 10%* Discount.
Order Now logo

Ask This Question To Be Solved By Our ExpertsGet A+ Grade Solution Guaranteed

StatAnalytica ExpertResume writing

838 Answers

Hire Me
Tracy BartramEnglish

634 Answers

Hire Me
StatAnalytica ExpertEducation

613 Answers

Hire Me
Hal CruttendenData mining

631 Answers

Hire Me

SDD describes design goals and considerations, provides a high-level overview of the system architecture.


System Design Document


Instructions: Provide identifying information for the existing and/or proposed automated system or situation for which the SDD applies (e.g., the full names and acronyms for the development project, the existing system or situation, and the proposed system or situation, as applicable), and expected evolution of the document. Also describe any security or privacy considerations associated with use of this document.

The System Design Document (SDD) describes how (1) the functional and nonfunctional requirements recorded in the Requirements Document, (2) the preliminary user-oriented functional design recorded in the High Level Technical Design Concept/Alternatives document, and (3) the preliminary data design documented in the Logical Data Model (LDM) are transformed into more technical system design specifications from which the system will be built. The SDD is used to document both high-level system design and low-level detailed design specifications.

The SDD describes design goals and considerations, provides a high-level overview of the system architecture, and describes the data design associated with the system, as well as the human-machine interface and operational scenarios. The high-level system design is further decomposed into low-level detailed design specifications for each of the system’s components, including hardware, internal communications, software, system integrity controls, and external interfaces. The high-level system design serves as primary input to the Preliminary Design Review (PDR). The low-level detailed design serves as input to the Detailed Design Review (DDR).

1.1 Purpose of the System Design Document

Instructions: Provide the purpose of the System Design Document. This document should be tailored to fit a particular project’s needs.

The System Design document documents and tracks the necessary information required to effectively define architecture and system design in order to give the development team guidance on architecture of the system to be developed. Design documents are incrementally and iteratively produced during the system development life cycle, based on the particular circumstances of the IT project and the system development methodology used for developing the system. Its intended audience is the project manager, project team, and development team. Some portions of this document such as the user interface (UI) may on occasion be shared with the client/user, and other stakeholder whose input/approval into the UI is needed.

2.General Overview and Design Guidelines/Approach

This section describes the principles and strategies to be used as guidelines when designing and implementing the system.

2.1 General Overview

Instructions: Briefly introduce the system context and the basic design approach or organization. Provide a brief overview of the system and software architectures and the design goals. Include the high-level context diagram(s) for the system and subsystems previously provided in the High-Level Technical Design Concept/Alternatives and/or Requirements Document, updated as necessary to reflect any changes that have been made based on more current information or understanding. If the high-level context diagram has been updated, identify the changes that were made and why.

2.2 Assumptions / Constraints / Risks

2.2.1 Assumptions

Instructions: Describe any assumptions or dependencies regarding the system, software and its use. These may concern such issues as: related software or hardware, operating systems, end-user characteristics, and possible and/or probable changes in functionality.

2.2.2  Constraints

Instructions: Describe any global limitations or constraints that have a significant impact on the design of the system’s hardware, software and/or communications, and describe the associated impact. Such constraints may be imposed by any of the following (the list is not exhaustive):

  1. Hardware or software environment

  2. End-user environment

  3. Availability or volatility of resources

  4. Standards compliance

  5. Interoperability requirements

  6. Interface/protocol requirements

  7. Licensing requirements

  8. Data repository and distribution requirements

  9. Security requirements (or other such regulations)

  10. Memory or other capacity limitations

  11. Performance requirements

  12. Network communications

  13. Verification and validation requirements (testing)

  14. Other means of addressing quality goals

  15. Other requirements described in the Requirements Document

3. Design Considerations

Instructions: Describe issues which need to be addressed or resolved before attempting to devise a complete design solution.

3.1  Goals and Guidelines

Instructions: Describe any goals, guidelines, principles, or priorities which dominate or embody the design of the system and its software. Examples of such goals might be: an emphasis on speed versus memory use; or working, looking, or “feeling” like an existing product. Guidelines include coding guidelines and conventions. For each such goal or guideline, describe the reason for its desirability unless it is implicitly obvious. Describe any design policies and/or tactics that do not have sweeping architectural implications (meaning they would not significantly affect the overall organization of the system and its high-level structures), but which nonetheless affect the details of the interface and/or implementation of various aspects of the system (e.g., choice of which specific product to use).


3.2  Architectural Strategies

Instructions: Describe any design decisions and/or strategies that affect the overall organization of the system and its higher-level structures. These strategies should provide insight into the key abstractions and mechanisms used in the system architecture. Describe the reasoning employed for each decision and/or strategy (possibly referring to previously stated design goals and principles) and how any design goals or priorities were balanced or traded-off.

Describe compliance with CMS Enterprise Architecture (EA) and standards. Specifically identify any deviations that were made from the CMS EA and standards, and provide rationale to support the deviation(s). When describing a design decision, discuss any other significant alternatives that were considered, and the reasons for rejecting them (as well as the reasons for accepting the alternative finally chosen). Sometimes it may be most effective to employ the “pattern format” for describing a strategy.

Examples of design decisions might concern (but are not limited to) things like the following:

  1. Use of a particular type of product (programming language, database, library, commercial off-the-shelf (COTS) product, etc.)

  2. Reuse of existing software components to implement various parts/features of the system

  3. Future plans for extending or enhancing the software

  4. User interface paradigms (or system input and output models)

  5. Hardware and/or software interface paradigms

  6. Error detection and recovery

  7. Memory management policies

  8. External databases and/or data storage management and persistence

  9. Distributed data or control over a network

  10. Generalized approaches to control

  11. Concurrency and synchronization

  12. Communication mechanisms

  13. Management of other resources

3.3   Performance Engineering

A contributing factor to System Design will be Performance Requirements.

Performance Requirements are the defined scalability or responsiveness expectations of specific workloads that process on a system.


(a) Using the Performance Requirements defined in the Requirements Document, provide a detailed explanation that describes how the Performance Requirements were incorporated into the system’s design. Please refer to Sections 2.0 of the CMS Performance Test Plan and Results Template for guidance on defining Performance Requirements.

(b) Start preparing Production Load Model(s) in preparation for Performance testing. Please refer to Sections 2.1.1 of the CMS Performance Test Plan and Results Template for guidance on Load Model construction.

4. System Architecture and Architecture Design

This section outlines the system and hardware architecture design of the system that is being built.

Instructions: Describe the system architecture, how the application interacts with other applications. Not necessarily how the application itself works but, how the appropriate data is correctly passed between applications. Provide an overview of how the functionality and responsibilities of the system were partitioned and then assigned to subsystems or components. Don’t go into too much detail about the individual components themselves in this section. A subsequent section of the SDD will provide the detailed component descriptions. The main purpose here is to gain a general understanding of how and why the system was decomposed, and how the individual parts work together to provide the desired functionality.

At the top-most level, describe the major responsibilities that the software must undertake and the various roles that the system (or portion of the system) must play. Describe how the system was broken down into its components/subsystems (identifying each top-level component/subsystem and the roles/responsibilities assigned to it). Describe how the higher-level components collaborate with each other in order to achieve the required results. Provide some sort of rationale for choosing this particular decomposition of the system (perhaps discussing other proposed decompositions and why they were rejected).

Make use of design patterns whenever possible, either in describing parts of the architecture (in pattern format), or for referring to elements of the architecture that employ them. Provide rationale for choosing a particular algorithm or programming idiom (or design pattern) to implement portions of the system’s functionality.

Related Questions

. The fundamental operations of create, read, update, and delete (CRUD) in either Python or Java

CS 340 Milestone One Guidelines and Rubric  Overview: For this assignment, you will implement the fundamental operations of create, read, update,

. Develop a program to emulate a purchase transaction at a retail store. This  program will have two classes, a LineItem class and a Transaction class

Retail Transaction Programming Project  Project Requirements:  Develop a program to emulate a purchase transaction at a retail store. This

. The following program contains five errors. Identify the errors and fix them

7COM1028   Secure Systems Programming   Referral Coursework: Secure

. Accepts the following from a user: Item Name Item Quantity Item Price Allows the user to create a file to store the sales receipt contents

Create a GUI program that:Accepts the following from a user:Item NameItem QuantityItem PriceAllows the user to create a file to store the sales receip

. The final project will encompass developing a web service using a software stack and implementing an industry-standard interface. Regardless of whether you choose to pursue application development goals as a pure developer or as a software engineer

CS 340 Final Project Guidelines and Rubric  Overview The final project will encompass developing a web service using a software stack and impleme

Get Free Quote!

406 Experts Online