Requirements Specification Draft Comments

CS 325, Software Engineering Concepts, Spring 2001


Don't give trivial specifications.

"The amount of speed and memory is sufficient to run the system."

Well, yes. And the system will not unnecessarily kill its users. Specify in terms of the problem:


Don't complicate the problem.

"The system will run on a network of computers within the business."

What business?
This is usually a symptom of last-minute scribbling.

Where is network operation justified by the informal spec?
Even if it's justified, are you sure you want to do all this work?

Assign Team names.
This is reasonable, but is it necessary? Do you want to deal with the extra work?


Be consistent.

"A student can create a new group." vs. "Only the professor can create groups."

Which is it?

Make sure you cover the informal spec, and don't contradict it.


Write well.

Define your terms: "Input", "Output", "Student-Id", "Group", . . .
What are these things?
Watch spelling.

Watch those dangling modifiers.

"The intended readers are the system designers, team manager, and, once validated, the programmer."


This page last modified on 21 February 2001.