WebSchedule Design Review Summary - Group 5 Document Version 1.0 2/18/99 [mrt.jpg] "I pity the fool who can't schedule meetings!" Winter Quarter 1999 2/18/99 Document Author: Jason Riggs Project Sponsors: The North Avenue Review Center Street Hall Council Project Team: Adam Lotz (Manager) Anthony Carl (Programmer) John Mooney (Architect) Andrew McCallum (Technical Writer) Jason Riggs (Quality Assurance) General information Date of review: 2/16/99 Link to artifact under review: Design Document Version 0.9 (2/15/99) Roles: * Facilitator - Jason Riggs * Recorder - Andrew McCallum * Document Author - John Mooney * Internal Reviewers - Adam Lotz and Anthony Carl General issues raised * a couple of spelling problems (raised by Jason) * a few grammar problems (raised by Jason) Specific issues raised High Level Architecture * An issue was raised with the back end diagram. The reviewers thought that it contained too many lines to be easily readable and understandable. (raised by Adam and Tony) * The high-level architecture contained vague language. For example, "function which may be called". (raised by Adam) * An issue with the chosen architecture for one of the requirements was raised. The first requirement says Users must have a way to add their schedules to the database. This will be accomplished by simply clicking on the schedule grid on the times when they will be unavailable. The architecture says this will be accomplished by check boxes. An issue was raised on whether it was possible to use something other then check boxes. For example, something you could click and drag, and would be easier for the user. (raised by Jason) Architecture Rational * The following requirement was listed but not justified: The system will be able to maintain schedule information for multiple groups. It was determined that this requirement will be ignored. There was no justification for this in the design document though. It was decided to drop this requirement because it didn't fit the scope of the program. (raised by Jason) * The architecture rational would be easier to read if it were divided between the functional and non-functional requirements. (raised by Adam) Design Specification * One reviewer thought that the OOP section of the design specification needed more detail. (raised by Adam) * The programmer brought to the attention of the architect that using C instead of C++ would be easier for him. (raised by Tony) User Interface * An issue was raised about the general architecture for entering times. The reviewer felt that it could be made easier to the user. (raised by Tony) * It was brought up that in addition to links to snapshots of the user interface, that thumbnails of the screen shots would make the user interface section easier to read. (raised by Adam) Results of review Priority Issue assigned to: expected finish date High a couple of spelling problems John 2/19/99 High a few grammar problems John 2/19/99 High The following requirement was listed but not justified: The system will be able to maintain schedule information for multiple groups. It was determined that this requirement will be ignored. There was no justification for this in the design document though. It was decided to drop this requirement because it didn't fit the scope of the program. John 2/19/99 High The programmer brought to the attention of the architect that using C instead of C++ would be easier for him. John and Tony 2/19/99 High The architecture rational would be easier to read if it were divided between the functional and non-functional requirements. John 2/19/99 Med. An issue was raised about the general architecture for entering times. The reviewer felt that it could be made easier to the user. Tony 2/24/99 Med. One reviewer thought that the OOP section of the design specification needed more detail. John 2/24/99 Med. It was brought up that in addition to links to snapshots of the user interface, that thumbnails of the screen shots would make the user interface section easier to read. John 2/24/99 Low An issue was raised with the back end diagram. The reviewers thought that it contained too many lines to be easily readable and understandable. John 2/24/99 Low The high-level architecture contained vague language. For example, "function which may be called". Adam 2/26/99 Low An issue with the chosen architecture for one of the requirements was raised. The first requirement that says Users must have a way to add their schedules to the database. This will be accomplished by simply clicking on the schedule grid on the times when they will be unavailable. The architecture says this will be accomplished by check boxes. An issue was raised on whether it was possible to use something other then check boxes. For example, something you could click and drag, and would be easier for the user. John, Tony, and Jason 2/26/99 Revision History 1. Date: 2/19/99 Name(s): Jason Riggs Description of revision: Initial document Link to WebSchedule Project Notebook Last Modified 2/19/99 -- Jason Riggs