Introducing Behavioral Driven Design and Development (B3D)

That will take care of "Ill-defined goals and requirements". Sounds like a great start!

How about communication? Rather than creating traditional documentation and "bundling it up and throwing it over the wall" (aka Telephone Game), what if we had a single-source-of-truth artifact which any process participant could access, and which had everything they needed to do their work? Clearly, this would fix those Telephone Game problems!

Working toward achieving these goals, we can start with a simple diagram based on standard "use case" or "customer journey" phrasing:

As a consumer of the system's behavior, I want to provide <Trigger> and have the system respond with <Behavior>.

Rephrasing this as a test case, we get:

GIVEN our system is in a "start" state, WHEN the trigger event occurs (WITH data...), THEN the system responds with <behavior>. We can (and should) represent this as a simple directed graph:

Let's get back to basics.

What is a bug? A bug is when expected behavior does not match observed behavior. It's that simple. A system which doesn't behave as a customer expects is a failure.

There are implications here

• We need to have a clear, unambiguous statement of expected behavior for all triggering events and data states, and

• We need to collect observations of actual behavior for each of those triggers in a way which can be compared against expectations