CSSE 490 – Requirements

Technical Course for the MSE Program

RHIT

Due Wed, Aug 8, 2007

This is one of two assignments replacing the original one that was to do in class Aug 1. Do this one on your own. There’s no class Aug 1.

The other assignment is ImproveYourInterface.doc, in the same projects directory as this one. It’s designed to involve the other students in class, via email.

What it is:

A chance to improve your project requirements and the associated prototype, using comments and ideas from various sources.

Where to start:

Start with your project documents and prototype. Then go find all the sources of possible changes / improvements to these you have (or might now write down). These sources may include:

  • Comments from users from your Modeling Users activity – especially, in the “Additional User Requirements”section of the document for that.
  • Comments you got about your prototype from other students and from me, when you showed it in class.
  • Other ideas you yourself had about needed changes.
  • The ID book -- This week’s work is tied to Ch 11 in ID, which you are to study on your own. It’s largely about prototyping. As you read this chapter, you should think about your own prototype versus the principles in this chapter, and write down any concerns or changes which might result from this study. E.g., Does your prototype have a consistent metaphor which makes sense?

What to do next:

Whatever, the source, the goal is to make the process of changing what you have into something you engineer rather carefully. No haphazard changes!

Create a new document called “ProjectChanges.doc” which initially contains all the recommended changes or ideas you’ve gathered.

Indicate ways of weighting these changes. For example, maybe you put them all into a table which also has columns for “Difficulty” and “Importance,” so that you can rate each change in these two ways. There should be a place for you to discuss your “response” to each possible change, regardless of how you want to list information about the changes themselves. (Perhaps underneath, if your table is getting crowded across each row.) Additionally, there should a place for you to describe how it went when you tried to make the changes you actually attempted. Beyond that, I’ll leave the format up to you.

Go through your decision process for picking which of these changes you want to try to do by class time Aug 8. Mark those that you’re going to work on, in some systematic way. One cool thing a lot of engineers do on such things is to estimate how long you think they will take, and then record the actual time when you’re done. (Or when you give up!) No cheating.

Then:

Make the changes! And record how successful they were, and/or interesting things about the process, like how long each one took.

The actual implementation of the changes is something you may or may not be able to do. You should note for each suggested change in your list how the feasibility of making the requested change quickly turned out in practice.

To turn in:

The result is your improved prototype and related documentation, to be turned in before class, Wed, Aug 8. Additionally, turn in your change sheet“ProjectChanges.doc” with all your commentary about each possible change. This will be my guide for looking at the improvements.

Please also bring along a copy of your “ProjectChanges.doc” document to class on Aug 8, so we can talk from them for about 5-10 min, etc.