The purpose of this document is to provide you with a guideline for writing the software design document for your project


Download 43.9 Kb.
NameThe purpose of this document is to provide you with a guideline for writing the software design document for your project
A typeDocumentation
manual-guide.com > manual > Documentation

<Project Name> Design Document v.





Design Document

Authors:









Group: 0

The purpose of this document is to provide you with a guideline for writing the software design document for your project.
Points to remember:

  • Content is important, not the volume. Another team should be able to develop this system from only this document.

  • Pay attention to details.

  • Completeness and consistency will be rewarded.

  • Readability is important.


This page intentionally left blank.

Document Revision History


Date

Version

Description

Author

10/25/2012

0.0

Initial draft




10/25/2012

0.1



John Q. Doe


This page intentionally left blank.

Contents

1 Introduction 7

1.1 Purpose 7

1.2 System Overview 7

1.3 Design Objectives 7

1.4 References 7

1.5 Definitions, Acronyms, and Abbreviations 7

2 Design Overview 8

2.1 Introduction 8

2.2 Environment Overview 8

2.3 System Architecture 8

2.3.1 Top-level system structure of Fuel level controller 8

2.3.2 Level Monitoring Sub-system 8

2.3.3 Fuel Subsystem 9

2.4 Constraints and Assumptions 9

3 Interfaces and Data Stores 10

3.1 System Interfaces 10

3.1.1 Pressure Sensor Interface 10

3.1.2 Pump Valve Controller Interface 10

3.2 Data Stores 10

4 Structural Design 10

4.1 Design Explanation and Rationale 10

4.2 Class Diagram 11

4.3 Class Descriptions 11

4.4 Classes in the Fuel Subsystem 11

4.4.1 Class: Tank 11

5 Dynamic Model 12

5.1 Scenarios 12

6 Supplementary Documentation 13


1Introduction


This section addresses the purpose of this document including the intended audience, an introduction to the problem and a detailed view of the project's design. In the discussion, the design of the final system including several detailed diagrams will be described in detail.

1.1Purpose


Provide a brief introduction to the document. What is the purpose of the document? What is its layout?

1.2System Overview


Provide a brief description of the purpose of the system, its target users and the environment in which the system will be used. This is basically from the initial part of the requirements document with revisions if any.

1.3Design Objectives


In this section discuss the overall system design goals. Broadly mention what functionality the design attempts to cover and what it doesn’t. Also, refer to non-functional requirements like performance and usability that the design addresses. The requirements specification document could be useful in writing this section. Take a look at the functional and non-functional requirements definitions in your requirements specification.

This section should provide the overall scope and context for the design. After reading this section the reader should be able to understand what features and functions are being addressed. In the later sections, you will be explaining how this is achieved in your design.

1.4References


Provide references to other documents.

Hint: You must at least refer to the requirements document!

1.5Definitions, Acronyms, and Abbreviations


Definition of various terms, acronyms, or abbreviations used in the document.

Note: If your TAs ask, “what do you mean by this…?”, may be you should consider adding a brief definition here.

If some of the terms have been defined in the requirements document already, you may just refer the reader to the glossary of the requirements document.

2Design Overview

2.1Introduction


This section should highlight the design approach that you adopt (e.g. object-oriented design or structured design), the proposed architecture of the system (e.g. client-server) and the relevant techniques and tools used (e.g., Microsoft Visio, Dia, ArgoUML, etc.).

2.2Environment Overview


This section should describe the environment in which the system will be run. This should include diagrams and descriptions of the environment. For example, if we are describing a web app, this will include a network diagram or topology. If we are developing a library, we should describe what might be calling us. In order to do this effectively, you should have previously stated your system’s scope.

Be sure to address where this application will reside and how it will be executed.

2.3System Architecture


Provide a high-level description of the system architecture. Use a few block diagrams to show the major components and their interaction. Remember to describe the conventions and notations used in your diagrams.

The following is provided as an example:

2.3.1Top-level system structure of Fuel level controller




