re-quire-ment: something wanted or needed; something
essential to the existence or occurrence of something
else.
spec-i-fi-ca-tion: detailed precise presentation of
something or of a plan or proposal for something; a
written description of an invention for which a patent
is sought
You can specify designs. You can specify architectures. Blueprints are specifications. Source code is a specification. Pseudo-code, state diagrams, and message sequence charts are specifications.
A statement of need is never precise or detailed. It should be clear, unique, feasible, and testable, but it cannot be precise or detailed.
The user interface shall be responsive, is a requirement. It's a poor requirement, but it's still a statement of need.
Lamp X shall illuminate 100 ms after button Y is pressed, is a specification. It defines a precise description of events. It's not a requirement. No information regarding the stakeholder's need has been conveyed.
I can usually spot a specification when I see one. A good requirement is difficult to identify and even harder to write. Authors naturally tend to slip into writing specifications because they don't know how to express their needs. Requirements are also subjective. Some people might view the statement, the UI shall be responsive as failing to convey need. One can always ask, why must the UI be responsive?
I admit I'm on a holy crusade to eradicate the term Requirements Specification. Let's call it a Requirements Document or a Requirements Database. Let's save the term specification for the Software Specification that will follow the Requirements Document. Typically this is a High Level Design and Low Level Design. Those documents are worthy of the title Specification.
No comments:
Post a Comment