Due date: October 21 at noon in 4105 Upson Hall. The design document counts for 20% of your overall grade.
Most groups were missing the following information in their design document drafts:
Information about the high-level information flow. This could be flow charts of any kind (text or graphical)
The SQL Queries that are issued at individual pages.
How is temporary state maintained, and where it is used.
How is authentication set up and maintained
The design document should be an extension of your project proposal. (Concretely: Take your project proposal and extend it according to the requirements stated here.) The main difference is that you have to give a detailed description of how you will implement the functionality you proposed.
The final design document should contain three main parts: an overview of the project, a description of the database, and a detailed description of how each component of your system is implemented. There are no length requirements, but we estimate that the document will be at least 12 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 section, you have to describe the underlying database that your system will operate on. First, show an ER-diagram of the database. Then map the ER-diagram to relational tables (including all domain constraints, key, foreign key, and other constraints that you want to enforce). One possibility to describe the tables is CREATE TABLE statements in SQL. For each table, give a short description of its purpose and usage in the system. Somebody who does not know anything about your project should be able to take this part of your design document and implement the database schema that you need.
In this part you should describe in detail the functionality of your system and how this functionality is implemented with the technologies that are provided. Describe all web pages that will be presented to users in detail. Give a complete description of the functionality and implementation of each page:
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, then talk about the implementation.
2) Data. Describe the data involved in the processes. You need to describe the actual SQL queries, but present at a low level what is happening to the database, what state information is kept during a session with a user (if there is any) and how this state information is implemented, and whether and how there is temporary data maintained.
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. At this point you will already have described the implementation in detail, so don't repeat it.
As a general recommendation: If you are in doubt whether a detail is worth putting into the report, put it in.