Why Use an Integrated Solution for Requirements Management and MBSE?

Systems Engineering and Requirements Management

One of the questions we get most is “Why should we get a tool that does both requirements management and MBSE?” With the growth of SaaS products, we are seeing industries all over using an integrated platform. For example, the crm we use, Hubspot, has taken advantage of the unique capabilities of the SaaS market. Hubspot integrated the entire marketing lifecycle into one place from content management, analytics, email automation, etc. We’ve greatly benefited from using only one tool for all of our marketing efforts. Innoslate provides similar benefits with its integrated platform for the entire product lifecycle including the the process modeling, risk analysis, and testing.

A lot of times, we hear people tell us that they “only do the requirements management or the process modeling part of the lifecycle,” therefore they don’t need an integrated platform. Think about what’s your overall goal when you are capturing, managing, and analyzing requirements? You are certainly not just doing this entire process because you enjoy paperwork. You’re goal in requirements management is to meet the goals and needs of stakeholders to complete a product or process. For instance, to create medical devices, large networks, or develop an autonomous vehicle. Let’s keep using the autonomous vehicle example. You’ve done your research, you have 1000s and 1000s of high quality requirements. The document has a complete layout including roadside infrastructure, vehicle safety, DOT regulations, vehicle communication, etc. You know exactly what you are building. The next step is the how you are going to build it.  Whether or not you are the one that does the ‘how,’ at some point in this system or product both parts will have to be completed. Even if the requirements team is handing the project off to another team for analysis and testing, it’s still best to only use one tool. If you don’t, you’ll wind up spending a long time transfering and organizing data. Unfortunately, you’ll probably lose some data in that process, which will result in not having full traceability. With a tool like Innoslate you can develop requirements then create the process of how you will build it.


Long story short…There are a lot of reasons you should integrate requirements management with model-based systems engineering.


Here’s seven to start with.


Saves the entire company time

This is especially true for large organizations. Software tools require training and management. If you have two different tools, you have to do double the training. IT has to spend time managing both tools. It’s even worse if you are putting the software on a server, then IT have to manage two servers. If you want api integration between software, they are probably the ones that have to set that up too. You and your team will lose weeks of time importing and exporting data between tools.  

Saves money

One tool costs much less than two. Innoslate costs much less than most requirements management tools and mbse tools. It’s certainly less than having to buy both. You also don’t have to pay for any additional plugins to make the tools work with each other.


Time is money. You are going to save a lot of money by not wasting employee’s time importing all that data into another tool or having IT manage two servers and force integration.


Keeps your data all in one place

Besides saving lots of time and stress, keeping your data in one place also reduces risk. You can easily lose data (and not even realize it) during the import/export process. Every tool has a different underlying schema, which can make it extremely challenging to import all the data exactly as the requirements manager intended. This can result in a loss of traceability and make the requirements manager look bad. With using one tool you can easily trace requirements, actions, documents, test processes and more to each other. Innoslate allows you to create relationships from almost anywhere making it simple to create full traceability through the entire project.



Many times requirements managers and engineers struggle to communicate. We just pass our requirements onto the engineers to let them do the next steps. No one wants this to occur. We want both sides to effectively communicate, so they can create a lessons learned. Using two different tools just makes this entire process harder. Innoslate provides version control, chat, comment, and more to make collaborating with diverse teams easy. So next time the engineers want to give the requirements team feedback, they can use the same Innoslate project.


Document the Requirements Management Process

What better way to create a requirements management process then to use the advanced built-in models in a MBSE tool? In Innoslate you can model the entire requirements management process. From there you can trace back each action to the requirements or any document. You can also use the collaboration features to make the process a workflow. This way team members will receive email notifications when it’s their turn to do the next step or when something has been approved.


Develop requirements from models

If you use a tool that integrates both requirements management and MBSE, you can actually develop low level requirements from the models. The beauty in creating requirements from models is it allows you to analyze the current process and the future process and from that you can understand what you need. This is especially great if you are starting a requirements document from scratch. Innoslate has a built-in feature that automatically creates requirements documents directly from your models. Here’s a great article that shows you how: “Developing Requirements from Models – How and Why?”


Gain Valuable Insight

Applying MBSE to requirements management gives you valuable insight you wouldn’t be able to have otherwise. Creating executable models allows you to use the monte carlo simulator, so that you can calculate the variance in cost, time, and resources.Without even leaving the program you can trace back to the requirements document to see if the proposed process meets the specified cost, time, and resources specified in the requirements.


Save your organization a whole lot of time, money, and stress by using an integrated solution for a project’s lifecycle. Having the requirements management, modeling, and testing all in one easy to access place will make everyone’s life easier. If you would like to try an integrated requirements management and MBSE solution, sign up for Innoslate at innoslate.com/sign-up.

Developing Requirements from Models – Why and How

One of the benefits of having an integrated solution for requirements management and model-based systems engineering is you can easily develop requirements from models. This is becoming an increasingly used practice in the systems engineering community. Often times as requirements managers we are given the task of updating or developing an entirely new product or system. A a great place to start in this situation is to create two models a current model and a future (proposed) model. This way you can predict where the problems are in the current systems and develop requirements from there. Innoslate has an easy way to automatically generate requirements documents from models. Below we’ll take a well known example from the aerospace industry, The FireSAT model,  to show you how you can do this.

The diagram below shows the top level of the wildfire detection and alerting system. Fires are detected and then alerts are sent. Each of these steps are then decomposed in more detail. The decomposition can be continued until most aspects of the problem and mechanisms for detection and alerting have been identified. If timing and resources are added, this model can predict where the problems are in the current system. This model can show you that most fires are detected too late to be put out before consuming large areas of forests and surrounding populated areas.

One system proposed to solve this is a dedicated satellite constellation (FireSAT ) that would detect wildfires early and alert crews for putting them out. The same system could also aid in monitoring on-going wildfires and aid in the fire suppression and property damage analysis. Such a system could even provide this service worldwide. The proposed system for the design reference mission is shown below.

The “Perform Normal Ops” is the only one decomposed, as that was the primary area of interest for this mission, which would be a short-term demonstration of the capability. Let’s decompose this step further.

Now we have a decomposition of the fire model, warning system, and response.. The fire model and response were included to provide information about the effectiveness of such a capability. The other step provides the functionality required to perform the primary element of alerting. This element is essentially the communications subsystem of the satellite system (which includes requirements for ground systems as well as space systems).

Innoslate allows you to quickly obtain a requirements document for that subsystem. The document, in the Requirements View looks like the picture below.

This model is just for a quick example, but you can see that it contains several functional requirements. This document, once the model is complete, can then provide the basis for the Communications Subsystem Requirements.


If you’d like to see another example of how to do this, watch our Generating Requirements video for the autonomous vehicle example.

Ford vs. Mazda Transmissions: Why Does Quality Matter?

In the 1980’s Ford owned roughly 25% of Mazda (then known as Toyo Koygo). Ford had Mazda manufacture some automatic transmissions for cars sold in the United States. Both Ford and Mazda were building the same transmission off of the same specification and both had 100% specification conformance. However, the Ford transmissions were receiving more customer complaints about noise and were having higher warranty repair costs. This led Ford engineers to investigate and they found that the Ford manufactured transmissions utilized 70% of the available tolerance spread for manufactured parts, while Mazda used only 27% (AC 2012-4265: Promoting Awareness in Manufacturing Students of Key Concepts of Lean Design to Improve Manufacturing Quality). The Ford engineers began to realize that the Mazda transmissions were higher quality than the Ford manufactured ones. It turned out that Mazda was using a slightly more expensive grinding process than what Ford was using. This raised Mazda’s manufacturing costs, however the full lifetime costs were higher for the Ford manufactured transmissions.

This story is a prime example of why it is important to think about quality. Too often we tend to focus on other metrics and neglect quality, or we use a single metric to define quality. Ford experienced this by focusing on a “Zero Defect” policy, thinking that if there were zero defect in a transmission that would produce a quality transmission. Mazda expanded on this policy and took the whole lifecycle cost and experience into consideration as they developed their transmissions. With this holistic view, it is easy to see why engineers need to think about quality all across a program’s lifecycle.

Building Quality into The Lifecycle

If the goal of an organization is to deliver a quality product, engineers at all stages need to think about how they can add quality into the system. An easy way to think about how to add quality, is ask yourself: “What are the extra details, the extra effort, the extra care that can be put into the product?” When these extra efforts are applied to a properly defined system, the output is often a quality system. To a program manager all the extra effort sounds like a fair amount of extra cost. This is true, however it is important to weigh the short term cost increase against the potential long term costs savings. Below are two examples of how to add quality in the lifecycle.


One of the first steps of the design effort is requirement building and unfortunately having a requirement like “system shall be of a quality design” does not cut it. Never mind that this requirement violates nearly all the good requirement rules, it fails to take into account the characteristics of a quality system. Is it the “spare no expense” engineering efforts of high end audio systems or is it the good quality for the price factor of Japanese manufactured cars in the 1970s? It is important to identify how the customer and market defines quality. Having this understanding informs choices going forward and prevents a scenario where the market doesn’t value the added quality efforts.


The procurement/manufacturing phase of the lifecycle is where quality efforts are the most visible. As parts are being ordered it is important to be thinking about how the whole supply chain thinks about quality. This involves reviewing the supplier’s suppliers to verify that the parts being delivered do not have a poor design or a possible defect that could be hidden through integration. For internally manufactured parts, is extra effort being added to check that the solder on pins is clean and will not short other sections under heating? Extra thought and care should be given to the human interface of the system, as this normally plays a major role in determining the quality of a system. For software, do user interfaces make sense, do they flow, are they visually appealing? These are the kinds of questions that should be asked to help guild engineers to building a quality system.

 “Quality Is Our Top Priority”

All too often I find a Scott Adams’ Dilbert comic strip that highlights a common problem that engineers face. In the comic below we have a perfect example of Pointy-Haired Boss directing Dilbert, Alice, and Wally to focus on quality.


DILBERT from Sunday March 28, 2004


What Pointy-Haired Boss fails to realize is that quality and the rest of his priorities are not mutually exclusive and can be done concurrently. A quality system is one that is safe, that is law abiding, and is financially viable. Quality should also be added to these factors, making sure that the extra bit of design work is worthwhile. All of these factors when properly combined together with good design and engineering produce a quality system.

By Daniel Hettema. Reposted from the SPEC Innovations’ blog with permission.

Move Past Spreadsheets with Modern Requirements Management

Are you still using Microsoft Office to capture, manage, analyze, and trace all your requirements? Products and systems increase in complexity every day. You need a requirements management tool that can properly handle large complex projects.

When you use spreadsheets for requirements management you increase your time to market Even worse not using a modern requirements management solution can result in a higher risk of product failure.  A CIO report found that “as many as 71 percent of software projects that fail do so because of poor requirements management.”  Poor requirements management occurs when teams use antiquated RM tools that do not have the needed traceability, collaboration, and quality analysis features.

Traceability needs to happen through the entire process. It’s much simpler to get full project traceability if you can map your process in the same place you create your requirements. That’s why more and more companies are looking at robust solutions for their requirements management. Solutions like Innoslate, that have built in collaboration features, traceability, test processes, system processes, and more. Innoslate has the benefit of being a full lifecycle tool. You can start with requirements management, develop a process for the product and system, and then verify and validate that the process meets the requirements.

Modern requirements tools should be able to  trace between requirements and other classes and get reports such as the RTM, RSM, and RVM. In Innoslate, you can actually use the Test Center feature as well, and you can even trace the requirements to your verification actions (Test Case) and create a complete RVTM.

Another major problem with using spreadsheets is that teams can barely communicate with each other. It becomes difficult to keep files updated. Files are often shared between people using the same tools, but cross sharing isn’t really possible. Large teams with large complex requirements need to be able to communicate effectively. Cloud RM tools provide the ability to collaborate and keep information accurate. You can also look for on-premise solutions that offer your team collaboration, but still meet your security needs. Innoslate offers the ability to work collaboratively throughout the entire project. With Innoslate you can communicate quickly via chat and comments and keep a record of your conversation. Version control allows team members to work together on the same requirements document saving you time and reducing errors.

Of course, with all these collaboration features you need strong program management controls. A program manager can see every change made to a requirement and the team member that made the change. He or she can then revert back to older versions. Baselining allows you to see changes throughout the entire history of the document. With permissions, you can determine which team members can have owner, read/write, or read/only privileges to your project. Branching and forking provides even stricter controls, allowing the program manager to split off certain sections of a project to different groups. From there the program manager can decide which changes to accept back into the main project.

Spreadsheets were not specifically designed for capturing, managing, and analyzing requirements. Microsoft Office’s spell check was built to help maintain proper grammar and spelling. However, Innoslate has a quality analysis feature that can look for mistakes specific to requirements. Writing multiple requirements into one can make verification impossible or writing requirements that aren’t specific enough. These mistakes are costly and can result in poor requirements management. Innoslate can improve your entire requirements document by finding these mistakes for you.

It’s important to find a modern solution that can allow you to move past spreadsheets with traceability, collaboration, and quality analysis.

Watch “Move Past Spreadsheets with Modern Requirements Management” webinar.

10 Most Important Requirements Capture and Management Rules

Requirement documenting plays an important role in systems engineering. Writing high quality requirements can not only save millions of dollars, but lives. No matter how experienced you are it’s important to remind yourself of requirement writing rules and techniques.

  1.  Know Your Stakeholders

    The first and most important commandment of writing requirements is to know your stakeholders. Understand what common knowledge they have. Make sure you are all on the same page. Understand what each group of stakeholder’s priorities is and their objectives. You do not want each group to develop their own priorities and objectives separately. Separate priorities and objective result in a time consuming and expensive review process with lots of conflicts. Collaborative software that allows for continuous reviewing will help you keep up with all the stakeholders needs. You never want to give them a completely finished product and then ask for review (although that is common practice).

  2. Remember the CONOPs

    Most of you will probably not forgo the Concept of Operations (CONOPS), since it is such a valuable artifact. The CONOPS will be something that all the stakeholders understand and collaborate on together.  In this step you basically create stories that will consider different scenarios and needs. From there you will have a better understanding of where to start with your requirements. The CONOPS will help you write quality requirements by finding all the assumptions. It will help evaluate the ‘what if’ scenarios, make testing easier, and formulate your needs into the requirements.

  3.  Understand What is Really Needed

    First of all, there is a huge difference between want and need. Will the system work without a particular requirement? If you answered yes, then you can probably omit that requirement. A common mistake systems engineers make is listing possible solutions to needs rather than the actual needs. If your need is an efficient way to communicate, don’t specify cell phones, since there are many other forms of communications that may be more feasible, less expensive, or effective.  List what is actually needed; don’t list possible solutions to the needs.

  4. Be Specific (Give actual numbers. Don’t leave room for assumptions.)

    Leaving room for assumptions is leaving room for error. If you are not careful with the language you choose you could end up making costly assumptions. Using words such as minimize, maximize, etc., and/or, more efficient, forces the stakeholders to assume. Don’t let the stakeholders assume how much you want to minimize.

    • etc. can mean so many things
    • and/or causes the reader to guess whether its ‘and’ or ‘or’
    • min. max. don’t just say minimize expansion, say minimize expansion to 300
    • don’t just say quick, say how quick
    • give actual numbers
  5. Do Not Be Too Specific

    The only mistake worse than not being specific enough is over specifying. You want to be specific, but not too specific. Carefully review your requirements before baselining. During this review delete any unnecessary specifics.

    Allow scope with your numbers. If a requirement is good enough at expanding 300% +/- 10%, then give that option. Have any numbers be based on the results of analyses, not just someone’s “engineering judgment.”

  6. Give Requirements Not Instructions

    Understand what is needed and create requirements from those needs. This is why Commandment #1 is so important. If you understand your stakeholders needs writing requirements and not instructions becomes an easier task. It might be tempting to just writing instructions, but that is not what requirements are for. Requirements should provide enough information to allow the builder to provide the most cost-effective solution to the problem.

  7.  Use the Words ‘Shall’, ‘Should’, and ‘Will’

    The industry’s standard word usage for a requirement is “shall”, a goal is “should”, and a statement is “will”. If you do not use these standard word choices you will confuse other stakeholders.

  8. Include a Rationale

    A rationale justifies the inclusion of a specific requirement. Attach a rationale to each requirement by explaining the need for the requirement. The rationale provides reviewers and implementers with additional information on the intent of the requirements, thus avoiding confusion down the line.

  9. Use Proper Grammar

    You will prevent a lot of costly mistakes due to confusion if you use proper grammar. For example, run on sentences will result in two requirements appearing to be one. One technique to improve grammar is to use bullet points first and then construct sentences out of them.

  10. Use a Standard

    Use a standard to ensure consistency. Three common standards are MIL-STD-490, IEEE, and ISO. You should choose one that is right for your industry.

    MIL-STD-490: The United States Military Standard establishes the format and content for the United States Department of Defense’s objectives. It can be useful in other areas as well.

    IEEE: The Institute of Electrical and Electronics Engineers Standards Association develops the IEEE standards. Unlike the MIL-STDs, the IEEE reaches a broad range of industries, including transportation, healthcare, information technology, power, energy, and much more.

    ISO: The International Organization for Standardization develops standards for business to optimize productivity and minimize costs.

Document Trees in Innoslate

Different levels of documents result from decomposition of user needs to component-level specifications, as shown in the figure below.

Innoslate enables the user to create such trees as a Hierarchy chart, which uses the “decomposed by” relationship” to show the hierarchy. An example is shown below.

Each of these Artifacts contain requirements at the different levels. Those requirements may be related to one another using the “relates from/relates to” relationship if they are peer-to-peer (i.e. at the same level of decomposition) or using the decomposed by relationship to indicate that they were derived from the higher-level requirement.

This approach allows you to reuse, rather than recreate requirements from a higher-level document. An example is shown in Requirements View below.


In this example, the top-level Enterprise Requirements were repurposed for the Mission Needs document (MN.1.1 and MN.1.2) and the System Requirements Document (SRD.5). If you prefer to keep the original numbers, you only have to Auto Number the ERD document using that button on the menu bar and the objects would show up with the ERD prefix in the lower documents. Note that in either case, the uploaded original document would retain the original numbers, in case you wanted to reference them that way. Also, each entity has a Universal Unique Identifier (UUID) that the requirement retains, if you prefer to use that as a reference.

This approach discussed above is only one way to accomplish the development of a document tree. Innoslate enables other approaches, such as using a new relationship (i.e. derived from/derives). Try it the way above and see if it meets your needs. If not, adjust as you like.

Why Requirements Management Needs Analysis

When we talk to potential customers who are seeking requirements management tools, we begin with asking them: “What is your requirements management process?” Usually they say, “we get requirements from our customers and then trace them to our products.” In areas where the customer knows exactly what they need and have been doing it for many, many years, this might work. But in the fast paced businesses of today, that approach will miss a lot of the real requirements, gaps, and risk areas. Ignorance of these requirements usually means product failure or worse, loss of life. Your company is then liable for that failure and in the US that usually means a lawsuit. If you can’t prove that you did the necessary analyses, your company will usually lose the lawsuit.

If they say they do analysis on those original customer requirements we than ask: “How do you do requirements analysis?” Often the answer is: “Well, we read them and look for shall statements.” Again, this is insufficient and will lead to failure! A requirement must be:

  • Clear: Clear represents if this Requirement is unambiguous and not confusing.
  • Complete: Complete represents if this Requirement expresses a whole idea.
  • Consistent: Consistent represents if this Requirement is not in conflict with other requirements.
  • Correct: Correct represents if this Requirement describes the user’s true intent and is legally possible.
  • Design: Design represents if this Requirement does not impose a specific solution on design; says “what”, not “how”.
  • Feasible: Feasible represents if this Requirement is able to be implemented with existing technology, and within cost and schedule.
  • Modular: Modular represents if this Requirement can be changed without excessive impact on other requirements.
  • Traceable: Traceable represents if this Requirement is uniquely identified, and able to be tracked to predecessor and successor lifecycle items/objects.
  • Verifiable: Verifiable represents if this Requirement is provable (within realistic cost and schedule) that the system meets the requirement.

If they say they understand the need for complete requirements analysis, then we ask: “Did you know that functional analysis and modeling is a critical part of requirements analysis and management?” Again, most of the time the answer we receive is: “No, we don’t need that! All we need is a cheap tool that traces the requirements to product.” As you might expect this approach also leads to failure.

The Department of Defense (DoD) recognizes this problem. They define the purpose of requirements analysis as:

“To (1) obtain sets of logical solutions [functional architectures] derived from defined Technical Requirements, and (2) to better understand the relationships among them. Once these logical solution sets are formed, allocated performance parameters and constraints are set, and the set of Derived Technical Requirements for the system can be initially defined.

Outcomes: For each end product of a system model:

  1. A set of logical models showing relationships (e.g., behavioral, functional, temporal, data flows, etc.) among them
  2. A set of ‘design-to’ Derived Technical Requirements”

Most experts use a process like the one below:

Notice that functional analysis and allocation is in the center of this process. Other process models have this as well, but tend to bury it. That is a mistake. What functional analysis does is enable the analyst to create user stories (sometimes called use cases, scenarios, or threads) that can be used to validate the user requirements. As you conduct this analysis by creating a functional model, you can identify gaps and problem areas that the user may not have originally considered. You can also use these models to derive the performance requirements and identify other constraints using simulation.

The figure below shows a functional model of a process for fighting forest fires. It includes data entities and resources used in the operation. The rounded rectangular blocks represent the functional requirements for the operation. Even though some of these functions may currently be performed by people, many of them can be automated to enhance the performance of the overall system. Many of these functional requirements would be missing if you just asked people what the requirements were.

We can better understand the performance requirements by execution of this model in a simulation. An example of the results from a discrete event simulation is shown below:


These results show the time, cost and resources (water) used to put out the fire. By running these kinds of simulations, we can easily determine cost, schedule and performance metrics needed to accomplish the operation. Isn’t it better to know that early in the design phase rather than later?

The end result of performing these analyses is a much better set of requirements to build or buy what the users need. It will also build the case that you did the due diligence in this litigious society. That could mean the difference between a successful project and a failed project.