Recently I had a discussion about the meaning of words with my wife. Most of the time, most people, play some degree of fast and loose with the definition of words and the structure of their sentences. However, there are some aspects of life and work where that will not stand, doctors visits, political discussions, and the writing of requirements. With that in mind, here is a couple simple “mad lib” for writing a clear requirement.
Form 1 Response Requirement: When <Subject> is <State> then <Action> shall happen to <Action object>.
In this form, the requirement specifies a response. For example, when my wife (subject) comes into the room (state) then I (action object) smile (action).
(Note: this should be fleshed out with definitions of “the room” and “smile”; e..g how long after, for how long. The good news is that this is a testable requirement. My wife enters rooms all the time so I can test it out tonight!
Form 2 State Check: When <Subject> is <State> then <Measured Object> shall have value <State>
This form enforces existing conditions, it can also be written in a “Before <Subject> is <State>…” form. An example is “Before the car <subject> is placed in park <state> the vehicle <measured object> shall have a velocity less then 0.1 mph <state>.
So what templates do you use?
I suggest and hope you’ll read:
“Domain-specific languages”, “Predicate Logic” and “Hoare Logic” in this paper https://bit.ly/2xKc9zW
“System testing” in this paper https://bit.ly/2OlJVqr
Templates for specifying required system behaviors include user stories, use case descriptions, and service contracts (signatures and semantics). All are variations on the theme of specifying system behaviours (services and processes) declaratively by their entry and exit conditions.
· Entry conditions may be defined as triggers, inputs and preconditions.
· Exit conditions may be defined as outputs, post conditions and the values of those to system users.