Requirements for the Final Project Proposal

CS 433, Fall 1999

 

Note: The final project proposal is due 9/29 in class. This proposal counts for 15% of your overall grade.

The final project proposal should contain two main parts: an overview of the project and a detailed description of the concrete functionality. There are no length requirements, but we estimate that the document will be between seven and ten pages.

    In this part, give a general description of the project. Describe the problem that your system solves or the service it provides and detail the usage of the system that you propose to build. If there are different types of users, describe the users and the (possibly different) services to the individual user groups.

    In this part you should describe the functionality of the your system. Describe all web pages that will be presented to users in detail. Give a complete description of the functionality of each page (e.g., is the database accessed/queried/updated, which user group sees this page, what other features are on the page). You do not have to describe how you are going to achieve this functionality, but your description should be precise enough so that another group could potentially use your document and implement the functionality in some way. You should be concerned with the following three different views of your system: 

1) Processes and the workflow. Describe the processes in your system. Depict (either verbally or in a picture) the possible interactions with your system. Give "what-if" descriptions: If on page X the user does Y, then Z happens. Try to describe the processes first at a higher level, and then break the processes down into individual steps. 

2) Data. Describe the data involved in the processes. You don't need to go to such a low level where you describe the actual database tables and the SQL queries, but present at a high level what is happening to the database, what state information is kept during a session with a user (if there is any), whether there is temporary data somewhere etc.

3) User groups. Your system might offer different interfaces to different types of users (e.g., administrators, normal users etc) who have different rights and privileges. Explain the functionality of the project by user groups. For each user group describe the data they can access/manipulate.

As a general recommendation: If you are in doubt whether a detail is worth putting into the report, put it in. It is always better to be more precise at an early stage than to find out about problems later on.