Elicit every edge case.

Statestep originated in embedded systems. Two indications that it could deliver significant value for you are:

• Your project is a reactive system, changing state in response to events which may occur unpredictably.
• The system has a user interface with multiple functions: users do unexpected things, and one needs to think about how the system should behave in less obvious cases.

On the other hand, Statestep is unlikely to be appropriate where data transformation is the predominant source of complexity.

If you have a project in mind then feel free to get in touch for an opinion on its suitability.

Secretly, the Statestep approach is a formal method of specification, but without the mental weight lifting. Statestep's major comparative advantages are:

• Elicitation: Formal methods are good at avoiding logical contradictions but poor at uncovering errors of omission. Statestep excels at elicitation, prompting you to consider all the questions that need to be asked, e.g., When Function X is engaged, should Setting Y be cleared?, where the answer might be Yes, to avoid user distraction or misinterpretation.
• Simplicity: Most formal methods require mathematical acumen, and are employed only if a project is thought to justify the effort, perhaps because it is safety-critical. In contrast, a Statestep model is easy to understand and may even be shared with stakeholders to validate it.

(Formal methods is a broad term. Technically, the Statestep approach is model-based, employing the finite state machine concept; where that does not fit, other methods may suit.)

Statestep performs the most useful function of a model checker by confirming that no illegal state can be reached. It can interactively check this reachability property even while the model is being created, without spurious errors.

While Statestep is designed for modeling system state transitions, it can also be used just to create decision tables. Unlike standard decision table tools, it allows you to:

• manage enormous numbers of possible combinations of conditions (e.g., billions rather than tens of cases);
• use a constraint table to exclude impossible cases (rather than dummy rules);
• optionally use formulas to express constraints or rules.

Not arbitrarily, but well enough for that often to be only a theoretical concern. Where practical limits have been hit, users have continued to benefit from the method by modeling relatively independent portions of a system separately.

For academic and non-commercial use, you can request a free licence. Free help may also be available.

Commercial use of the tool is on commercial terms, though that may be included with consultancy. Please ask for a full evaluation licence, describing your use case (exclusions apply to some application domains).