System Design Specification

http://www.cs.armstrong.edu/sjodis/COURSES/3321/design-guide.html

The System Design Specification (SDS) is a complete document that contains all of the information needed to develop the system. Unlike the SRS, the targetaudiences of this document are the implementation and testing teams, so the SDS should be written at a more technical level.

 

Thisdocument does not attempt to restrict a team to a specific format for producingthe documentation. It merely sets up guidelines showing what is required. Withineach section of each document, students are encouraged to use their pastexperience and organizational abilities to come up with the best method ofdescribing their particular system.

 

Themajor sections of the SDS should be:

 

1.Introduction

 

2.Project Scope

 

3.System Design

 

4.Component and Process Design

 

5.Data Design

 

6.User Displays and Output Reports

 

7.System Files

 

8.Prototype Description

 

9.Prototype Test Procedures

 

10.Prototype Analysis

 

11.System Development and Project Management Schedules

 

12.Special Notes

 

13.Project Extensions

 

14.Appendices

 

Thesections should be numbered as shown above, and the appendices should beassigned capitol letters. The design team may further organize their documentby adding subsections under these major sections where appropriate for theirparticular system. Each section of the SDS will be fully described in thefollowing subsections.

 

 

 

 

 

 

 

 

 

1.Introduction:

 

Theintroduction should be written during the architectural design phase of thecourse. It should provide an overview of the system, including a briefdescription of each of the major functions or operations to be provided by thesystem. There should also be a brief summary of the output capabilities, usercompatibility, and projected cost savings features of the system. The finalparagraph of the introduction should generally describe the rest of thedocument and all its appendices. Teams are encouraged to reuse sections ofprevious documents as needed.

 

 

 

 

2.Project Scope

 

Theproject scope should be written during the architectural design phase. Itshould restate the system objectives and project constraints from the SRS. Alsoinclude in this section a discussion of any other limitations that thedevelopers of the system may need to know in order to perform their duties.This should include a general description of the hardware and softwareinterfaces of the system and the tools and equipment needed to develop thesystem.

 

Afterthe system design has been completed, this section should be enhanced with adiscussion of the degree of fulfillment of the system objectives. Since theseobjectives have been written so that they are measurable, the degree offulfillment should be evaluated as specifically as possible without a fullimplementation of the design.

 

3.Design Description

 

Thissection contains the final, verified versions of the graphical representationsof the architectural design. These diagrams should be derived from the systemdiagram developed in the System Description Section (SRS). Also includearchitectural charts and diagrams, such as structure charts, which have beenderived from the graphical system diagrams. Show all the hardware components tobe integrated and software processes to be developed, as well

astheir invocation hierarchy. The architectural charts should be arranged inhierarchical order, and each chart should have a legend to enhance thedescription.

 

4.Component and Process Design:

 

Thissection should contain a brief narrative which describes the function of eachhardware component and software process shown on the structure charts. Theformat for this section should be adapted from that of the process descriptionof the SRS. Upon completion of the architectural design phase, there should bea description for each component identified in the previous section.

 

Duringthe detailed design this section should be enhanced with a graphicalrepresentation of each entity's logic ( ie, hardware block diagram,pseudo-code, etc.) These diagrams should be at a level of detail sufficient tofacilitate implementation. Each graphical representation should have a legendcontaining:

 

 

a)The name of the person responsible for its creation

 

b)The date of creation

 

c)The name of the last person to revise the diagram

 

d)The date of that revision

 

e)The nature of that revision

 

Ingeneral, integration and development should not require that the specifiedcontrol constructs be modified substantially.

 

5.Data Design

 

Thissection should consist of the final, verified version of the system datadictionary. This dictionary should be derived from that developed in the DataFlow Description Section of the SRS. It should be adapted during thearchitectural design phase and substantially enhanced during the detaileddesign. If any complex data structures are required (e.g. tables, linked lists,trees, etc.), include diagrams showing the logical composition of the datastructures.

 

6.User Displays and Output Reports

 

Thissection should be completed during the architectural design phase. It willcontain descriptions of all the input and output displays and reports availablein the system. These descriptions should be arranged in the order in which theuser might access the displays and reports. This section may read much like auser guide to the system.

 

Eachof the displays and reports of the system should be drawn on a separate pageand surrounded with a box to show exactly how they will look in the finalsystem. Each menu of the system should be accompanied by a narrative page whichdescribes the menu, its usage within the software system, and each option ofthe menu. Each data entry made should be accompanied by a description of typesof information required in each of the entry fields, the order in which thefields must be filled in (if any), an indication of which fields must be filledin and which are optional, and a description of how to move back and forthamong

entryfields (so that errors may be corrected), and how to exit the menu. Describe ina similar manner the format of any other items that must be specifiedinteractively by the user of the system.

 

Foreach of the output reports produced by the system, include an example reportalong with a narrative page that contains the following information:

 

a)the purpose of the output

 

b)the availability of the output

 

c)a brief description of the output's content

 

d)any logical ordering to be imposed on the output

 