The system consists of two major components, a level monitoring subsystem and a fuel subsystem. The interaction between the systems is bi-directional. Current sensor measurements are sent to the level monitoring subsystem from the fuel subsystem and instructions to various actuators are sent back based on the current fuel level.

2.3.2Level Monitoring Sub-system





The Level Monitoring Subsystem consists of the Operator interface and the Controller. The operator interface in turn consists of Alarms and Switches.

2.3.3Fuel Subsystem


Another diagram and some explanation…

2.4Constraints and Assumptions


Mention the major design constraints here. These may have been imposed by the customer, which can be found in the requirements document. Explain how your design accommodates these constraints.

There may also be constraints imposed because of your system interacting with other external systems or being dependent on some external systems to provide part of the functionality. In such cases clearly mention the type of software your system interacts with (e.g. XYZ database software, ABC email software) and the constraints this imposes (e.g. only text based email messages are allowed).

Implementation languages and platforms may impose certain constraints. Mention them here, including the languages or technologies you will use in your implementation.

For constraints imposed by your design choices, briefly mention the options that you had, the tradeoffs involved and the reason why you made the choice.

  1. Response from the controller to changes in the fuel level should reach the controller within 100 milliseconds.

This is addressed by a combination of the priority scheme and the underlying executive software that operates the controller. Events are scheduled to be handled by the executive by priority. The executive runs every 25 milliseconds and schedules the event-handler for the highest priority event pending in the event-queue. All event-handlers execute within the 25-millisecond time limit.

  1. Another constraint…

An example of a design choice imposing a constraint:

Choice of email software restricts messages to plain text.

We had the option of choosing an easy to use software that provides the basic functionality or a full-featured messaging system. The former option meant that we could use only text based messages whereas the latter option meant a lot of overhead in installing and supporting the software. Since our application required predominantly text-based messages, we chose the first option. In future binary data could be sent over the text-based system using some coding scheme.

3Interfaces and Data Stores


This section describes the interfaces into and out of the system as well as the data stores you will be including in your system.

3.1System Interfaces


The various interfaces provided to users and/or other external systems should be defined here. If you had included user interface descriptions in your requirements document you may refer to them here. If you provide interfaces to other systems, say export and import data to a different software, you should mention them here.

Do not include JavaDocs here. You should describe the interfaces using prose and graphics if your interface includes a GUI.

The following is provided as an example:

3.1.1Pressure Sensor Interface


This interface is used to measure the liquid pressure at the bottom of the tank from which the fuel level is computed. The sensor measures pressure in pounds per square inch (psi). A hardware interface is provided to access the sensor reading from the Controller software. The data can be accessed by the software at a fixed memory location (using memory mapped I/O).

3.1.2Pump Valve Controller Interface


Description goes here…

3.2Data Stores


Describe the internal databases/data stores you will create AS PART OF YOUR SYSTEM – any data permanently stored on the hard drive. This should NOT include databases or other data stores that are external to your system. This information should be included in a previous section.

4Structural Design

4.1Design Explanation and Rationale




A written explanation of the design you chose, explaining how your system is structured, how requests are handled, and how communication and control flow through your system.
This section should also include design justification, including specific rationale for the decisions made in the design (for example, why your design may be better than another or why you chose to implement a specific design pattern in one of your subsystems).

4.2Class Diagram


Provide the class diagram for the system. If the class diagram is too big, partition the diagram using some reasonable criteria. For example, you may provide the client-side and the server-side object models as separate diagrams.

What should go into a class diagram?

All the classes should find a place here. All associations between classes should be identified and associations should be decorated with the right cardinality. Aggregation and inheritance relationships should be identified. A brief explanation should accompany each diagram including your justification for your design. Make sure you include figure numbers to help you reference figures in the document.

Remember: You may have to iterate several times before you agree on the right class diagram for your system.

4.3Class Descriptions


In this section you would describe in detail each class, its attributes, and its methods. You should logically group classes together. For example, you may use your architecture diagrams to group classes within a sub-system together.

Provide a subsection for each class. For each class, briefly describe its purpose, any constraints, (e.g., only single instance) and list the attributes and the methods of each class in the class diagram.

