CT320: Requirements

Homework Requirements

Consider the requirements for a homework assignment:

Read two integers. If the first isn’t divisible by the second, print “Oops!”

You might reason:

All numbers are divisible by all other numbers, just not evenly (you forgot about zero). Therefore, I never have to print “Oops!”

Or, you might think:

The assignment doesn’t say what to do if it is divisible. I’ll print “Oops!” unconditionally!

You might get away with that sort of reasoning in court, but not here.

Assume that I’m not an idiot—the requirement must be there for a reason.
If the requirement makes no sense to you, then you need to seek further explanation.
The requirement might be deliberately ambiguous:
- I might just want an error message, but not particularly care about the wording, as long as it makes sense.
- It might be there as a test.
- I might have just screwed up.
This isn’t a holy book written centuries ago. Ask!
Of course, if you first read the assignment a half-hour before it’s due, asking is more difficult.

In the REAL WORLD, requirements are quite informal.
Your boss might say, “Write a program that tells us if too many invalid web page fetches are attempted.”
You might respond:
- “Sorry, but your specification is totally imprecise!”
- “What should the text of the error messages be?”
- “Precisely how do you define ‘invalid’?”
- “How many is ‘too many’?”
You would then sit back, cross your arms, and smirk, because you won.
Your next assignment would involve cleaning toilets.

Instead, your boss expects you to use your brain, and resolve those ambiguities.
You should return to your boss with your interpretation of the assignment:
- “The program will react to any HTTP/HTTPS fetch that doesn’t result in code 200.”
- “It will react to more than ten bad accesses in a minute.”
Your boss will either say “Yeah, that’s fine” or correct you.
Happiness ensues!