e)a list of the items in the output, along with any formula's which are

usedto calculate them

 

7.System Files

 

Thesystem files section should be completed during the architectural design. Inthis context, a file may be a software logical file or hardware physical file.Each file used by the system should be documented with the followinginformation. First, include a narrative which explains what type of informationis stored in the file. This narrative should tell how the file is accessed(i.e., SAM, ISAM, VSAM, direct-linked, random access, etc.), list any pointerfiles which reference the file, and show a structure diagram if the records inthe file are linked in any way. A file layout form should be created for eachfile sowing the following information for each field in the file's records:

 

a)the fields position within the record (1st field, 2nd field, etc)

 

b)the starting position of the field within the record (in bits or bytes)

 

c)the field size (in bits or bytes)

 

d)the fields type (alphanumeric, numeric, hexadecimal, alphabetic,

signedbinary, binary, etc.)

 

e)a brief description of the field

 

f)the source of the information kept in this field, (user input,

programcalculation, etc.).

 

 

Atthe beginning of each file layout form, include the logical name of the file,the record length, and the actual name by which the file will be referenced.

 

Onceall of the files have been described, show a file-entity cross-reference whichshows how the processes, components, and files interact. The cross-referenceshould show which processes or components create which files, and which filesprovide input, output, or both for which entities.

 

8.Prototype Description

 

Thissection will define the prototype that the team will implement and test duringthe second quarter of the course. It should be completed during thearchitectural design phase of the project. The prototype chosen shouldillustrate a concept, verify a critical design decision or measure the degreeof accomplishment of key objectives. Estimated to be developed by the team inabout five weeks, it should be completely described so that there is nomisunderstanding between the team and the course administration as to the sizeand scope of the prototype.

 

9.Prototype Test Procedures

 

Thissection should develop guidelines for completely testing the prototypediscussed above. Functional tests, i.e. tests which verify that implementedprocesses are consistent with their original specifications, should beincluded. These tests should specify inputs and expected outputs. Softwaretests should, as a minimum standard, achieve branch coverage of the designrepresentation while testing boundary conditions, special values, defaultinitial values, and logically related inputs. After the prototype has beenimplemented, each test should be updated with the actual results of running thetest.

 

Sincethe tests described above will not sufficiently test the full implementation ofthe system, describe any additional testing procedures to be performed on thefull implementation, including the persons (positions)who will be responsiblefor the design and execution of these additional test cases.

 

10.Prototype Analysis

 

Theprototype was chosen to illustrate a concept, verify a critical design decisionor measure the degree of accomplishment of key objectives. After the prototypehas been implemented and tested, the team should discuss what has been learnedfrom the implementation in this section. Some teams may find that designdecisions should have been made differently, or may need to reconsider someobjectives of their system. In writing this section, teams should realize thattheir project design has already been graded. Criticisms of the design will notcause a team's grade to be reduced. Rather warranted criticisms will show thatthe team chose a relevant prototype and performed a proper analysis of theirsystem. This analysis would be very helpful if the system was to be

fullyimplemented, so properly discussed criticisms would improve the team's grade.Further, an absence of such criticism will indicate that the prototype processwas not meaningful.

 

11.System Development Schedules

 

Thissection will be set up during the architectural design phase and updated duringthe detailed design, and prototype testing phases. It should contain a revisedproject schedule (adapted from the schedules in the SRS) which show:

 

 

a)the detailed activities planned for the next phase of the project

 

b)the proposed activities for the remaining future phases of the project

 

Indicateany deadlines to be met, and the due dates for each of the expecteddeliverables. Once again, while preparing these schedules keep in mind theindividual schedules.

 

12.Special Notes:

 

Thissection will be completed during the prototype testing phase. The contents ofthis section will be highly project dependent. Some systems will require adiscussion of production and packaging considerations, resources needed andcosts associated with production, marketing strategies, price per unit of thefinal system, number of unit sales required to break even, and number of unitsales projected.

 

Somesystems may require complicated installation procedures. Designers of thesesystems should include complete installation instructions and tests required toensure proper installation.

 

Thissection may also be used to pass hints and notes to the implementation andtesting teams.

 

 

 

 

 

 

13.Project Extensions

 

Almostany project could be extended and improved with more time and money. Thissection, to be completed during the prototype testing phases, shouldspecifically describe those improvements and extensions for th projectdescribed above. For each extension, generally estimate the projected costs andbenefits associated with its design, implementation, and integration (includingtesting) within the current system. Specifically describe the extension'scompatibility with the current design. Order the extensions by increasing estimatedcosts/benefits ratios. The final paragraphs in this section may contain a verygeneral discussion of future interests associated with the project.

 

14.Appendices

 

Includein appendices any other materials which are required to give your specificproject a more complete description. There should be appendices containinglists of the prototype code, the names, addresses, and telephone numbers of thepeople to contact regarding the design specification, and all reference andbackground materials used during the design. Appendices may also be used todisplay tabular data, excerpts from other documents, approved changes from theSRS and any other information that may be useful in the future.