System/subsystem Design Description model text

The System/Subsystem Design Description (SSDD) describes the system- or subsystem-wide design and the architectural design of a system or subsystem. The SSDD may be supplemented by Interface Design Descriptions (IDDs) and Database Design Descriptions (DBDDs).

SYSTEM or SUBSYSTEM DESIGN DESCRIPTION

FOR THE

GUIDANCE CONTROLLER

CONTRACT NO.

CDRL SEQUENCE NO.

Prepared for:

Prepared by:

This document contains No. of pages pages

REVIEW AND HISTORY PAGE

CONTENTS

Insert the "Table of Contents" here.

Consult DI-IPSC-81432 and the 'Documentation Standard' when preparing this document.

1. SCOPE

1.1 Identification.

Identify the system to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

1.2 System overview.

State the purpose of the system or subsystem to which this document applies.

1.3 Document overview.

Summarize the purpose and contents of this document.
This document comprises of six sections:

• Scope;
• Referenced documents;
• System-wide design decisions;
• System architectural design;
• Requirements traceability;
• Notes

Describe any security or privacy considerations associated with its use.

2. REFERENCED DOCUMENTS

2.1 Project documents.

Identify the project management systems documents here.

2.1 Other documents.

2.1 Precedence.

2.1 Source of documents.

3. SYSTEM-WIDE DESIGN DECISIONS

This section shall be divided into paragraphs as needed to present system-wide design decisions, that is, decisions about the system's behavioural design (how it will behave, from a user's point of view, in meeting its requirements, ignoring internal implementation) and other decisions affecting the selection and design of system components.

To be continued

4. SYSTEM ARCHITECTURAL DESIGN

Describe the system architectural design in this section.

4.1 System components.

This paragraph shall:

• Identify the components of the system (HWCIs, CSCIs, and manual operations). Each component shall be assigned a project-wide unique identifier. Note: a database may be treated as a CSCI or as part of a CSCI;
• Show the static (such as "consists of") relationship(s) of the components. Multiple relationships may be presented, depending on the selected design methodology;
• State the purpose of each component and identify the system requirements and system-wide design decisions allocated to it. (Alternatively, the allocation of requirements may be provided;
• Identify each component's development status/type, if known (such as new development, existing component to be reused as is, existing design to be reused as is, existing design or component planned for Build N, etc). For existing design or components, the description shall provide identifying information, such as name, version, documentation references, location, etc.
• For each computer system or other aggregate of computer hardware resources identified for use in the system, describe its computer hardware resources (such as processors, memory, input/output devices, auxiliary storage, and communications/network equipment). Each description shall, as applicable, identify the configuration items that will use the resource, describe the allocation of resource (for example, 20% of the resource's capacity allocated to CSCI 1, 30% to CSCI 2), describe the conditions under which utilization will be measured, and describe the characteristics of the resource:
  1. Descriptions of computer processors shall include, as applicable, manufacturer name and model number, processor speed/capacity, identification of instruction set architecture, applicable compiler(s), word size (number of bits in each computer word), character set standard (such as ASCII, EBCDIC), and interrupt capacities.
  2. Descriptions of memory shall include, as applicable, manufacturer name and model number and memory size, type, speed, and configuration (such as 512K Cache memory, 16 MB RAM).
  3. Descriptions of input/output devices shall include, as applicable, manufacturer name and model number, type of device, and device speed/capacity.
  4. Descriptions of auxiliary storage shall include, as applicable, manufacturer name and model number, type of storage, amount of installed storage, and storage speed;
  5. Descriptions of communications/network equipment such as modems, network interface cards, hubs, gateways, cabling, high speed data lines, or aggregates of these or other components, shall include as applicable, manufacturer name and model number, data transfer rates/capacities, network topologies, transmission techniques, and protocols used;
  6. Each description shall also include, as applicable, growth capabilities, diagnostic capabilities, and any additional hardware capabilities relevant to the description.
• Present a specification tree for the system, that is, a diagram that identifies and shows the relationships among the planned specifications for the system components.
  
• 4.2 Concept of execution.
• Describe the concept of execution among the system components. It shall include diagrams and descriptions showing the dynamic relationship of the components, that is, how they will interact during system operation, including, as applicable, flow of execution control, data flow, dynamically controlled sequencing, state transition diagrams, timing diagrams, priorities among components, handling of interrupts, timing/sequencing relationships, exception handling, concurrent execution, dynamic allocation/deallocation, dynamic creation/deletion of objects, processes, tasks, and other aspects of dynamic behaviour.
  
• 4.3 Interface design.
• Describe the interface characteristics of the system components.
• 4.3.1 Interface identification and diagrams.
• 4.3. X Project-unique identifier of interface.
• Beginning with 4.3.2 identify an interface by project-unique identifier, briefly identify the interface entities, and divide into subparagraphs as needed to describe the interface characteristics of one or both of the interfacing entities. If a given interface entity is not covered by this SSDD (for example, an external system) but its interface characteristics need to be mentioned to describe interfacing entities that are, these characteristics shall be stated as assumptions or as "When [the entity not covered] does this, [the entity that is covered] will ....". This paragraph may reference other documents (such as data dictionaries, standards for protocols, and standards for user interfaces) in place of stating the information here. The design description shall include the following, as applicable, presented in any order suited to the information to be provided, and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size, frequency, or other characteristics of data elements):
  • Priority assigned to the interface by the interfacing entity(ies).
  • Type of interface (such as real-time data transfer, storage-and-retrieval of data, etc.)
  • Characteristics of individual data elements that the interfacing entity (ies) will provide, store, send, access, receive, etc., such as:
    1. Names/identifiers
       • Project-unique identifier;
       • Non-technical (natural-language) name;
       • Standard data element name
       • Technical name (e.g., variable or field name in code or database);
       • Abbreviation or synonymous names.
    2. Data type (alphanumeric, integer, etc.)
    3. Size and format (such as length and punctuation of a character string)
    4. Units of measurement (such as meters, grams, seconds)
    5. Range of enumeration of possible values (such as 0-99)
    6. Accuracy (how correct) and precision (number of significant digits)
    7. Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the data element may be updated and whether business rules apply
    8. Security and privacy constraints
    9. Sources (setting/sending entities) and recipients (using/receiving entities)
       
• 5. REQUIREMENTS TRACEABILITY

• The following shall be included in this section:
  • Traceability from each system component identified in this SSDD to the system requirements allocated to it.
    
• 6. NOTES

• This section contains information of a general or explanatory nature that may be helpful, but is not mandatory.
• 6.1 Intended use.
• This system/subsystem design description shall ...
  
• 6.2 Definitions used in this document.
• Insert here an alphabetic list of definitions and their source if different from the declared sources specified in the 'Documentation standard'.
  
• 6.3 Abbreviations used in this document.
• Insert here an alphabetic list of the abbreviations and acronyms if not identified in the declared sources specified in the 'Documentation Standard'.
  
• 6.4 Changes from previous issue.
• Will be "not applicable" for the initial issue.
  Revisions shall identify the method used to identify changes from the previous issue.
  

This page is under construction
Back to Home page MANAGING STANDARDS Home page
Please send any beneficial comments or identification of errors using the following form to: kenr@wysywig.airtime.co.uk