When I talk to systems engineers about Innoslate, they are often very intrigued and relay an all too common story to me.
“We have a tool for managing our requirements and a separate tool for doing our modeling. We find ourselves getting in trouble as updates to requirements are only made in the requirements tool and there is no linkage to the modeling tool to know that an update ever happened.”
I am sure this story sounds all too familiar. You may have lead a team that faced these problems or were in charge of modeling for a project and were constantly having to hunt down requirements as they change. To me having two tools creates two specific problems: separate repositories and lack of traceability through the lifecycle.
Separate Repositories: Each tool manages and maintains their own data. Often the only way to communicate between the two tools is via some sort of export. Commonly, this is a one-way street and becomes a hassle to take updates from one tool and get them into another.
Lack of Traceability: Having the separate repositories makes tracking who changed a requirement; why a requirement was changed; what changed a requirement; what model element does that change effects; and what is the overall effect on the system a difficult task to do. This lack of traceability can grow exponentially as the size of a system increases.
Innoslate solves both of these problems by having the requirements and modeling all done in the same tool. As requirements are updated modelers can keep updated with changes, finding out who changed it and what the rationale was for the change. They can then see what model elements are linked to that requirement and if there is any effect of a requirement change on the system. This isn’t just a one-way street though, modelers can help refine requirements by running simulations and linking the resulted data back to a requirement update.
Linking Your Requirements
Innoslate has three relations to link requirements to the rest of the model: traced to (the most common), satisfied by, and verified by. Each of these relations has a different meaning and use:
- traced to is a general all purpose relation. This is a good way to easily show linkages between a requirement and a given model element without implying any overall meaning.
- satisfied by shows what model element fulfills a given requirement. This relation is my go to when I have model elements that that show the implementation of a given requirement. (i.e. a requirement referencing response time would have this relationship to an Action entity showing the response time).
- verified by links entities to a requirement that support the requirement. I will often use this for showing the verification process of a requirement. Having this as a separate relation reduces the overhead into doing verification and validation.
To do the linkages between a requirement and a model element navigate to a requirement entity view.
You can find traced to on the Popular tab, satisfied by and verified by can be found on the All tab. Click on the “Add button” and use the search to find the model element to add the relationship to.
Use the check box to select the desired model element and then click the green “Add” button.
Visualizing The Linkages
As the model grows finding and managing entities that are related to one another becomes more difficult. This is especially true when you need to verify that every requirement is satisfied by at least one model element or need to see if a requirement change will affect your ability to meet another requirement. Within Innoslate there are two diagrams that help visualize these linkages between requirements and model elements: Spider Diagram and Requirement Diagram.
The spider diagram shows entities and the relationships between the entities. Each box on the diagram is an individual entity with the lines connecting them being the relationships. The relationships are color coded to aid in readability. I use this diagram starting from a requirement, to visualize its relationships to other model entities and their relationships back to requirements. This gives me a good overview of how a single model element could satisfy multiple requirements.
The requirement diagram from SysML will show a hierarchy of requirements and the relationships to model elements. This is a good way to verify that every requirement has been related to a model entity.
Reports Showing the Linkages
The final part of linking requirements to models is the ability to generate reports that show that linkage. Innoslate has a few reports that are specifically designed to show this linkage: RTM, RSM, RVM, and RVTM.
RTM, RSM, RVM, and RVTM Reports
These reports are found in Requirements View and can be accessed under the Report button, then selecting the desired report.
Each report will show a different relationship to the model. Below is an overview of the four.
RTM (Requirements Traceability Matrix) will show requirements and model entities that are related via the traced to relation.
RSM (Requirements Satisfied Matrix) will show requirements and model entities that are related via the satisfied by relation.
RVM (Requirements Verification Matrix) will show requirements and model entities that are related via the verified by relation.
RVTM (Requirements Verification Traceability Matrix) will show requirements and model entities that are related via the verified by or traced to relations.
To generate a report that contains all of the matrices you can select the “All Matrices Output” from the report dropdown selector.
Topics: How to Use Innoslate Series