Model Based vs. Textual Requirements

Requirements Run Amok

Requirements are high-level things, typically stating that the system shall do something. Their purpose is to demonstrate why I am doing my design at all. Over the past 30 years, requirements have become a place for engineers to put in every little detail they could think of. I suspect this is because they didn’t have another way of documenting them. However, they really should be more abstract and conceptual. The model, the design, the elements: these should be the detailed requirements. This is the system they should be striving for. The values, systems, subsystems, why they occur, how it is broken up — all of this is can be done in SysML.

Let SysML Design Your Digital Information Model

Recently I was asked via LinkedIn engineering group post: “What tools are out there in the marketplace for requirements engineering?” Undoubtedly, it is becoming increasingly complex to keep track of requirement-by-requirement changes. After mulling the question over, I realized that there might be a misperception among the community. Namely, that requirements engineering is not really a discipline. Rather, requirements are a subset of systems engineering. Not wanting to belabor the point, I answered her straightaway, suggesting that DOORs and PTC Integrity are the two major players. However, I also felt compelled to emphasize that she should not cut herself short by neglecting to model her requirements using SysML. This is something that SysML and the modeling languages demonstrate.  The stepping stones from textual to model based starts with having the visualization of the textual element as a block in SysML.

Visualizing Requirements

How can I take my requirements and visualize them? Let us move beyond tradition and start to consider the models we are building as the actual system we want to build.  The model itself becomes the information.  Instead of having to write down a single word, can I draw an entire requirement set in, not just SysML but perhaps CAD in conjunction with SysML, to define all the details that I need? 

Understanding the difference between seeing your system context in a model as opposed to having to read into your requirements and understanding the context is fundamental. Knowing that systems engineers need to communicate with all the other disciplines they interact with a model tells a better story than reading seperate requirements.

I can model structure, flow, information, or whatever I have typed in my textual specifications. If my textual document specifies: do these five things, then those five things should be in a sequence diagram. Sequence diagrams describe how and in what order the objects in a system function. Entities collaborate to realize a use case (or other behavior).

Or if it identifies a certain order that must happen, then it should be in an activity diagram, showing flow. The point is that you can visualize all of these things, instead of producing an ambiguous written document.

Example of Requirements Modeling With SysML

Consider I have a SysML model of a car. The car, of course, has tires and those tires will have values of type psi with a specific pressure (35 psi for example). Therefore, I know from my model that when I see a value type of type psi, it is specifically related to the tire. This is because it is in the context of the tire. I know that it is not some pressure related to the engine compartment or something else.

If the requirements were in paragraph form, someone would actually have to type in the words tire psi, and then the problem of interpretation comes into play. Or I would have to know that it is, for instance, spelled out underneath Subsection [Tire], Subsection [Value] within the requirement. I am just doing the same hierarchy sets, ordinarily done in a systems model, in design. So, why bother with the textual values stored inside the requirement tools for any purpose? Why do textual requirements at all? I can plan the entire thing by putting together a model that specifies—this is the system I want to build. I can trace it to CAD or whatever else I want, and I am good to go.

In fact, we can run performance analysis using solving engines and pull those numbers back into our model.  The new numbers become the values that the system actually needs to be built, tested, and to be validated against.  If it was still in textual form, we would have to go back and rewrite the requirement as well.  Any value you have in the requirements should be directly dropped into the appropriate part of the system and that data value should be a surrogate, a direct one-to-one. This is to eliminate the countless paragraphs we’ve all had to weed through, and just focus on modeling.

Intuitive Engineering

If you’ve ever had experience building model airplanes as a child, did you have step-by-step requirements telling you how to build them? Or were the instructions simply a graphical representation of the parts being put together? When did we grow up thinking that typing up something in the language would make products better? As engineers, we like to describe ourselves as logical and rational. However we’ve become too reliant on textual based requirements. We should also accept intuition as a versatile tool in our arsenal. 

Requirements Derived From Use Cases

I feel like I’m beating the proverbial dead horse here, but I believe it’s worth another argumentative approach for understanding.

In a typical SysML model, use-case diagrams specify what the system does, which services it provides, and what capabilities it has. In other words, a use case diagram can be interpreted in any of three ways:

• Functionality – how does the user use the system? A person starts a car, for instance.
• Services – what services does the system provide? This could be anything from the Internet of Things (IOT) service to simply turning a light on.
• Capabilities – what potential does the system have? For example, the motor can pull 10Nm torque.

Users can also indicate a customer needs set that can potentially become a stakeholder value network or SVN. The SVN specifies which customers have higher priority over others.

Therefore, requirements are created from the functionalities, capabilities, and services of use cases. If all that is needed is to specify something the system must do, then the user can do a textual requirement. If the requirement is of a specific value, for instance, x psi, x display ratio, or x material, then this should be done directly in SysML, in the modeling tool. These are variables that belong to part of the system. I don’t need to put values in my requirements if they can be in the system design directly.

US Army Leading the Way Towards MBSE

This process of transitioning from document to a model-based approach is already happening, and is catching on in many organizations. In fact, the US Army REDCOM is currently testing out all of the tools in the market for model-based via the Joint Multi Role Technology Demonstrator. The JMR-TD will do a technology trade study of the available tools in the marketplace to remove the need for textual and/or digital requirements to all digital information models.