Thursday 28 June 2018

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

Monday 25 June 2018

Introducing ROCKETS: An executable MBSE process

What is the ROCKETS MBSE process?

I've decided to name my MBSE method ROCKETS. ROCKETS is a derivative of the the Harmony/SE method that uses executable MBSE with SysML and IBM Rational Rhapsody. It stands for Requirements Originating in the Context of Knowledge Executed as Transitions on Statecharts. It’s designed to be fun. To make it fun a couple of aspects are considered important:

  1. Automation, so that the user is focused on the creative aspects associated with solving the problem, rather than setting up the model.
  2. Systematic, the method splits the problem down. The adage is to take tiny steps rather than a giant leap.
  3. Team work. How people interact during the process is considered as important as the artefacts that are produced.

The approach is use case driven, and conforms to the original definition of a use case as:
“A description of a set of sequences of actions, including variants, that a system performs that yield an observable result of value to an actor” [Booch, Rumbaugh, Jacobson 1999] (where actors are entities outside of the system that gain value from or participate in the use case)

Importantly, use cases are stories about how the system is intended to be used. ROCKETS is therefore a method focused on concept of operations (CONOPS) modeling. CONOPS models describe clearly and concisely what the is to be accomplished and how it will be done using available resources. As such it is independent of aspects such as programming language and software design. We are trying to model who needs to do what, rather than how it is done.

What are the phases of the ROCKET process?

There are three phases to the ROCKET process:

  1. Payload definition.
  2. Launching the rocket(s).
  3. Assembling the space station.

The key challenge overcome from the ROCKETS process is the management of complexity; the division of responsibility across a team and between teams of engineers such that the task can be accomplished with productive use of resources. In practice these phases occur in parallel, as we can’t get the whole space station into a single rocket, we need to send up a series of rockets.

The space station analogy is a useful one because we can picture it as a series of components that are interconnected. Importantly, we might read the components as component owners. This is a systems engineering task to allocate work to different teams by deciding which team needs to do what.

Payload definition starts on the ground with the creation of functional system requirements that we intend to launch up to the space station. To get them to the space station we need to launch them. We do this with executable MBSE. Much like how we might hypothesis how a clock might work, executable MBSE involves building a simulation that we can interact with to test how the system may work. We then need to get the payload into space in a rocket where they will be assembled by a separate team.

What is the relationship to process standards?

ROCKETS process aligns directly with Sys.1 to Sys.5 of A-SPICE 3.

SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Test
SYS.5 System Qualification Test

Friday 22 June 2018

Gen #3 profile testing with TestConductor

I've concluded first round of enhancements focused on being able to move sequence diagrams involving interacting with the simulation into test cases in test conductor. I actually found more enhancements were needed than expected, hence a few changes from the Gen #2 profile were needed. Main thing was to make use of Interfaces on ports (rather than use rapid ports). This introduced an issue I hadn't considered around inheritance in framework. However, that's all solved with a few changes to the helper.