Innoslate’s Import Analyzer is a fast and powerful way to get started with Innoslate. As new users come across Innoslate they naturally want to dig right into their current project and bring their data into Innoslate. Although we suggest you start a new project from scratch as a new user, we are happy to help you get started with using your current project’s data. However, with the Import Analyzer’s ability to import six different file types (the .inno and .xml tab in the Import Analyzer are for Innoslate’s own files to import), it is very important to consider some things to make sure this mundane task of importing a file into another software, doesn’t start you off on the wrong foot in Innoslate.
First, users will usually start by signing up at cloud.innoslate.com/signup and start as trial users on Innoslate Cloud. The first thing to note about this, is that as a trial user you are limited to 200 entities in a project. So before importing your project’s data into Innoslate, it is important to make sure to use a small sample of that data, especially as a trial user on Innoslate Cloud. A document with a small sample of statements and requirements to work with in Innoslate will quickly help you realize the overall power of the tool. As noted in the first blog of this series, The Importance of Hierarchies in Innoslate, we highly suggest you look at the basic ontology behind Innoslate (Lifecycle Modeling Language, i.e., LML) to help you start and get familiar with the framework and schema of your project in our tool.
Within Innoslate, there is a powerful functionality of the Import Analyzer for .DOCX and .CSV files where it can distinguish between statements and requirements with just a few clicks the user needs to know. Per LML, a statement is a piece of contextual information that is NOT a requirement and is usually referenced by an Artifact (Artifact is the LML class for document, or other source of information like a file type). In LML, Requirement is a child class of Statement (when you go through your document knowing this piece of knowledge, you’ll automatically start distinguishing these two classes of information in your head, it’s really neat). This is important to note, because in order for the tool to know that it is importing these different classes of information, you must designate this every time you import a document.
So now that we know this, how do we apply it? Right now, you’ll see that the Import Analyzer auto defaults to the Requirements class, however, to distinguish between the classes you must change this dropdown to Statements and then check the box right below that where it reads “Set entity to specific class when description contains a certain word or phrase.” When you click this option in the Import Analyzer, a new dropdown will pop up that will allow you to differentiate another class of information. In this specific case, you’ll choose Requirements. From here, you can add and eliminate the certain words and/or phrases (phrases are literal and must read sequentially as is in the document) that you’d like the Import Analyzer to pick up as that second class of information. The analyzer will then know to pick up Requirements vs. Statements by those certain words and/or phrases in that third field (feel free to take out the auto generated “shall”, “will”, “must” if those aren’t applicable to you by clicking on the small blue “X”).
Do you have an alphanumeric schema for your parent child relationships? Then the “Plain Text” tab in the Import Analyzer is your friend in this situation. Note, you can’t distinguish between two different classes with this importer, however, you can establish a numbering schema of mixed letters and numbers with an outline format already made, or you can customize your own format here (this is a little more advanced, if you’re not familiar with this, please reach out to Innoslate Support, they’ll be happy to help).
These tips & tricks may seem trivial, especially if you saw this in a demo or have already begun studying LML and/or Innoslate. But if you are a new user and haven’t been able to read through the LML Guide or talk to us, this will automatically start putting you in the right mindset on how Innoslate looks at your data and will help you get familiar with the ontology behind the tool a little faster (TIP: another way of looking into the ontology behind Innoslate, is built right into the tool with the Schema Editor where you can start looking at the classes their attributes and relationships). Because essentially in Innoslate when you import a document, in LML speak, you are telling Innoslate’s Import Analyzer to “import this artifact and have it reference these statements and requirements into the project’s database.” With the proper parent/child numbering schema in this same import, in LML speak, you are also telling it “this requirement is decomposed by these children and these children requirements decompose this parent requirement (all the italicized words reference LML words).” This is a pretty powerful statement and action to make with a mundane task like importing a document into another software (LML puns intended)!
When you follow these tips for the Import Analyzer, distinguish your statements and requirements, and also make hierarchies with your enumeration, you’ll be building your project’s database of requirements, statements, and artifacts in hierarchies within minutes. Before you know it, you’ll be managing your requirements and checking your Requirement’s attributes with our NLP Quality Check feature in Innoslate in no time!