CMPS183, Fall 2011, Section 01: Design - Description

Now that the requirements for your Web application have been specified, your team needs to collect together decisions concerning the software architecture, database schema design, information design, software design, and detailed graphical layout of pages in your site. Together these comprise the design of your project.

There are several benefits of having an explicit design phase. One is that your team develops a consensus on the design approach for your project up front, before starting low-level development. This improves communication among your team, and ensures that team members are working towards the same goal. Another is the ability to explore different design alternatives while it is still easy to modify the system. Once code, XML, and HTML has been written, it becomes increasingly difficult to make significant changes to it. Finally, the design activity causes ideas to be fleshed out before development work occurs.

For the design phase of your project, you need to provide the following:

  • Information design: Provide 1-4 pages of text describing the rationale underlying your site's information design. Then, provide a graphical or pictorial representation of your site's information layout. This might look similar to Figure 9-5 in Chapter 9 of Hypermedia and the Web (is class reading). Be creative, yet accurate in representing your information design.  
  • Data design: Provide one or more diagrams that give the database schema, including all tables, columns, datatypes, and relations.
  • Software architecture: One or more diagrams showing the architecture of your entire Web application (including browser, server, servlets, databases, other information systems with which your code interacts, etc.) The internal architecture of the server-side code (and client side code, if applicable) must be described (i.e., it is not sufficient to just have a component labeled "servlet code"). The architecture diagram must clearly identify which code is being developed specifically for this project, and which code is being reused (such as a PHP component).
  • Refined prototype/storyboard: An improved version of the paper prototype and/or storyboard created for the scenarios and requirements phases. Whereas perviously the paper prototype and storyboard was not required to have significant presentation details, in the design phase you must now make decisions on items such as:
    • amount of screen real estate dedicated to each page component
    • fonts, colors, and other presentation details
    • logos
    • link highlighting
  • Customer approval of requirements: (Only for groups that have an external customer.) Similar to the requirements phase, for the design phase you must include an email message from your customer that states:

    I have read the requirements document produced by {your team}, and approve it as an accurate representation of current project requirements. The team is ready to begin translating the requirements into a detailed design.
  • Security review: 
    • Detail what personal information is retained by the site, how it is protected, and what the policies are for the use or sharing of such information.  What is the communication policy of the site?
    • Detail the measures taken to protect the site from common attack classes, and make a credible case that the site is safe from such attacks.


Similar to the requirements phase, your writeup must include a title page, change log, and table of contents.