The main purpose of the Functional Requirements is to explain what you are going to do for your project (as opposed to how you will accomplish these goals). The functional requirements, and an overall design (which will be your next assignment), describe the proposal to your client. When accepted, these documents are a contract between you and your client (me) about what you intend to deliver. Changes can be negotiated later and should be recorded as an appendix to this document (all of which must be turned in again at the end of the course.) When writing this document, therefore, you should keep in mind that your audience will be a client (who, in general, is not an expert in computer science) and your group members, who will want to refer back to this document periodically to be reminded of what they are supposed to be doing. Also, you could get new group members, and this document will be an excellent place for them to start.

You must write this document in HTML, and put the paper on one of your home pages. On Thursday, October 1^st, you must give the URL of your write-up to your partner group (to be assigned in class). They will have 48 hours to give you feedback about your write-up. Then, you will have five days to revise your document, and submit the final version on Thursday, October 8^th.

You must turn in your project in the following way:

• You must make a personal web page that has a link to your revised document, and then email the URL to the TA at mailto:sbw@cs.umd.edu with a subject line of "CMSC435 Functional Requirements".

If the final version is not turned in by Thursday, Oct 8^th, at class time (2pm), it will be considered late. On the course home page, we will make links to all of your documents so you can see what your fellow-students created.

This assignment, as well as all others throughout the year, should be turned in with a cover page that includes the following information:

• A title that identifies the document
• The name of your group (feel free to make up a name for your "company")
• The people who contributed to this document
• Course name, instructor's name, and date

In about 1-2 pages, you should briefly summarize the project you are working on. Give your system a name. Describe what it does and who will use it. What needs 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 for your system: time or space efficiency, security, or reliability?

The main point of this section (which should be approximately 5 pages) 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 and interactions 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 those cases. Part of this section will eventually be developed into a user manual. First we'll consider the content, then the form, of these descriptions.

The inputs, state changes, and outputs should be described in reasonable detail. You can negotiate major 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.

Your functional description should employ some of the following techniques.

• Sample interaction: A very important part of the description is a sample interaction with the system. You may sketch snapshots of what the pages and interface will look like. Be sure to give sequences that show a running dialogue. The main point of this section is to give your client a feel for what your system will look like.
• FSM Model: If your system can be thought of as being in a number of states, you can draw a finite state machine model (FSM). The different states might correspond to different prompts for user response that are shown in your dialogue.
• Boxes, arrows, and tables: As appropriate, use pictures of data flow or control flow diagrams, decision tables, etc. Be sure that any diagrams are captioned and that there is a key explaining what various boxes and arrows mean.
• 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.

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?

Predicting how much can really be accomplished in a finite period of time is often tricky. It is important to describe a range of functionality. You should describe the

What would a bare bones version of your system involve. Describe, in one or two pages, the composite of your skeletal system. What functions will not 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.

Now 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. You might want to think about this in terms of:

• A kernel system with absolutely minimal features that you are positive you can finish in 1/2 of a semester.
• A cheap but usable system that you expect to finish.
• A standard system that you have a change of finishing.
• A super system that you probably won't be able to finish but would like to.

Don't drop the reader off a cliff at the end of your document. It has been a long time since the beginning of the paper. Restate the main points you want remembered.

Write down the authors of individual sections, the editor of the whole paper, outside consultants, etc. (Do this for all future papers as well.) This will help your client figure out who to ask for more details.

A real functional specification would include a number of items that you may wish to skip at this point. Some of them require more experience to predict and some may not be relevant to your projects.

• Make some general statements about the performance goals for your system. What are your goals for system run time, main and disk memory use? What kind of reliability will you guarantee? Security of information? What kind of performance tradeoffs have you decided to make?
• Can you say anything about compatibility with existing software or hardware? What about an installation agreement? Maintenance contract?
• What resources are to be committed to the project? Who are the people on the project? Their skills and background? What is the promised delivery date?
• How much computer time and space will be used to develop the project? What publications will be produced? Who are the intended users?