Saturday, May 26, 2012

Requirements (again!)

Matthew Squair is a safety guy. When he writes a requirement, it's serious stuff. People and systems can hurt themselves if he gets it wrong.

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.

Delicious Bookmark this on Delicious