CONTENTS OF A FUNCTIONAL SPECIFICATION

I.                   TITLE PAGE

The functional specifications should be turned in with a title page that includes the following information:

A.     A title that identifies the document.

B.     The name of your group.

C.     The people who contributed to this document.

D.     Course name, Instructor's name, and date.

II.                 FUNCTIONAL SUMMARY

In about 2 pages, briefly summarize the project you are working on. Give your system a name. Describe what it does and who will use it. What requirements will your system satisfy? How will it help the users? Outline the most important features of your system. Describe the physical environment in which your system will be used, including any other systems with which the new system will interface. Are there any important performance goals of your system: time or space efficiency, security, or reliability?

III.              DETAILS CONCERNING SYSTEM/ USER INTERACTIONS

The main point of this section is to describe the functions that the system will perform from the point of view of the system user. You need to cover the kinds of inputs your system expects, the actions it will take on both expected and unexpected inputs, and the types of outputs that the user will see in these cases. Part of this section could eventually be developed into a user manual.

A.     The inputs, processing, and outputs should be described in reasonable detail. You need not stick to the exact wording of messages, but you should make definite statements. You can make changes later. Describe what legal values or ranges your system will accept for inputs, what precision or accuracy constraints you will follow, and how you will handle errors.

1.Will your inputs be mostly commands entered interactively? If so, give examples.

2.Will the input be menu driven? If so, give examples.

3.What functions or transformations does the system perform from the user's point of view?

4.Will the outputs be short messages to the display? If so, give examples. Probable error messages should be noted.

5.Will reports be generated? If so, give examples.

6.What kind of help facilities will you provide for system users?

B.     Your functional description should employ some of the following techniques:

1.Sample transcript. A very important part of the description is a sample interaction with the system in the form of a transcript of a dialogue between a user and the system. Use some convention to distinguish between what the program types and what the user types. You will give a demonstration of your system later in the semester, and your goal in that demonstration should be an elaboration of the dialogue described here.

2.A description of the syntax of any commands that must be specified by the user.

3.Diagrams or tables. Be sure that any diagrams are captioned and that there is a key explaining what various boxes and arrows mean.

4.Glossaries. Be sure that all specialized terms are defined in the body of the document or in a collection at the end. This could include computer science terms that you wouldn't expect your client to know or application terms that programmers working on the project might not understand.

IV.             FEASIBILITY

Make sure your project has a chance of being completed in a semester. What are your preliminary thoughts on how you will break down the different features of the project? What are the major classes of functions and the relationships between them? For example, are there fairly separable components such as an editor, move checker, function simulators, database access functions? Think a little about your main data structures and algorithms, and spend a page or so discussing possible implementations. Don't waste time fighting over details.

V.               OUR SYSTEM, PLAIN AND FANCY

Predicting how much can really be accomplished in a finite period is difficult. It is important to decide what a bare bones version of your system would involve. Describe, in one or two pages, the composition of your skeletal system. What functions will be included, and why? Cover yourself by making sure that reading between the lines doesn't make your customer think that more is being promised than you plan to deliver. Sketch out which features will be added as time permits. Try to organize the bells and whistles into packages that could be added independently or in some predictable order. Also think about the order in which parts of the system can be dropped so that you can retreat gracefully if necessary.

More specifically describe:

A.     A kernel system with absolutely minimal features (that you are positive you can finish in 3/4 of a semester).

B.     A cheap but usable system (that you expect to finish)

C.     A standard system (that you have a good chance of finishing)

D.     A super system (that you probably won't be able to finish but would like to; don't make this something impossible).

VI.             SUMMARY

Restate the main points you want remembered.

VII.          ACKNOWLEDGEMENTS

Specify the authors of individual sections, the editor of the whole paper, outside consultants, etc.

VIII.        OPTIONAL SECTIONS

Include the following information as necessary and relevant to describe your project Make some general statements about the performance goals of your system. What are your goals for system run time, main and disk memory use? What kind of reliability will you guarantee? What kind of security can you guarantee? What kind of performance trade-offs have you decided to make?

IX.             DUE DATE AND COMMENTS ON THE ASSIGNMENT

A.     The functional specifications are due 2000/??/??.

B.     Appoint one of your group members as editor for the document. This person should not have to write the entire document, but should combine the sections and check for consistency and language usage. Someone else should be editor on the next document.

C.     Keep a log of the time you spend on the project

D.     Make a copy of the document for each team member of well as a copy to turn in.

E.     Provide an index and number the pages.