Notes:

1. Give a Lecture-style presentation of the contract between you and your clients this quarter. What is the structured list of requirements you have this quarter, and how will we know that you met those requirements?

2. How careful should you be about your requirements? Suppose that you gave these requirements to a design/implementation team that wanted to do as little as possible, and had no interest in you or your goals -- they felt bound by the contract you gave them (the requirements), but would certainly look for the easy way out through any loophole in the requirements document. Now, how clearly have you compelled them to build, and test, the system you desire? This is the measure of your work, and will be the yardstick by which it is judged.

3. Conversely, suppose that a client was taken over by an unscrupulous corporation, and they wanted to avoid paying your development team anything. They would follow the letter of the requirements contract, but that is all. How carefully does the requirements document specify what tests you have passed so that you can prove you should be paid?

4. Requirements development: Are your requirements concreted, grounded, and empirically testable? If not, edit them.

5. Requirements tests: Given your requirements, how will you know if you met them? What explicit tests can you run for each requirement?

6. State diagram for the system: What are the allowable states for your system, and what are the transition triggers for the different states? (You may also wish to include this in your design documentation.) See the Finite State Machine example.

7. Note: Students tend to focus on the less-interesting, and less-demanding, aspects of screen interface and input specification. These are important, but it is often the internal workings of the system that are in much greater need of formal specification, which often have to do with the state transitions that are allowed or disallowed. Avoid spending valuable time with uniteresting screen interface discussion.