Requirements Document Comments

Team: Yakko Wakko and Dot Dayplan

Grade: (89 out of 100)

The following is a breakdown of the grading.

Document presentation (5 out of 5)

Important points:

Organization - good
Document author - OK
use of English - OK

Comments:

Project Description of Target System (10 out of 10)

Comments: Well done. Don't change a thing. I like the pointers to Java references.

Scenario descriptions (10 out of 10)

3 scenarios provided - yes. And each one highlights a different feature of the system. Good job.
level of description - nice level of detail and interesting to read.
clarity - no problem

Comments: Boy, someone must have learned something in 2390! :)

Storyboarding (7 out of 10)

Evidence of storyboarding - PostScript file
Connection with scenarios - not that direct.

Comments: OK, so I can see that you have three main views - the calendar launch page, the monthly view and the daily view. The daily view appears to have two separate subviews, one for the personal schedule and one to show an overlay of people. Will that overlay always be showing? How do I go about defining what people get shown in the overlay? It raises a lot of questions. What about weekly view? You mention it later on. It would be nice to have a clearer picture of exactly what you expect to show up in the various views. You try to do that in the functional requirements, but it is at this point that you can experiment. Maybe you have done this on paper. If so, you should show me.

Functional Requirements (24 out of 25)

Number of requirements - 8 divided into three groups.
Clarity of description - good
Decomposition - OK
Prioritization - yes

Comments: I don't really see why there is a difference between adding multiple appointments and adding a special date. Presumably, you would want to define a language for specifying repeated events and that would be general enough to cover both cases.

Not clear how you will determine the set of users in the overlay multiple schedules mode.

Non-Functional Requirement (14 out of 15)

Clarity - OK. First category is very good. In the second category, I don't see why you grouped correct date range as a response to the planner category. I think a better way to gauge the reasonable response time is to say that any access to the dayplan will complete before the network timeout, but I'm not sure how that will work. I don't understand the correct date range requirement.
Measurability - the interface to .dayplan are very specific and hence you can test them. Response time I think you can measure, but how can you guarantee that a network access won't time out? All you can say is that it won't time out under working conditions due to processing of the dayplan, but would that ever occur?
Variety - good

Comments:

Platform and Network Environment (7 out of 10)

Vehicle platform - Internet connection and Java beta Virtual Machine. Which one? Probably Netscape, but you should be specific.
Development platform - Java Development kit on what kind of platform? You should be specific.

Comments: Won't you have a constraint of storing the persistent calendar information on the same server on which you download the applet?

Risk Analysis (12 out of 15)

Risks identified - Yes. I'm not clear as to the difference between the socket solution and the store all info on server. Aren't they the same?
These are OK risks, but there are other important ones as well, such as ineffective training (nobody can write Java code in time). What if somebody drops the course?
Alternate strategies identified - yes

Comments:

If you wish to have your Requirements Document regraded, revise it within one week of receiving comments. Be sure to maintain a link to the original version of the Requirements Document in your notebook for comparison purposes. To get a regrade, you must send e-mail to the instructor requesting the regrade.