FSM ⁽¹⁾

The ability to trace requirements through to implementation is an important property of commercial software development. As we know from the last 24 years of Agile, it's very rare to be able to obtain a complete, consistent and correct set of requirements at the start of the project, in practice they have to be continually refined during development. One of the common failings is to think only in terms of positive requirements - everything the product must do; and to forget the negative requirements - everything the product must not do. Very closely related is the problem arising from only specifying part of the logic, the default or happy path e.g. "when the button is pressed ..." and forgetting to specify the other part e.g. "when the button is released ...". It's not always obvious what the product should do when logical states change back to their default, when conditions revert to normal or when users cancel operations, causing developers to make assumptions and resulting in a major source of bugs. The requirements always start life as a text document but once these start to become understood by the developers, we can translate them into diagrams. In larger and regulated…