Your Project Name

Design Review for Name of Project You are Reviewing

??/??/04, Version major.minor

 

 

Instructions

This is a design review template for CS169.  Each team must send a copy of this completed document to cs169@cory.eecs.berkeley.edu by 5pm on the due date. The subject line of the email message must contain only the word “proj5”.

 

Your group has been assigned to review the design and planning document for one of the other projects.  You will receive an email containing the design document to be reviewed, along with the requirements document that you should use to understand the problem to be solved.  

 

For this class, the design review serves two purposes.  First, it is the last check that projects are addressing a clearly understood problem in a coherent and practical manner.  While the course staff will also review the design and provide feedback to groups, there is great benefit to having more people read and comment on designs before a lot of work is invested in coding.  Second, you will be the quality assurance organization for this same project in a later assignment; we will expect you test that group’s code.  This assignment will familiarize you with the other project, and give you an opportunity to have input into their design prior to testing.

 

Summary

 

Here you should give a summary of your design review.  This section, which should be relatively short, focuses on the recommendations you consider to be the most important.

 

Questions

 

At the end of the design document template, there were a number of questions that you should use to guide your review. Please organize your comments as answers to the following questions (which summarize the questions from the design template). Your answers may be of any length, but should be justified by reference to specific parts of the design document (and specification, if appropriate).

 

1.      Are there any inconsistencies in the design?  That is, does the document contradict itself?

 

2.      Are there omissions in the design?  That is, are there elements that are mentioned but never discussed, or obvious pieces that are missing?

 

3.      Are any parts of the design unclear?  The standard should be that given the design document, a competent programmer can code the project.  Note that “clear” does not mean that the document must be very detailed.  We assume that a decent computer scientist can fill in missing details, provided the overall document is clear enough.

 

4.      Are there technical errors in the design?  Is there any statement of fact that you know is false?

 

5.      Has thought been given to testing?  How would you test this design? What, if anything, could be done to make the design easier to test?

 

6.      Does the design make realistic assumptions about the environment?  That is, will the team have trouble getting access to important external components (e.g., specialized hardware) and are the systems the project needs to interact with suited to the purpose?

 

7.       Does the plan seem realistic?  Are tasks at a reasonable level of granularity and is it clear what each task means?  Do the time estimates seem appropriate?  Do any parts of the plan seem risky in the sense that they are likely to become a bottleneck to further progress?

 

8.      Any other comments?

Team Assignments:

 Check out http://inst.eecs.berkeley.edu/~cs169/handouts/teams.txt to get contact info for a team, in case you need to communicate with them directly.