Outline of the Functional Specifications Document

This document integrates what you have learned from your user so far. It freezes what must be delivered in the product and separates it from what may be delivered or left for the next release. The document will include the following sections:

1. Title page, table of contents

2. Team members and what role and contribution each has made to the team's effort.

3. Description of the product's end user, focusing in on the need which this product will meet.

[Although you may identify and describe the specific user who motivates the project, neither project should be viewed as uniquely customized (in-house), but should be abstracted to a generic user of the type your user represents (any appraiser, any drug screening lab).]

4. A data flow diagram of the system of activities in which your user is engaged, which includes all of the entities which provide or consume data or reports which your product will process. On this diagram will be drawn the automation boundary, the the circle which encloses the functions which your product will perform. This boundary could be extended to include some adjacent manual process, or retracted to require that some process be done manually instead of by the computer. At the boundary where data input occurs, you need to indicate what processing, if any (what decisions) the data entry person must perform with the data to convert if from the format it has IRL (usually a form) in order to enter it into the computer.

5. An architectural diagram of the product in which its internal componets and their interactions are shown.

6. A representation of the user interface which will show the menu tree of the GUI abstractly, listing the functions which can be performed on each screen (the screen layout is arbitrary or inconsequential. If your menus are all pulldown or activated from the tool bar, the main menu is the root and each button starts a branch of the tree).

7. A list of the logical or user functions (each named) accessible from the GUI, one or two per page, indicating the preconditions, the need information on hand (that the user is thinking about and using while performing the function), the sub-functions, if any, which must be performed by the program as the user enters the steps of the process [the menu tree should permit the user to select the processing which is to be done, the function, from the user's point of view should be a whole module (perhaps one of a short sequence of modules, each with clear boundaries), but from the program's viewpoint, several distinct processing activities might be triggered by the module], WHAT (not how) it accomplishes, what the post condition is (how has the state of the program/data base changed as a consequence of the execution of this function), and what does the user see when the function processing is complete (there may be different ways in which the function terminates, depending on error conditions or user intervention). [In the design document you will break these user functions down into named program modules.]

8. A description of the reports which will be generated by the program (any printed output).

9. A list and description of the non functional requirements which the program will satisfy, including size and speed capacities, security, and backup provisions.

10. A Summary of how the requirements have been clarified during your feasibility study, including especially an explanation as to how the product description has changed over the first two months as represented by previous hand-ins. This Summary will also highlite any continuing areas of ambiguity and possible trouble spots in the current specifications. Finally, it will list program functions which are not presently planned for the intial product, but which might be desirable.

11. A glossary of terms (user and computer) which might be unfamiliar to a user or a programmer working on this product.

12. Appendix will contain a statement from the user indicating that he has certified the completeness of the product as represented by the prototype. (Your previous definition document will be added to the Appendix also, so you might wish to augment or improve the materials you submitted earlier).

13. This list is minimal. You may wish to include additional sections or expand upon the material in any section described above. Do not be concerned with desgin details, however (answers to HOW processing will be done internally).