Processes and Tools for Planning a Program- 7

System Design Document (SDD) - The SDD is intended to capture an overview of the system design. It should be generated in parallel with the system design work and serve as a concise data source for new personnel coming on to a project at any time during the life cycle and as a reference document for future designs. The SDD should include a summary of top level requirements, but is not the source of requirements information, and it should include the project information architecture.

The SDD captures all system level design diagrams, provides a description of each mode, defines the operational scenarios, includes key use cases, includes a complete functional description to at least the second level and includes a complete description of the physical architecture.

If the enterprise has a mature information system that is designed to archive design data such that links are preserved then the SDD can include links to more detailed design analysis and design documentation; if not then it probably isn’t worthwhile to include such links.

The SDD is not defined as part of the integrated design data packages by the DoD, NASA or IEEE handbooks. However, think of the SDD as the introduction and summary section of the total data package. Just as a good technical report or proposal needs an introduction and summary an integrated design data package needs a SDD to orient users, especially on their first visits to the data package and before they begin contributing to the product design effort. The SDD is also the primary reference for future development of similar products. Trying to wade through the design data of a prior product development without having a SDD to introduce and summarize the design is a formidable task that is avoided if a SDD is available as a roadmap to the design.

Information Architecture - Design of a modern complex system results in generating a large number of specifications, documents, drawings, plans etc. A drawing tree, or a specification tree and drawing tree, may have sufficed to describe the relationships and traceability of design documentation for simple products of the past but these simple trees are no longer sufficient.  It is critical to develop and maintain a data management system as part of an overall configuration management process so that data integrity is maintained and any desired data is easily retrievable. Part of planning a program is defining how this data base is to be configured for the system or product being developed. Unfortunately there seems to be no agreement on what name to give to the complex data base needed today. In this work the term Data Management Repository (DMR) is used for the data base that includes all the documentation associated with the product development. How this DMR database is structured and how traceability is defined is called the information architecture. A key element of the information architecture is the document tree, which is an expansion of the traditional specification tree that includes specifications, plans and key technical reports.

If a modern object oriented data management tool like Telelogic’s Dynamic Object Oriented Requirements System (DOORS^TM), or an equivalent tool is used the document tree can be a template for defining the database. For example, if DOORS^TM is used each box on the Document Tree represents a formal module (data set) in the DOORS^TM database.  Arrows between the boxes identify important relationships (DOORS^TM links) between DOORS^TM formal objects.  These links represent the requirements and decision traceability when complete and they facilitate change management and impact assessment. A Link Module is created in DOORS^TM for each different relationship type captured in the Document Tree. These link modules can include requirements, verification, decision and change with each having a different color on the tree diagram to make traceability easy. An example of a simple document tree for a hypothetical system called AB is shown in Figure 4-5 with only requirements links and verification links shown.

Figure 4-5 A simplified document tree for a hypothetical system called AB showing requirements links and verification links.

The SEMP outline given in a previous posting includes a specification tree and a list of other documents. It is recommended that these two items be replaced by the document tree.