In a recent posting he linked to a paper he has co-authored about writing good requirements and specifications, especially for safety and fail-safe systems.
Here's an example from that paper, entitled "What Happens when Engineers get it Wrong"
The following is a real example consequences of a requirements error:
• As written – “The system shall ignore all
anomalies 20 seconds prior to shutdown”
• As built – “The system actually cleared the
anomalies list 20 seconds prior to shutdown”
• What was needed – “The system should have
ignored all anomalies occurring in the 20
seconds prior to shutdown”
• What happened - The system detected an
anomaly within the window of vulnerability,
responded and as a result destroyed itself.
While this example is a safety related one, such
errors can be no less costly in terms of time and
money for less critical applications.
He then continues with some advice about constructing a requirement, saying in part:
"The most basic construction of a requirement can be expressed as an actor (the thing of interest), performing some act (the action to be taken) upon a target (the focus). So in the preceding example the system is the actor, the act is to ignore and the focus is the all anomalies. The requirement also has a constraint applied, in that the act can only occur in the 20 seconds prior to shutdown."
This really isn't too far from writing a use case in a structured way. One reference I like on use cases is by Karl Wiegers entitled "Software Requirements". In spite of the title it's quite a good tome on how structure good requirements, whether emergent, incremental, evolutionary, or foreseen.
Bookmark this on Delicious
This really isn't too far from writing a use case in a structured way. One reference I like on use cases is by Karl Wiegers entitled "Software Requirements". In spite of the title it's quite a good tome on how structure good requirements, whether emergent, incremental, evolutionary, or foreseen.
Bookmark this on Delicious