Since there are a variety of projects in the class this term, there is no single design strategy to be taken. For some projects, a functional approach might be best. For others, an object oriented approach would be most appropriate. For web page design, some combination of object oriented and user interface design might be the best way to go. Additionally, For that reason, the structure of this document is left fairly open with the exception of the first several sections which are described further on in this document.
Recall that Sommerville divides the design process into the following phases:
Please work to organize your design document as much as possible around these principles. Also recall that if you are taking an object oriented approach, you should probably include:
If yor are taking a functional approach, you should probably include
Use the graphical conventions found in Sommerville for this. If you are taking either approach, you may find an entity-relationship diagram useful, and a data dictionary is probably a must.
If you are designing a web page, consider that you are primarily (though not exclusively) designing a user interface. You may have already decided on some sort of iterative prototyping as a development strategy. You could probably take either a primarily object or functional approach (though I admit that I am starting to consider an object-oriented approach to be most appropriate - consider each page as an object?). In any case, you will need drawings of the various pages, some way to show the network of pages (a directed graph - from this page you can get to ..., etc.), and of course some design for any functions that are included (particularly Java code).
Finally, please make your documents professional. Part of your grade on the documents will depend on the appearance, organization and attention to clear writing in your documents. The following sections should appear in your document in the order given.
Design Document for the XYZZ project
Your names here together with email addresses.
Include, in your own words, the purpose of a design document.
This should be a list of each change to the document together with the date the change was made and the reason for the change (i.e., respond to client's or reviewer's comments). The first entry should be the date on which the document was first turned in to me.
I use \LaTeX for much of my writing, and would be happy to give an hour's lesson in its use. I'm sure that any word processor you use will have some provision for table of contents (though I've never learned how to do it in MS Word, I'm afraid).
Brief description of the problem this system solves, and how it will solve the problem. Include a discussion of the design approach adopted, and why you decided to do things this way.