For each class, describe each of its attributes with the following details: name, type, a one line description of the attribute if its meaning is not intuitive, and constraints on the attribute (e.g., attribute must have unique value for each object or value range is restricted to positive integers).

Each method should be described with the following details: method name, return type and value, parameters, purpose and a brief description of the algorithm used (if it is non-trivial). Pre-conditions and post-conditions should be mentioned here if there are any assumptions about the arguments or the return values. List the attributes read and modified by this method and other methods invoked by this method.

The following is provided as an example:

4.4Classes in the Fuel Subsystem

4.4.1Class: Tank


  • Purpose: To model the relevant aspects of the physical tank that stores fuel

  • Constraints: None

  • Persistent: No (created at system initialization from other available data)

4.4.1.1Attribute Descriptions


  1. Attribute: fuel-level

Type: real (double precision)

Description: Stores the current fuel level in the tank

Constraints: should be a value between 0 and max-level


  1. Attribute: max-level

Type: real (double precision)

Description: maximum level of fuel that the tank can hold

Constraints: non-negative


  1. Another attribute …

4.4.1.2Method Descriptions


  1. Method: AdjustLevel(double pressure)

Return Type: boolean

Parameters: pressure – the current pressure reading for the tank

Return value: success or failure

Pre-condition: fuel-level between 0 and max-level

Post-condition: fuel-level between 0 and max-level

Attributes read/used: fuel, pump, alarm, fuel-level

Methods called: fuel.get_density(), alarm.sound_alarm()
Processing logic:

The fuel density is obtained from the fuel attribute of the tank. New fuel-level is computed from density and pressure. If level falls outside the range [low-level, high-level) the alarm associated with the tank is sounded and the pump is stopped.
Test case 1: Call AdjustLEvel with pressure X and fuel-level Y. Expected output is:….


5Dynamic Model


The purpose of this section is to model how the system responds to various events, i.e., model the system’s behavior. We do this using UML sequence diagrams.

The first step is to identify different scenarios (e.g. Fuel Level Overshoots), making sure you address each use case in your requirements document. Do not invent scenarios, rather a general guideline is to include scenarios that would make sense to the customer. For example, for the course enrollment system, logging in is a valid scenario.

5.1Scenarios


For each scenario you will have a subsection with the following information:

  • Scenario Name: Provide some meaningful name for the scenario (it is a good idea to include this in the subsection name.

  • Scenario Description: A brief description of what the scenario is about and the sequence of actions that take place

  • Sequence Diagram: A sequence diagram showing various events and their relative time ordering (as discussed in class).


6Supplementary Documentation


Provide any other relevant documentation that may help understanding the design.


CSci 5801: Software Engineering I of

Share in:

Related:

The purpose of this document is to provide you with a guideline for writing the software design document for your project icon1introduction 1Purpose and Scope This section provides a brief description...

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconNote: This document spans many years of experience in Computer Software...

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconU. S. Government Printing Office Federal Digital System System Design...

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconTo show a document map or index for this document click on “view”...

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconPurpose of this document

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconIntroduction Purpose of the document

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconSection 0 Purpose of Document

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconA web and Android mobile app project. The document will outline the...

The purpose of this document is to provide you with a guideline for writing the software design document for your project icon1. 1Document overview This document contains the software development...

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconDocument title: Project Plan Project name

The purpose of this document is to provide you with a guideline for writing the software design document for your project icon1Introduction 1Backup and Recovery Document Purpose

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconThis document is to be used as a reference. I will attempt to keep...

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconAbstract: [Supply your own summary of the technical purpose of the document.]

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconAbstract: [Supply your own summary of the technical purpose of the document.]

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconTechnical Design Document Template doc

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconThe information contained in this document is confidential and is...

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconThis manual has been prepared to assist you in the operation and...

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconThis Microsoft Word document was converted from an original Adobe Acrobat pdf document

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconListed document this document shall not be revised without approval...

The purpose of this document is to provide you with a guideline for writing the software design document for your project iconThis document is provided "as-is". Information and views expressed...




manual


When copying material provide a link © 2017
contacts
manual-guide.com
search