Requirements Document Regrade

Team: Yes, No, Maybe So...

Grade: (99 out of 100)

The following is a breakdown of the grading. These comments are based on Version 2.1 of your Requirements Document.

Document presentation (5 out of 5)

Important points:

Organization - ok
Document author - ok
use of English - ok

Comments: There are a lot of spaces added to the document. Looks like something might have occurred when transferring the HTML file from one machine to another. Please take care of this problem as it decreases the readability of your document.

Project Description of Target System (10 out of 10)

Comments: freeze it

Scenario descriptions (10 out of 10)

3 scenarios provided - OK
level of description - good
clarity - good

Comments: Scenario 1 last line "being" -> "begin"

Hmm, sounds like you guys are prepared to commercialize the idea. I say go for it, as long as you give me some credit for the original idea. :)

Storyboarding (10 out of 10)

Evidence of storyboarding - OK, you showed it to me in class. I saw one picture of the way Cyberguide will look and it was largely influenced by the existing Newton version.
Connection with scenarios - not really, you are basically going with minimal changes to the existing Cyberguide.

Comments - I'm eager to see how you have gone beyond what the original prototype did and what novel interface features you could come up with. The path mechanism is one example of something you do that Cyberguide does not do. That's why I was noting that your connection between the storyboard and the scenarios was weak. Your scenarios suggest a lot of functionality that your storyboard seems to ignore.

Functional Requirements (25 out of 25)

Number of requirements - 5 major categories with further subdivision - good
Clarity of description - brief, but I get the idea
Decomposition - OK
Prioritization - OK, you have added some prioritization by indicating when tasks will be performed.

Comments: It is a non-trivial task to Enter project information. There are a couple of ways to make your life easier, however. First, Don Allison prepares all of the information for the Demo Day (project descriptions and locations) in a Frame Document that you could grab and work with. Also, you could consider extracting information automatically from the GVU Web pages that describe most of the projects and using an HTML renderer to display information.

How are you guys going to integrate with the positioning system. If you want more information on how that work, let me know. Also, your scenarios suggest that you will do outdoor as well as indoor positioning. Have you thought about how to build the system to achieve both? We have a GPS receiver for use with Cyberguide.

Non-Functional Requirements (14 out of 15)

Clarity - good
Measurability - good for some, not so good for fault tolerance.
Variety - good

Comments: You adjusted response time requirement, as suggested.

Platform and Network Environment (10 out of 10)

Target platform - OK
Development platform - OK, but I'm worried that you won't be able to develop for the pen, so you better come get the DTR from me.

Comments:

Risk Analysis (15 out of 15)

Risks identified - yes, but you re missing one of the big risks at this point and it is whether your system will run on the DTR. You should determine that as quickly as possible and figure out an alternative strategy if there is a problem.
Alternate strategies identified - yes, same comments as before.

Comments: