Requirements Management and Analysis

Last modified on September 13th, 2018.


Welcome to the Requirements Management and Analysis guide!

This guide is meant to demonstrate how to use Innoslate for requirements management and analysis. If you haven't already, we recommend reading our Innoslate 101 guide before proceeding.

As you know, system requirements are the backbone of systems engineering and are essential in every organization. Your goal is to improve and maintain quality, mitigate risks, lower cost, and reduce time to market, all while keeping aligned with your customers' requirements. As products and systems become more complex, your goals become more challenging. Innoslate makes it simpler than ever before to have full lifecycle traceability for your requirements. Capture, analyze, and manage all of your requirements all in one place. Innoslate's web browser user interface makes it easy for your team to collaborate in real-time, tracking all of the requirements throughout the product/system lifecycle.

Photo: Google

To show you how to use Innoslate with a realistic example, we will use an "Autonomous Vehicle" sample problem. SAE International defines six levels of driving automation, which span from no automation (Level 0) to full automation (Level 5). Level 5 automation is a complex and current problem faced by the entire automotive industry. For our originating requirements, we will utilize artifacts derived from the SAE International Level 5 standards.

Capture Standards

The first step is to capture your requirements in Innoslate. You might derive your requirements from any of the following: customer needs statement, lessons learned, policies and procedures, laws, standards, etc. To see this in action, let's start with importing a requirements document to derive new requirements.

  1. Create a new Innoslate project with the name "Lesson – Autonomous Vehicle." For detailed instructions on creating a project, see our Creating Projects documentation.
  2. Download our example "SAE Automation Sample Requirements" spreadsheet by clicking here.
  3. Open the 'MENU' drop-down located on the top navigation bar and click the 'Import Analyzer' menu item in the “Tools” section.
  4. Follow our Importing Microsoft Excel (csv) Files documentation to import our example "SAE Automation Sample Requirements" spreadsheet into Innoslate.

'Import Analyzer' "analyzes" the document's overall structure and will import all of the statements and requirements right into your project. A Statement entity specifies text while a Requirement entity identifies what a system must do to have value and utility to the end user.

You've now successfully imported a requirements document. You will notice that every requirement has a unique number. Innoslate requires all requirements to have a unique number (ex. 1.1.1 or SPEC.1.1) within 'Documents View.'

Baseline Requirements

Now that your originating requirements are imported, you can preserve the original document through baselining. A baseline is a read-only snapshot of the document that is preserved until the document is deleted. To do this:

  1. Within your Requirements Document in 'Documents View,' click the 'Baseline' button located on the toolbar.
  2. Provide a name for the baseline, ex. "Original Document."
  3. Click the 'Create' button.

Once the new baseline has been created, the only visual cue that this happened will be a color change from yellow to blue of the baseline indicator (the left-most block of color on every row in 'Requirements View'). While the baseline indicator remains blue it indicates the statement or requirement has not changed since the last baseline. If the baseline indicator is yellow it means the statement or requirement has been changed since the last baseline or has never been baselined.

It’s a good practice to create baselines every once in awhile, to help track the changes your team has made throughout the project. To go back and review an existing document baseline, follow the steps outlined in our Reviewing an Existing Document Baseline documentation.

Analyze Requirements

We have successfully imported our originating requirements, but how do we know their quality? Unique to Innoslate, the "Quality Check" feature of 'Documents View' uses natural language processing to parse requirements and analyze the text to understand the grammar and structure.

Innoslate provides the following quality indicator attributes built into the default database schema of the Requirement class:

Attribute Description Automated?
Clear Explicit and not confusing to readers. Yes
Complete Expresses a whole, single idea, and not portions of one or many. Yes
Consistent Does not conflict with other requirements. Yes
Correct Describes the user’s intent and legally possible. No
Design Does not impose a specific solution (“what” not “how”).  Yes
Feasible Implementable with existing or projected technology and within cost and schedule. No
Traceable Uniquely identifiable and able to be tracked to predecessor and successor lifecycle entities. Yes
Verifiable Proves within realistic cost and schedule that the architecture meets the requirement. Yes

Since Innoslate cannot verify correctness (legality) and feasibility automatically, you, the user, will have to perform analysis on the Correct and Feasible attributes manually.

To run a "Quality Check" against all the entities in your document, click the 'Quality Check' button on the toolbar. It will take a few seconds to run. When it's done, you will see your score in the "Quality Score" column. Remember, only six of the eight attributes can be checked automatically, for a maximum automatic score of 75 percent. The results of the analysis appear below.

After the "Quality Check" has completed the analysis, you need to verify the results and address issues. Click on any Requirement (not a Statement) entity. Next, choose the middle tab labeled 'More Attributes' on the left sidebar. This tab shows additional attributes not already shown in a column in 'Documents View,' including the quality indicator attributes and the issues identified by the "Quality Check."

Continue to click through all the requirements and you will find that the following issues have been identified:

Tip: If you do not agree with issues the "Quality Check" identified or its suggestions for improvement, you can always manually change any of the quality indicator attributes to "Yes."

After you have cleaned up your document, re-run the "Quality Check." Since your requirements have been re-analyzed, you should baseline your document again. The document should appear similar to the picture below:

Now that you have a well written requirements document, let's continue to the next section.

Managing Requirements

The "SAE Level 5 Automation Requirements" sample document currently contains only ten requirements; however, over time, this project may contain hundreds or thousands of requirements. Organizing your requirements is essential to developing models at scale.

Often requirements documents will contain a combination of different types of requirements (ex. Functional Requirements, Performance Requirements). Innoslate uses labels to aid in the organizational structure of models. Unlike with a folder system, a single model element can have multiple labels (whereas a single model element cannot be in multiple folders).

Formatting Requirements

Click on any requirement or statement. This will open it up and make the text editable. You can add, delete, cut, copy, and paste text. On the rich text editor's toolbar, the third feature is the 'Insert' drop-down. Click to open the 'Insert' drop-down and you will see the options to insert links, images, diagrams, tables, and horizontal rules. Innoslate actually allows you to insert diagrams straight into a document. As you make changes to the diagram in Innoslate, those changes will be reflected in the document as well.

Additional formatting options include: undo, redo, bold, italic, underline, strikethrough, superscript, subscript, align, bulleted list, numbered list, list indentions, text color, and highlight color.

Click on the green check mark when you are finished formatting.

Tip: Want to change the prefix or fix document numbers? For detailed instructions, see our Automatically Re-Numbering All Document Entities documentation.

Visualizing Requirements

As you may recall from Innoslate 101, a relational model is underlying Innoslate, which allows for auto-generation of diagrams. To try this out, use the 'Tree Diagram' to review the structure of our requirements document. Follow these instructions to navigate to the 'Tree Diagram:'

  1. Within 'Documents View,' click on the 'Open' drop-down located on the toolbar.

  2. Under the "General Diagrams" section, select the 'Tree Diagram.'

  3. The 'Tree Diagram' displays the entire document hierarchy to show traceability within the document. By default, the first three levels of decomposition are displayed. On documents with more than three levels of decomposition, the third level of tree nodes will be shaded indicating they can be clicked to expand subsequent levels.

    The left sidebar has three tabs: 'New,' 'Existing,' and 'Comment.' In the 'New' tab, you can drag and drop statements and requirements anywhere on the diagram in the right panel. This allows you to add new statements and requirements right into the requirements document. The 'Existing' tab allows you to add existing statements and requirements. Existing requirements can be dragged and moved to different places in the hierarchy. You can search for the existing entity, then drag and drop it over to the diagram. Click on 'Comment,' then go ahead and leave a comment for your team to see.

    To easily visualize traceability, we recommend using the 'Spider Diagram.' Follow these steps to navigate to the 'Spider Diagram:'

    1. Within the 'Tree Diagram,' click on the 'Open' drop-down located on the toolbar.

    2. Under the "LML Diagrams" section, select the 'Spider Diagram' menu item.

    The 'Spider Diagram' is a type of hierarchical organizational chart used in Innoslate as a means of visualizing traceability. This diagram is capable of displaying up to nine levels of decomposition of entities arranged in concentric circles radiating outwards from the center.

    Further Reading

    Now that your originating requirements document is complete and you have visualized the underlying model of the document, we encourage you to create your first system models by following along in our next guide: Model-Based Systems Engineering.

    Note: If you are not interested in model-based systems engineering at this time, you can continue straight to the Verification and Validation guide.

Requirements Management and Analysis

Last modified on September 13th, 2018. 


Welcome to the Requirements Management and Analysis guide!

This guide is meant to demonstrate how to use Innoslate for requirements management and analysis. If you haven’t already, we recommend reading our Innoslate 101 guide before proceeding.

As you know, system requirements are the backbone of systems engineering and are essential in every organization. Your goal is to improve and maintain quality, mitigate risks, lower cost, and reduce time to market, all while keeping aligned with your customers’ requirements. As products and systems become more complex, your goals become more challenging. Innoslate makes it simpler than ever before to have full lifecycle traceability for your requirements. Capture, analyze, and manage all of your requirements all in one place. Innoslate’s web browser user interface makes it easy for your team to collaborate in real-time, tracking all of the requirements throughout the product/system lifecycle.

Photo: Google

To show you how to use Innoslate with a realistic example, we will use an “Autonomous Vehicle” sample problem. SAE International defines six levels of driving automation, which span from no automation (Level 0) to full automation (Level 5). Level 5 automation is a complex and current problem faced by the entire automotive industry. For our originating requirements, we will utilize artifacts derived from the SAE International Level 5 standards.

Capture Standards

The first step is to capture your requirements in Innoslate. You might derive your requirements from any of the following: customer needs statement, lessons learned, policies and procedures, laws, standards, etc. To see this in action, let’s start with importing a requirements document to derive new requirements.

  1. Create a new Innoslate project with the name “Lesson – Autonomous Vehicle.” For detailed instructions on creating a project, see our Creating Projects documentation.
  2. Download our example “SAE Automation Sample Requirements” spreadsheet by clicking here.
  3. Open the ‘MENU’ drop-down located on the top navigation bar and click the ‘Import Analyzer’ menu item in the “Tools” section.
  4. Follow our Importing Microsoft Excel (csv) Files documentation to import our example “SAE Automation Sample Requirements” spreadsheet into Innoslate.

‘Import Analyzer’ “analyzes” the document’s overall structure and will import all of the statements and requirements right into your project. A Statement entity specifies text while a Requirement entity identifies what a system must do to have value and utility to the end user.

You’ve now successfully imported a requirements document. You will notice that every requirement has a unique number. Innoslate requires all requirements to have a unique number (ex. 1.1.1 or SPEC.1.1) within ‘Documents View.’

Baseline Requirements

Now that your originating requirements are imported, you can preserve the original document through baselining. A baseline is a read-only snapshot of the document that is preserved until the document is deleted. To do this:

  1. Within your Requirements Document in ‘Documents View,’ click the ‘Baseline’ button located on the toolbar.
  2. Provide a name for the baseline, ex. “Original Document.”
  3. Click the ‘Create’ button.

Once the new baseline has been created, the only visual cue that this happened will be a color change from yellow to blue of the baseline indicator (the left-most block of color on every row in ‘Requirements View’). While the baseline indicator remains blue it indicates the statement or requirement has not changed since the last baseline. If the baseline indicator is yellow it means the statement or requirement has been changed since the last baseline or has never been baselined.

It’s a good practice to create baselines every once in awhile, to help track the changes your team has made throughout the project. To go back and review an existing document baseline, follow the steps outlined in our Reviewing an Existing Document Baseline documentation.

Analyze Requirements

We have successfully imported our originating requirements, but how do we know their quality? Unique to Innoslate, the “Quality Check” feature of ‘Documents View’ uses natural language processing to parse requirements and analyze the text to understand the grammar and structure.

Innoslate provides the following quality indicator attributes built into the default database schema of the Requirement class:

Attribute Description Automated?
Clear Explicit and not confusing to readers. Yes
Complete Expresses a whole, single idea, and not portions of one or many. Yes
Consistent Does not conflict with other requirements. Yes
Correct Describes the user’s intent and legally possible. No
Design Does not impose a specific solution (“what” not “how”).  Yes
Feasible Implementable with existing or projected technology and within cost and schedule. No
Traceable Uniquely identifiable and able to be tracked to predecessor and successor lifecycle entities. Yes
Verifiable Proves within realistic cost and schedule that the architecture meets the requirement. Yes

Since Innoslate cannot verify correctness (legality) and feasibility automatically, you, the user, will have to perform analysis on the Correct and Feasible attributes manually.

To run a “Quality Check” against all the entities in your document, click the ‘Quality Check’ button on the toolbar. It will take a few seconds to run. When it’s done, you will see your score in the “Quality Score” column. Remember, only six of the eight attributes can be checked automatically, for a maximum automatic score of 75 percent. The results of the analysis appear below.

After the “Quality Check” has completed the analysis, you need to verify the results and address issues. Click on any Requirement (not a Statement) entity. Next, choose the middle tab labeled ‘More Attributes’ on the left sidebar. This tab shows additional attributes not already shown in a column in ‘Documents View,’ including the quality indicator attributes and the issues identified by the “Quality Check.”

Continue to click through all the requirements and you will find that the following issues have been identified:

  • Ambiguous Words: Ambiguous words were identified in requirements 4.2 and 4.3. You can find this suggestion under the Verifiable attribute in the left sidebar. You will want to replace “high speed” (> 55 mph) and “low speed” (< 40 mph) with absolute values.
  • Listed Terms: Requirement 3 contains multiple requirements. These requirements should be split into three children requirements. To do this:
    1. Select requirement number “3. Fallback Performance of Dynamic Driving Task.”
    2. Click on the ‘Add Child’ button located on the toolbar.
    3. Name the child requirement “Change Lanes” and type in “The driver assistance system shall determine when to change lanes.” as the description.
    4. Repeat the previous steps to add two more child requirements: “Determine Turns” (description: “The driver assistance system shall determine when to turn.”) and use “Use Signals” (description: “The driver assistance system shall determine when to use signals.”).
    5. Remove the text from the description in “3. Fallback Performance of Dynamic Driving Task.”
    6. Since “3. Fallback Performance of Dynamic Driving Task” is no longer a requirement, transform the Requirement to a Statement.
      1. Select “3. Fallback Performance.”
      2. Click on the ‘More’ drop-down on the toolbar.
      3. Click the ‘Transform to’ menu item.
      4. Select the ‘Statement’ menu item.

Tip: If you do not agree with issues the “Quality Check” identified or its suggestions for improvement, you can always manually change any of the quality indicator attributes to “Yes.”

After you have cleaned up your document, re-run the “Quality Check.” Since your requirements have been re-analyzed, you should baseline your document again. The document should appear similar to the picture below:

Now that you have a well written requirements document, let’s continue to the next section.

Managing Requirements

The “SAE Level 5 Automation Requirements” sample document currently contains only ten requirements; however, over time, this project may contain hundreds or thousands of requirements. Organizing your requirements is essential to developing models at scale.

Often requirements documents will contain a combination of different types of requirements (ex. Functional Requirements, Performance Requirements). Innoslate uses labels to aid in the organizational structure of models. Unlike with a folder system, a single model element can have multiple labels (whereas a single model element cannot be in multiple folders).

  • Add labels in bulk via ‘Database View’

    1. Click on the ‘Database’ button on the top navigation bar.

    2. In ‘Database View,’ filter the view to only display Requirement entities by clicking ‘Requirement’ in the “Classes” section of the left sidebar.

    3. Click the ‘Select All’ checkbox in the table header to select all of the ‘Requirement’ entities.

    4. Click the ‘Bulk Label’ drop-down.

    5. Select the ‘Functional Requirement’ label.

    6. You will now see that all of your selected ‘Requirement’ entities have acquired the Label of ‘Functional Requirement.’

  • Add labels via ‘Documents View’

    1. Click the ‘Documents’ button on the top navigation bar to return to ‘Documents View.’

    2. Select the “SAE Level 5 Automation Requirements” sample document.

    3. Select requirement number 4.2 named “High Speed Cruising.”

    4. From the left sidebar under Metadata, in the Labels section, click ‘Performance Requirement.’

    5. Click the green check-mark button to save the requirement.

    6. Repeat these steps for “4.3 Low Speed Traffic Jams.”
    7. You will now see that these ‘Requirement’ entities have acquire the Label of ‘Performance Requirement.’

  • Filter your requirements

    In ‘Documents View,’ under the ‘Filter’ tab of the left sidebar, click ‘Performance Requirement.’ This will filter our document to display only Requirement entities with the Performance Requirement label.

    Click ‘Clear Label Filter’ to clear the label filter and return to your normal view.

  • Customize your Attributes

    Innoslate allows you to customize the attributes that you want to see in the columns in ‘Documents View.’ By default, the following three columns will be shown: “Rationale,” “Quality Score,” and “Labels.” Click to open the ‘Wrench’ drop-down located on the toolbar icon and select the ‘Settings’ menu item.

    Here you can change which columns are displayed.

Formatting Requirements

Click on any requirement or statement. This will open it up and make the text editable. You can add, delete, cut, copy, and paste text. On the rich text editor’s toolbar, the third feature is the ‘Insert’ drop-down. Click to open the ‘Insert’ drop-down and you will see the options to insert links, images, diagrams, tables, and horizontal rules. Innoslate actually allows you to insert diagrams straight into a document. As you make changes to the diagram in Innoslate, those changes will be reflected in the document as well.

Additional formatting options include: undo, redo, bold, italic, underline, strikethrough, superscript, subscript, align, bulleted list, numbered list, list indentions, text color, and highlight color.

Click on the green check mark when you are finished formatting.

Tip: Want to change the prefix or fix document numbers? For detailed instructions, see our Automatically Re-Numbering All Document Entities documentation.

Visualizing Requirements

As you may recall from Innoslate 101, a relational model is underlying Innoslate, which allows for auto-generation of diagrams. To try this out, use the ‘Tree Diagram‘ to review the structure of our requirements document. Follow these instructions to navigate to the ‘Tree Diagram:’

  1. Within ‘Documents View,’ click on the ‘Open’ drop-down located on the toolbar.

  2. Under the “General Diagrams” section, select the ‘Tree Diagram.’

  3. The ‘Tree Diagram’ displays the entire document hierarchy to show traceability within the document. By default, the first three levels of decomposition are displayed. On documents with more than three levels of decomposition, the third level of tree nodes will be shaded indicating they can be clicked to expand subsequent levels.

    The left sidebar has three tabs: ‘New,’ ‘Existing,’ and ‘Comment.’ In the ‘New’ tab, you can drag and drop statements and requirements anywhere on the diagram in the right panel. This allows you to add new statements and requirements right into the requirements document. The ‘Existing’ tab allows you to add existing statements and requirements. Existing requirements can be dragged and moved to different places in the hierarchy. You can search for the existing entity, then drag and drop it over to the diagram. Click on ‘Comment,’ then go ahead and leave a comment for your team to see.

    To easily visualize traceability, we recommend using the ‘Spider Diagram.’ Follow these steps to navigate to the ‘Spider Diagram:’

    1. Within the ‘Tree Diagram,’ click on the ‘Open’ drop-down located on the toolbar.

    2. Under the “LML Diagrams” section, select the ‘Spider Diagram’ menu item.

    The ‘Spider Diagram’ is a type of hierarchical organizational chart used in Innoslate as a means of visualizing traceability. This diagram is capable of displaying up to nine levels of decomposition of entities arranged in concentric circles radiating outwards from the center.

    Further Reading

    Now that your originating requirements document is complete and you have visualized the underlying model of the document, we encourage you to create your first system models by following along in our next guide: Model-Based Systems Engineering.

    Note: If you are not interested in model-based systems engineering at this time, you can continue straight to the Verification and Validation guide.