Use cases, BDD and Clean Room
The canonical form of requirements or “behaviors” in Behavior Driven Design is something like:
GIVEN <situation> WHEN <condition> THEN <predicate>
Where <situation> describes the state of the system and <condition> describes what’s actually happened to cause the system to express a behavior. <predicate> verifies that the correct behavior occurred.
Uncle bob says that this is a finite state machine in English, which is true, but it also has a similarity to the black box specifications of cleanroom:
| Stimulus History | Stimulus | Response |
| What has happened to the system before | What’s happening to the system now | What we want the system to do |
Now, this is a step before the finite state machine, that’s called a “state box” in Clean Room parlance.
Clean Room separates this stimulus history driven black box from the state machine to maximize the flexibility in allowed implementations. The idea is to start with some natural language entries in the black box description and go through discussion with the client, as this is happening, stimulus histories are generated using combinatorics to make sure that all possible histories are covered.
This guarantees something called “referential transparency”, which basically means that the black box specification is complete and preserved at all levels of “detailing” and implementation.
This doesn’t deal with the ambiguity of human language, but gives specifications some structure that should help turn it into procedure and code.