Requirements Management and Analysis

Last modified on February 17th, 2017.


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.

Google Self-driving CarPhoto: 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 Requirements

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, or other such sources. 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.
Capture Requirements

'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 'Requirements 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 'Requirements View', click the 'Baseline' button located on the toolbar.
  2. Provide a name for the baseline, ex. "Original Document".
  3. Click the 'Create' button.
Baseline Requirements

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 'Requirements 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 (6) of the eight (8) attributes can be checked automatically, for a maximum automatic score of 75%. The results of the analysis appear below.

Quality Check Results

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 'Requirements 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 it's 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:

Second Quality Check Results

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

 

Managing Requirements

The "SAE Level 5 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).

To add labels in bulk, let's explore Table mode of 'Database View'.

  1. Click on the 'Database' button on the top navigation bar.
  2. Once in 'Database View', click the 'Table Mode' button located on the toolbar to open table mode.
  3. To filter the view to only display Requirement entities, click 'Requirement' in the "Classes" section of the left sidebar.
  4. Using the horizontal scrollbar on the bottom, scroll to the right until the "Labels" column is visible.
  5. Double click the first cell in the "Labels" column and type in "Functional Requirement".
  6. Deselect the cell.
  7. Single click the first cell again.
  8. Now, similar to Excel, drag the blue square of the highlighted cell down to add the label to all the other requirements.
Capture Requirements

Click the 'Requirements' button on the top navigation bar to return to 'Requirements View'. Here we can also add labels directly within 'Requirements View'. To see this in action:

  1. Select requirement number 4.2 named "High Speed Cruising".
  2. From the left sidebar under Metadata, in the Labels section, click 'Performance Requirement'.
  3. Click the green check-mark button to save the requirement.
  4. Repeat these steps for "4.3 Low Speed Traffic Jams".

Using the left sidebar, we can now filter our requirements. In the 'Filter' tab, click 'Performance Requirement'. This will filter our document to display only Requirement entities with the Performance Requirement label. Click 'Performance Requirement' again to clear the label filter.

Filtered by Label

Innoslate allows you to customize the attributes that you want to see in the columns in 'Requirements 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 to change which columns are displayed. Let's continue to the next section to learn about our requirement formatting options.

 

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 first 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.

Format Requirement

Additional formatting options include: bold, underline, strike-through, superscript, subscript, yellow highlight, red strike-through, alignment, bulleted list, and numbered list.

Click on the green check mark when you are finished.

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 'Document Tree Diagram' to review the structure of our requirements document.  Follow these instructions to navigate to the 'Document Tree Diagram':

  1. Within 'Requirements View',  click on the 'Open' drop-down located on the toolbar.
  2. Under the "General Diagrams" section, select the 'Document Tree Diagram'.

The 'Document Tree Diagram', shown below, 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.

Document Tree Diagram

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 'Document Tree Diagram', click on the 'Open' drop-down located on the toolbar.
  2. Under the "LML Diagrams" section, select the 'Spider Diagram' menu item.

Spider Diagram

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 (9) 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 February 17th, 2017. 


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.

Google Self-driving CarPhoto: 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 Requirements

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, or other such sources. 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.
Capture Requirements

‘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 ‘Requirements 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 ‘Requirements View’, click the ‘Baseline’ button located on the toolbar.
  2. Provide a name for the baseline, ex. “Original Document”.
  3. Click the ‘Create’ button.
Baseline Requirements

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 ‘Requirements 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 (6) of the eight (8) attributes can be checked automatically, for a maximum automatic score of 75%. The results of the analysis appear below.

Quality Check Results

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 ‘Requirements 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. named “Fallback Performance of Dynamic Driving Task”.
    2. Click on the ‘Add Child’ button located on the toolbar.
    3. Type in “The driver assistance system shall determine when to change lanes.” as the description.
    4. Repeat the previous steps for the “turn” and use “signals” requirements.
    5. Remove the text from the description in  “3. Fallback Performance…”.
    6. Since “3. Fallback Performance…” 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 it’s 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:

Second Quality Check Results

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

 

Managing Requirements

The “SAE Level 5 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).

To add labels in bulk, let’s explore Table mode of ‘Database View’.

  1. Click on the ‘Database’ button on the top navigation bar.
  2. Once in ‘Database View’, click the ‘Table Mode’ button located on the toolbar to open table mode.
  3. To filter the view to only display Requirement entities, click ‘Requirement’ in the “Classes” section of the left sidebar.
  4. Using the horizontal scrollbar on the bottom, scroll to the right until the “Labels” column is visible.
  5. Double click the first cell in the “Labels” column and type in “Functional Requirement”.
  6. Deselect the cell.
  7. Single click the first cell again.
  8. Now, similar to Excel, drag the blue square of the highlighted cell down to add the label to all the other requirements.
Capture Requirements

Click the ‘Requirements’ button on the top navigation bar to return to ‘Requirements View’. Here we can also add labels directly within ‘Requirements View’. To see this in action:

  1. Select requirement number 4.2 named “High Speed Cruising”.
  2. From the left sidebar under Metadata, in the Labels section, click ‘Performance Requirement’.
  3. Click the green check-mark button to save the requirement.
  4. Repeat these steps for “4.3 Low Speed Traffic Jams”.

Using the left sidebar, we can now filter our requirements. In the ‘Filter’ tab, click ‘Performance Requirement’. This will filter our document to display only Requirement entities with the Performance Requirement label. Click ‘Performance Requirement’ again to clear the label filter.

Filtered by Label

Innoslate allows you to customize the attributes that you want to see in the columns in ‘Requirements 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 to change which columns are displayed. Let’s continue to the next section to learn about our requirement formatting options.

 

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 first 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.

Format Requirement

Additional formatting options include: bold, underline, strike-through, superscript, subscript, yellow highlight, red strike-through, alignment, bulleted list, and numbered list.

Click on the green check mark when you are finished.

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 ‘Document Tree Diagram’ to review the structure of our requirements document.  Follow these instructions to navigate to the ‘Document Tree Diagram’:

  1. Within ‘Requirements View’,  click on the ‘Open’ drop-down located on the toolbar.
  2. Under the “General Diagrams” section, select the ‘Document Tree Diagram’.

The ‘Document Tree Diagram’, shown below, 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.

Document Tree Diagram

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 ‘Document Tree Diagram’, click on the ‘Open’ drop-down located on the toolbar.
  2. Under the “LML Diagrams” section, select the ‘Spider Diagram’ menu item.

Spider Diagram

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 (9) 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.