With Innoslate you can start anywhere in the lifecycle. We have customers that start with modeling the current system and from that develop requirements for the future system. But the first place most users start is importing documents. Innoslate’s Import Analyzer tool is very robust and powerful. It was one of the first tools to automatically create parent/child relationships from an imported document. It’s also the only MBSE tool to use NLP technology to analyze for quality. But as systems engineers we still need to analyze the documents and not fall for the old “garbage in, garbage out” predicament. The best way you can do this is realizing the importance of hierarchies.
User error happens. The user error we see the most is uploading too many requirements in one document and disregarding the parent/child relationships capability in the Import Analyzer. We’ve had customers try to import a single document with well over 10,000 entities. The Import Analyzer is designed to import well-structured requirements documents. But please remember, the Import Analyzer picks up the parent/child relationships by the enumeration schema you assign the requirements. So using enumeration like 1 and 1.1, will make setting up your hierarchies in Innoslate much easier.
Are you experiencing a slow load time when you import your documents? If so, we highly suggest breaking down these documents even further. As hierarchical decomposition is absolutely essential in Innoslate, you can create a hierarchy of any class of information in Innoslate (artifacts included). A document with multiple sections but many requirements in one level should be broken into even more sections so that the data is usable in Innoslate. Innoslate also has a feature called cross-project collaboration to help you break that information down even further. Without breaking a document up into even just basic hierarchies/sections, you’ll lose out on the power of Innoslate.
Innoslate has a powerful importer, but it can break the document if used incorrectly. For example, the CSV importer is very literal and should be used delicately. As the mapping functionality in the CSV Importer brings in a lot of possibilities. Therefore, we highly suggest taking this one level at a time, especially if you are new to the tool and getting used to its functionality.
We also suggest starting with a new project from scratch. Sometimes users try to use an already existing project and then import information as well. This can cause lots of entities to create unintended hierarchy loops and makes Innoslate unable to create a hierarchy chart for the requirements (The use of Global IDs in Innoslate will be your best tip here, more on this in a later blog in the series). However, it’s best to start with a clean Innoslate project when you are starting something different and starting a new tool like Innoslate.
Another great tip is to have one parent and many children. As you think about the architecture of your documents, look at the LML Guide to give you the basic ontology behind Innoslate. Then you can look at the attributes dictated by your particular project that you need to include in Innoslate. These can be added into the Schema Editor of Innoslate. Between these steps, this will get you on the right first step into building your first project in Innoslate.
These suggestions will help you import your documents more efficiently, prevent the “garbage in, garbage out” issue, and avoid redundant information. If you have questions before starting your project, feel free to take advantage of all your resources. Your account manager, the free support call/email service, the documentation, and the webinars are all here to help you. Don’t be a stranger, we can’t wait to help you on your next project!