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.
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...)