Section 1 ("Overview") should provide a general overview of what your project is, what it hopes to accomplish and the like. Section 2 ("Requirements and Target Audiences") should provide a few sentences describing the problem that your system will solve. More specifically, you should describe in detail the intended users of your system, how your system will benefit them, and contrast with existing solutions. Section 3 ("Functionality") should give some typical use case scenarios. If you work through some scenarios carefully, the rest of the system will be a lot easier -- this should be done before you worry about implementation details. Joel Spolsky's articles on specifications are worth reading for a general guide.

Section 4 ("Design") should describe your major components. Each piece should have outlined what it does, how it connects and interacts with the other pieces, and their most likely implementation(s). At the very least you must cover your three "tiers". The business logic and/or middleware is likely "where the magic happens" with your specific project, so you will want to spell it out carefully. In this section you should pay specific attention to interfaces between components -- interfaces insulate each part of the system from details of the other parts, allowing modularity of both design and implementation. With proper interface design, you should be able to make significant changes to the details of your interface or database without changing the core code much, if at all.

Section 5 ("Timeline") should list significant milestones that you plan to achieve every week or so. Milestones should be a concrete task or feature that is 100% done, not a vague description like "coding" or "debugging". Allow for slippage, and for all the required "overhead": demo, documentation, etc. Consider what components constitute your minimal plumbing, your prototype, your alpha and beta versions, and how you can arrange your sequence of stages so you can stop at any time and declare success.

Section 6 ("Risks and Outcomes") is the place to show that you've thought about what you need to do and what might go wrong or cause delay. We're not interested in generic risks like someone getting sick, but in perils specific to your plan: learning new languages, tools, and systems; dependence on data or software or hardware acquisition. What will you do if your preferred path is blocked? Give this some thought, so you don't discover a month from now that you simply can't have something that you need

Submit your design document at https://tigerfile.cs.princeton.edu/COS333_S2019/designdoc. It must be in PDF format, and the file name must be the name of the project manager: if the manager is Jane Austen, the file name should be Jane_Austen.pdf. Anyone can submit on behalf of the group.

We are primarily concerned with content, not form or format, though if the latter are good, that suggests that you have taken some care with the former as well. Here are a few samples from some previous years.

One       Two       Three