Specifications and prototypes Pub Share

Here are some of the use cases:

• system requirements capture and management
• simulate micro-services
• stimulate micro-services

System requirements | capture and management

We normally capture requirements in one or more Word documents, which are handed out to architects, vendors and developers. Often, these documents go out of sync with the actual system needs as well as the implementation.

Also, acceptance criteria are often not up to date and most of the time, just some text in a document.

We aim to change that. Instead of words in a document, build a wiki, where we organize the requirements and acceptance criteria and tests. These are "live" and run all the time, throughout the development lifecycle and even production, increasing quality.

In the most generic case, requirements are of the form: "when a message is received, we expect this and that".

$msg home.guest_arrived (name="Jane")
$expect lights.on
$expect (lights=="bright")

dsl here...

result...

Continuous acceptance

These requirements stories, once written, can be validated any time, against the delivered system. They can be triggered manually or via scripts when the underlying implementation changes.

They could also run against production data, for assurance.

Simulate micro-services

While designing and architecting solutions, we will not always have access to the other services that we need to actually run the system. We can though simulate them here, via mocks:

$mock lights.check => (lights="bright")
$mock chimes.welcome => (greetings="Greetings, "+name)

dsl here...

result...

Now, the lights.check and chimes.welcome microservices are available and will be simulated with the rules above. You can now develop elsewhere, the logic that connects and/or uses these.

Stimulate micro-services

On the other hand, if we already do have the services we need to complete our architecture, we often have to wait for some functionality to be developed, to connect the basic services available, until we can use that and/or write other higher-level logic.

With this tool, you don't have to. We can simulate inputs and dispatch calls to the services we already have, to test the higher-level logic, before the code is even written.

$when home.guest_arrived(name) => lights.on
$when home.guest_arrived(name=="Jane") => chimes.welcome(name="Jane")
$when lights.on => lights.check

dsl here...

result...

Now, the home.guest_arrived microservice is available and will simply connect those others. You can continue developing some other logic depending on this new aggregate service!