Why is the payload textual requirements?

Despite being an executable MBSE method, the ROCKET method takes a strong stance that the payload carried by ROCKETS will always be textual requirements. There are good reasons for this.

Firstly, textual requirements are a common currency (as a manager I know used to say a lot). Executable MBSE can be our money-making machine but - by producing and consuming textual requirements in models - we can spend the money in different shops (outside of the model). For example, we can put textual requirements into a Requirements Management (RM) tool like DOORS NG or DOORS 9, send them to suppliers in ReqIF format or using a exchange server, and we can  exchange them with test management tools like RQM. A focus on textual requirements as the formal hand-off eases adoption of MBSE techniques into an existing requirements-driven business or process and means that all those good things that come from a focus on well-formed and well written requirements still apply.

Secondly, SysML provides a very clear, mature and intuitive way of dovetailing textual requirements with models, well supported by tool integrations with RM tools. Textual requirements being neutral to modeling elements can be associated with different views of the same system, e.g., activity models, interaction views, state machine diagrams, use case models, static design, and interfaces. Requirements are omnipresent, in that they can be shown on any of the diagrams or meta-elements that make up the OMG SysML standard. You can use a host of SysML artefacts like tables, matrices, and diagrams to view and create traceability in a model to enable you to get the best of both worlds.

This shows a textual requirement tracing to an action and accept event action on a SysML/UML activity diagram:

This is the same behavior described in a SysML/UML sequence diagram:

This is the same requirement tracing to a transition on a SysML/UML state machine:

All of these examples of refinement at the same level of behavioural abstraction. Each transformation is done for a different purpose.

Importantly, since the same textual requirement can be associated with different modelling elements this enables something very subtle but inherently powerful to occur in the ROCKET method, which is the transformation of model data from one form to another. Each of these behavioural representations is representing the same requirements in a different way. Like stepping stones (moon hops) over a stream, they enable you to get to the other side without getting wet (which is never a good thing when it comes to being a systems engineer ;-). You can even make a choice about whether to use the stones again or throw them away. Use case steps can be transformed into operations and events and put into state-machines that can be executed to create test scenarios that show operations and events, that can be copied to Blocks that represent architectural components, which by virtue of the copy will trace to the same requirements, so that when you create a sub-system requirement the traceability to the higher-level requirement can be done in-situ.

Since the method is highly formalised, highly systematic and thus repeatable. By systematic, I mean that it involves lots of little steps (nope, not a giant leap for man/human kind ;-). The systematic nature of the model transformations means they can be supported by automation that speeds it up. Engineers can focus on engineering decisions about their problem, rather than how to build models or use the tool, and tasks of refining the requirements can be optimised into phases (don’t worry about executing a model until you’ve actually spoken to stakeholders to validate the needs and art of the possible). Hurrah! What's not to like?

The consistency of the systematic approach and the use of automation leads to a production line mentality. Models that come off the line will have common layouts and make consistent use of the SysML metamodel. This makes external audits a doddle and means that engineers working on one model can easily switch to a model created by different teams using the same method and tools, enabling you to move resources easily between projects. Systematic approaches can be documented and thus used for quality assurance purposes enabling external audit like 26262 and A-SPICE for automotive, or FDA approval (of medical devices).

Phew! (I'll take a breather, stay tuned for more...)