Project.

Team:
Team Members:
Date:
Project Title:
Team Leader:

Note: All diagrams should be clearly labeled. Remove all text that is shown in RED.

Scope

This section will define the scope of the project by defining and describing the System, the major functions of the application, and the database.

System Description

Describe your application – this can / should be a copy from the Requirements Document

Major Software Functions

List and describe the major functions to be performed by the software. You should use some type of a SYSTEM Diagram, number and name each of the functions on the diagram and then describe them using the numbers and names from the diagram.

Database Description

What type of DB will you use for the application?

Design Constraints and Limitations

Describe any and all design constraints and limitations

Design Description

This section will provide an overview of the application design by providing a description of the data to be used and managed by the application, define the flow of data through the system, describe the architecture of the programs within the application and define the how the components will interface.

Data Description

Provide a normalized ERD that contains all of the primary and alternate key. This is the final version of the ERD you created in the Requirements Specification and at this point it is now a SCHEMA. Then provide a description of each table in the ERD and list the fields and their characteristics

You should also provide a description of each relationship (it helps to understand the data dependencies.)

Data Flow

In this section you will define and describe how the processes interface with agents/actors and/or datastores. This can be done with either a Context Level DFD (SAD) or a Package Diagram (OOAD). You should also provide as much narrative as necessary to describe each component of the diagram. The goal is to provide the reader with an outline of the system you are designing. Each component will be defined in detail in section 3.0.

Program Architecture

This section is best completed with either a Physical DFD (SAD) or a Class Diagram (OOAD). The purpose is to define the physical architecture of the programs as they interface with each other. The diagram should include every module that will be part of the application.

Component Interfaces

Provide a screen navigation diagram and an Event chart/list. If it needs to be described by a narrative then you should provide that as well.

Detailed Design

This section will define and describe the design details for each of the components in the application.

(The intent of this section is to prepare for the build phase. These detailed design specifications will become a program in your system)

( For each component you have identified in your Program Architecture, you need to create a component section. That means you should copy 3.1 and all of the subsections (3.1.1-3.1.4) and paste at the end of the document until you have one section per module/program (3.2, 3.3, 3.4, etc.) Be sure you give each section the Actual Name of the Module so that it can be tied back to the Program Architecture Diagram! )Component/Module One (Change the name “Component/Module One to be the actual name of the module you are designing. Repeat section 3.1 for ea. component)

Processing Description

Provide a Primitive DFD (SAD) or a Use Case Diagram (OOAD) and a brief narrative

Interface Description

There are several items that should be covered here:

· If the component has a GUI, display the image of the GUI and define each field, button, link on the GUI.

· if the component receives data, describe the data coming in and where it should go once it is processed (Input/Output)

· If there is data to be passed to another component that should be listed

This section will have a detailed written description of what each button, link, data entry field etc., does on the page, with an image of the proposed page layout, for each page.

Pseudocode

The processing rules for the component – in logical order.  But remember, language independent. (link to a great example) http://www.wiley.com/college/busin/icmis/oakman/outline/chap05/slides/pseudo.htm

Put things here if it is needed to help explain the business rule functionality of the screen. For example if you need to check to make sure a customer has no outstanding balance past 60 days in order for them to generate another order identify what data values need to be used to do this and the math functions that need to be used.

If Customer Balance > 0 and Last Purchase Date < (current date – 60 days) then Deny Purchase Else Allow Purchase

You can break this down into functions or procedures if that is the best way to approach this for your project.

Modules Uses

If this component is a function that is called by other functions, such as a DB call to retrieve data, insert data, update data or delete data, or some type of standard calculation used by multiple modules, you will describe that here. If this section does not apply to the component, simply delete the section.

DeVry University

CIS470 - CIS Senior Project

Design Specification

Page 5 of 5

Document Work Log:

To assist in assessing the contributions made by the individual team members, the team must complete the table below:

Section	Team Member - Primary	Team Member - Secondary
1. Scope
1.1 System Description
1.2 Major Software Functions
1.3 Database Description
1.4 Design Constraints and Limitations
2. Design Description
2.1 Data Description
Schema
Table and Relationships – Data Dictionary
2.2 Data Flow
2.3 Program Architecture
2.4 Component Interfaces
3. Detailed Design Section - One section (3.1 – 3.x) for each individual component or module
Detailed Processing Description
Interface Description – with UI
Pseudo code, Flowcharts or Storyboards
Module Uses