Is There a Return on Investment from Model-Based Systems Engineering (MBSE)? Part 1

Join us for a live webinar on this topic, “Is There a ROI From MBSE” on Thursday, October 17th at 11:00 am ET. Register Here.

This question is one that many people ask. In fact, the International Council on Systems Engineering (INCOSE) has that as one of its tasks for their Value Proposition Initiative. A group of systems engineers is trying to find evidence to prove that MBSE has value. However, that becomes very difficult for a concept that has only been around for a dozen years, when the lifecycle of many of the systems of interest are measured in several decades.

We can approach this question by inference. If there is a significant return on investment in systems engineering, then we can infer that there might be one for MBSE. Fortunately, we do have many decades of experience applying systems engineering to project since the 1950s (at least, depending on how you define systems engineering). One of the best analyses I have come across over the years was a very interesting piece of work by Werner M. Gruhl who was at the time the Chief of the Cost & Economics Analysis Branch at NASA. His work was published in a NASA technical paper entitled, “Issues in NASA Program and Project Management” (NASA SP-6101 (08), in 1994. In a paper by Ivy Hooks in this publication, she states that “if the program requirements are not well understood, there is not much hope for estimating the cost of a program.” She continues: “Werner Gruhl developed a history of NASA programs versus cost overruns” and cited the diagram below (redrawn to due to the poor quality of the document found – an old scanned PDF). She interpreted this chart as “if you have not done a good job in Phase A and B in defining and confining your program, you are going to encounter large numbers of changing requirements and the cost will go up accordingly.” Note the figure below indicates % Spent on Systems Engineering, which it is really Phase A and B in NASA terminology.

Thus, it’s clear that at least the combination of program management and systems engineering, which is what allows you to properly develop the set of requirements for the program, is required to keep the cost of the project from sky rocketing. Note that program management and systems engineering are flip sides of the same coin. The program manager optimizes cost, schedule, and performance, while mitigating risk in each of these areas. The systems engineer is tasked to do the same for the system. That’s why these two disciplines have been seen to overlap, which was recognized in a recent book by INCOSE and the Program Management Institute (PMI).

Another more recent attempt at qualifying the value of systems engineering came from the Software Engineering Institute. They conducted several studies to determine the value of systems engineering, including one documented in their November 2012 paper entitled “The Business Case for Systems Engineering Study: Results of the Systems Engineering Effectiveness Survey.” The authors “found clear and significant relationships between the application of SE best practices to projects and the performance of those project” as seen in the figure below.

Project Performance vs. Total SE Capability

In a later presentation by Mr. Joseph P. Elm, one of the authors of the 2012 paper, on “Quantifying the Effectiveness of Systems Engineering,” he cites a finding for a General Accountability Office (GAO) report (GAO-09-362T) that states:

“… managers rely heavily on assumptions about system requirements, technology, and design maturity, which are consistently too optimistic. These gaps are largely the result of a lack of a disciplined systems engineering analysis prior to beginning system development …”

So, it is recognized that there is great value in performing at least the “right amount” of systems engineering. If we use the Gruhl graph as a basis, we need to spend around 7-12% of the program’s budget on the combination of program management and systems engineering. Since the cost of the program could as much as double on average according to the chart, the return would be about 10 times the investment. For example, if we spent $100,000 on systems engineering and program management and the overall cost of the program was $1,000,000, then since the cost could have doubled to $2,000,000, we save $1,000,000.

So now that we agree there is a substantial return on investment in systems engineering, let’s get back to the question of ROI on MBSE. The question here is then, “does modeling help systems engineering.” Since we have always done modeling in systems engineering, I think that is clearly a part of good systems engineering. But the flavor of MBSE being pushed by many in the community has equated MBSE to SysML and many have also equated SysML as implemented by MagicDraw. But does SysML and MagicDraw® do all the things we need to do in systems engineering? In particular, do we obtain a good set of system requirements in a form easily used by all the stakeholders?

To begin to answer these questions, let’s go back to Mr. Elm’s paper. He states that the systems engineer must perform the following tasks:

  • Requirements Development
  • Requirements Management
  • Trade Studies
  • System Architecture Development
  • Interface Management
  • Configuration Management
  • Program Planning
  • Program Monitoring and Control
  • Risk Management
  • Product Integration Planning and Oversight
  • Verification Planning and Oversight
  • Validation Planning and Oversight

 

SysML consists of nine diagram type, most of which were derived from software engineering practices, not systems engineering. Yes, there is overlap between the two, but not as much as the overlap between systems engineering and program management. That becomes obvious from the task list above, many of which include explicitly the word “management.”

SysML also has proven to be very difficult for most other disciplines to understand, since they speak other languages. It also takes at least two large books, “A Practical Guide to SysML” and “SysML Distilled.” In comparison, the Lifecycle Modeling Language provides a whole systems engineering ontology and limited diagramming that completely subsume SysML. However, LML can still be explained in a very thin book, “Essential LML.” You can see the comparison in the picture below.

You probably are asking, “How is that possible that LML subsumes SysML?” By using an ontological approach that defines a set of entity classes and their relationships, along with the attributes on both, LML provides all the elements of a real language (nouns, verbs, adjectives and adverbs). This ontology can be used to capture the information easily and efficiently. Then that information can be displayed in many ways, including all the nine SysML diagram types.

The Innoslate® tool proves this assertion, as it produces all nine SysML diagrams (and many more) from this ontology as extended in Version 1.1 of the LML specification. In addition to the SysML diagrams, Innoslate produces the LML Action Diagram, that represents the same information as the SysML Activity Diagram, but in a significantly more understandable form. We can see this when we compare side by side the two type of diagrams, as shown below.

LML Action Diagram Example

SysML Activity Diagram

In the SysML diagram I need to know what the diamond and fork symbols mean. In the Action Diagram, I know exactly what they mean, because the words: OR, LOOP, and Decomposed, make their intent clear. In addition, in SysML I cannot just allocate the decision points to who or what performs them. I can in LML. Of course, if there were only two symbols I needed to decipher, then I would not care as much, but SysML has over 30 such symbols. You will need a “3-D decoder ring” to fully understand how to use all the symbols, hence the very large books and long training classes needed to try to learn SysML. This learning curve translates into a significant investment in the workforce to get them up to speed on this complex language. Of course, the electrical engineers, mechanical engineers, logistics experts, and all the other disciplines have their own languages and have no interest in learning something this complex.

You might say, “but of course MagicDraw overcomes these limitations in SysML?” The answer to that is not as well. In particular, if we go back to the list of systems engineering tasks, MagicDraw only does one “well:” System Architecture Development. Although MagicDraw has some limited requirements capability, almost everyone uses another requirements tool in conjunction with it. Innoslate by comparison has a robust Requirements View that includes automated requirements quality checking using the artificial intelligence technique of Natural Language Parsing (NLP). The requirements then can be directly traced to the diagram entities within the same tool, resulting in one database and no configuration management problems that you encounter having two databases. Innoslate also has a built in Test Center for the V&V activities. In addition, Innoslate provides Discrete Event and Monte Carlo simulators to verify that the Action (or Activity) Diagrams have been correctly done. We use that same approach to support Program Planning, Monitoring and Control.

So back to the ROI discussion. Can MBSE provide a healthy ROI? Only if we do all the things we need to do in systems engineering. In addition, if we can use modern technology to help automate these difficult tasks, we can provide even higher ROI than systems engineering by itself. Innoslate and LML provide a means to provide this higher ROI, while MagicDraw and SysML actually cost much, much more to implement and you end up with a poorer result. So, if you want ROI from your MBSE investment, use Innoslate and LML.

Join us for a live webinar on this topic, “Is There a ROI From MBSE” on Thursday, October 17th at 11:00 am ET. Register Here.

Webinar: What’s New in Innoslate 4.2?

Join us Wednesday, July 31st at 11:00 am for “What’s New in Innoslate 4.2?” Innoslate 4.2 brings a lot of new features and updates to improve the capabilities of systems engineering and requirements management.

Register here

Your host, Dr. Steven Dam, will walk you through all the changes from Innoslate 4.2. He’ll show you the new Charts View and how to create and edit XY plots. You’ll also get to see how you can generate Systems Requirements Documents (SRD) right from an asset diagram. Other new features that will be shown:

  • Support Dashboard
  • Roll Up Models
  • Entity Definition Report
  • Document Template Generation

Copy and paste this link into your browser: https://attendee.gotowebinar.com/register/3362923783853854477

Can’t make the webinar? Come back here for a recording.

innoslate, systems engineering, model-based systems engineering, requirements management

Innoslate 101: A Webinar for New Users

Come join us June 6th at 11:00 am EDT for “Innoslate 101: A Webinar for New Users.” Newbie Innoslate user, Joannah Moore, is going to show you just how easy it is to learn Innoslate. She will walk you through the ins and outs of the tool and show you how you can become an expert Innoslate user in no time.

Stay after the live demonstration for a question and answer session with systems engineering expert, Dr. Steven Dam.

Register Today

About Your Host

Joannah Moore is in both Sales & Support at SPEC Innovations. Before SPEC, Joannah’s career was on a strict business path including Commercial Insurance and Property Management. However, years into property management, she was hungry for more. This brings us to 2018 when she joined SPEC Innovations as a recent college graduate with her B.S. Degree in Business-IT Management. She is a certified IT professional with many IT certifications in the various fields of IT, including project management

About Innoslate

Innoslate is the model-based systems engineering solution of the future. An all-in-one software package made for systems engineers and program managers, you can keep your requirements management, modeling and simulation, test management, and more all in one place. Smarter, more successful systems start here. Create a trial account at innoslate.com/signup.

Model-Based Systems Engineering De-Mystified

Join us August 30th at 2:00 pm ET for a special guest webinar with Dr. Warren Vaneman. Model-Based Systems Engineering (MBSE) is an ambiguous concept that means many things to many different people. The purpose of this presentation is to “de-mystify” MBSE, with the intent of moving the sub-discipline forward. Model-Based Systems Engineering was envisioned to manage the increasing complexity within systems and System of Systems (SoS). This presentation defines MBSE as the formalized application of modeling (static and dynamic) to support system design and analysis, throughout all phases of the system lifecycle, and through the collection of modeling languages, structures, model-based processes, and presentation frameworks used to support the discipline of systems engineering in a model-based or model- driven context. Using this definition, the components of MBSE (modeling languages, processes, structures, and presentation frameworks) are defined. The current state of MBSE is then evaluated against a set of effective measures. Finally, this presents a vision for the future direction of MBSE.

Register here

https://attendee.gotowebinar.com/register/1889736524753881346

 

Meet Your Host

Dr. Warren Vaneman is a Professor of Practice in the Systems Engineering Department at the Naval Postgraduate School, Monterey, CA. He has more than 30 years of leadership and technical positions within the U.S. Navy and the Intelligence Community. Dr. Vaneman has been conducting research in MBSE for unmanned systems, enterprise systems and system of systems since July 2011. To enhance his research efforts Dr. Vaneman teaches several courses in Systems Engineering and Architecting and System of Systems Engineering and Integration. Prior to joining NPS, Dr. Vaneman has held various systems engineering positions within the Intelligence Community, including Chief, Architecture Analysis Division, and Chief Architect of the Enterprise Ground Architecture at the National Reconnaissance Office (NRO), and Lead Systems Engineer for Modeling and Simulation at the National-Geospatial Intelligence Agency (NGA). Dr. Vaneman is also a Retired Captain in the Navy Reserve, where he was qualified as a Surface Warfare Officer, Space Cadre Expert, and Information Dominance Warfare Officer. He had the pleasure of serving in six command tours, including a command tour in Afghanistan. He has a B.S. from the State University of New York Maritime College, a M.S. in Systems Engineering, and a Ph.D. in Industrial and Systems Engineering from Virginia Tech, and a Joint Professional Military Education Phase 1 Certificate from the Naval War College.

 

 

Data Analytics – Paving the Way for the Future of Digital Engineering

I recently attended the first Andrew P. Sage Senior Design Capstone Competition at George Mason University. This conference included student papers and presentations from GMU, West Point, University of Pennsylvania, US Naval Academy, Stevens Institute of Technology, and Virginia Tech. The conference is named for Andy Sage, who was the first Dean of Engineering at GMU and a prolific writer in the field of systems engineering. The students and faculty did him proud.

But perhaps the most impactful presentation on me was that of the keynote speaker, Dr. Kirk Borne. His topic was: “Using Analytics to Predict and to Change the Future.” He was coming at the problem from a “Big Data” point of view, beginning early in the presentation with the picture below talking about Zettabytes of data from airline engines. That is 1 x 1021 bytes of data.

I have often noted that in systems engineering, particularly in the early concept development phase, I have a sparse dataset, not a large one. In cutting edge work, such as defense applications, we often have only basic research where the massive data from other systems may not relate well to the new concept. However, during the presentation, I found myself writing many notes to myself about how the same concepts work even for smaller datasets.

Then I realized that we are already applying these kinds of techniques to Innoslate, as a result of applying natural language processing (NLP) to the information we are gathering and developing to create the system model.

For those new to NLP, Wikipedia defines it as “an area of computer science and artificial intelligence concerned with the interactions between computers and human (natural) languages, in particular how to program computers to fruitfully process large amounts of natural language data.” We currently use NLP in three of our Innoslate analytical tools: Requirements Quality Checker; Intelligence; and Traceability Assistant. The first two tools have been around for a while, but the Traceability Assistant is new with version 4.0.

If you are not familiar with the Requirements Quality Checker, it automates one of the more difficult problems in requirements management: knowing when you have good requirements. The picture below shows an example. The NLP algorithm assesses six of the eight quality attributes (Clear, Complete, Consistent, Design, Traceable, and Verifiable) shown on the sidebar below, and rolls them up into a quality score.

requirements management view and quality checker

We use this information to identify problems with the requirements and suggested fixes. Often those fixes are simple, such as forgetting a punctuation mark to complete the sentence or including a key verb (i.e., “shall”). You can always override the suggestion and select that it passes the test. All such changes are recorded in the History record for that entity.

Intelligence View also applies NLP technology against over 65 heuristics (i.e., rules of thumb) that represent best practices. Again, the NLP comes into play by looking at roots of words and comparing them, so it quickly recognizes that Wildfire and Wildfires are potentially the object. You can also select the “Fix” button and a window pops up letting you know what the problem is and helps you fix it (see right).

Finally, our newest application of NLP technology comes in the form of the Traceability Assistant. Innoslate’s Traceability Assistant is the “dream come true” for all of us who have been working with relational databases. The real challenge has been how to relate information between different classes of data. In fact, I was working on mapping two related policy documents the other day and went to my developers and asked, “Is there some way to automate this process of tracing requirements between documents?” Then they showed me what they were working on: The Traceability Assistant. They used the NLP technology to read the information contained in the name and description fields of every item for comparison and then determine if it is a match and how good a match it might be. In the example below, we can see different shades of green, where the darker green indicates a higher probability match. Now it’s just an algorithm and you may not agree with the conclusions, so you must put the “X” in the box, but the tool also shows the full name and description of the row and column entities so that you can make an informed decision. The best part is this works with any relationships between entity classes. So we can use this for functional allocation, as well as requirements traceability, and all the other connecting relationships. Can you imagine the productivity increase from this?

traceability assistant hierarchical comparison matrix

Innoslate also has a suspect assist, so that if relationships have been already created and reviewed, but then changes are made, it will help identify when the information entities should likely not be connected. This feature isn’t like many other tools provide, which show that you changed something, so all the information downstream is suspect. That can lead to someone cleaning up the grammar causing a major review down the entire chain. What a waste of time and energy. Innoslate’s Suspect Assistant highlights in shades of red the probability that traced entities should no longer be connected. It can also be used when you have done a set of manual connections to identify that not enough information has been provided in the name/description to validate a connection between the entities. This feature will then help you identify where you need to enhance the clarity between connected entities.

suspect assistant hierarchical comparison matrix

Both these tools are available in the traceability matrix diagram provided in Innoslate 4.0. Our commitment to the customer and application of emerging technologies, such as LML, cloud computing, and NLP technology, demonstrates that Innoslate is the tool for enabling 21st Century Digital Engineering.

 

Professional Development Event Model-Based Systems Engineering

If you are in the Washington, DC Area, April 24-26, 2018, don’t miss the Professional Development Event Model-Based Systems Engineering training course from TSTI.TSTI logo.jpg

This course is intended for practicing systems engineers, payload principle investigators, subsystem engineers or project managers involved in any phase of the space mission life cycle who are curious about application of MBSE to their projects. Some basic understanding of systems engineering principles and processes is assumed.

The course is organized in a unique, modular format allowing you to choose the depth of training appropriate to your interest and time available. Sign up for one, two or all three days.

Want an overview of MBSE? Day 1: Builds a foundation for understanding why MBSE is useful and its overall value proposition for your projects.
Want to be an MBSE user? Day 2: Builds on day one and provides a deeper understanding for potential users of MBSE to explore what types of products and artifacts can be generated and what they can be used for in your projects.
Want to build system models? Day 3: Builds on days 1 and 2 and dives deeper into the details of MBSE languages and tools and challenges participants to build their own models from scratch. While the course uses a specific tool for teaching, the goal of the course is to be “tool agnostic” such that the basic principles can be applied to any tools that a person or project may use.

For details and registration, visit https://www.tsti.net/mbse/ or read the informational brochure. MBSE Virginia Course Flyer

When: Tuesday, April 24 –Thursday, April 26 9 a.m. – 5 p.m.
Where: Marriott Courtyard Dulles Airport, 3935 Centerview Drive, Chantilly, VA 20151
Cost: 3 Days – $1,600, 2 Days – $1,290, 1 Day – $980

Innoslate Cloud vs. Innoslate Enterprise

This article is meant to help you determine which of these solutions is best for you and your team.

 

Innoslate is offered as a cloud or on premise solution, Innoslate Cloud and Innoslate Enterprise, respectively. It can be difficult to decide which one is right for you. We’ll take you through the pros and cons of each one to help you make this decision.

 

Innoslate Cloud

Innoslate Cloud is flexible and affordable. You can get started quickly, since there’s no download required. It’s easy to share projects with reviewers that are not Innoslate users yet. The pricing plans can be monthly or yearly, so you only have to pay for what you need. Innoslate Cloud is hosted in data centers audited for ISO 27001 and SAS70, so security isn’t a problem.

 

Pros:

Scalability through the cloud

High availability

Flexible pricing plans

Affordable pricing

No download required

 

Cons:

No floating licenses offered

Less administration controls

Less options

 

Innoslate Enterprise

Innoslate Enterprise offers scalability and collaboration beyond the cloud and behind your firewall, with the heightened security of your own server. Innoslate Enterprise is available on unclassified (U/FOUO) and classified (SECRET) level government networks through NSERC.  Innoslate Enterprise is also available on Amazon AWS Marketplace. You can choose between floating and named licensing options. You can get started within seconds on a modern server hardware. The high performance and close proximity of Innoslate Enterprise removes latencies. The server, RedHat Wildfly, implements the latest enterprise JAVA standards with full JAVA EE7 support. Wildfly runs on Windows, Mac, and Linux servers.

 

Pros:

Massive scalability (10 million entities)

Increased administration control

More availability through NSERC and AWS

Floating licensing options available

Fewer latencies

 

Cons:

Less flexibility through pricing

More expensive than Innoslate Cloud

Download required

 

Innoslate Enterprise is perfect if you need your SaaS on your organization’s server or want more administration controls through LDAP. Some organization will have to choose Innoslate Enterprise due to strict security requirements. Check with your IT department to see if you are required to use an on-premise solutions.

 

Still not sure, which solution is right for you? Give us a call at 571.485.7800.

Difference in Floating vs. Named – What’s Right For Me?

Innoslate Enterprise has two licensing type options: Floating and Named. On a daily basis, we hear people ask us “what’s the difference and which one is best for my organization?” They both have different benefits and it’s important to understand what each one is in order to pick the best licensing type for your organization.

Floating Licensing – “a software licensing approach in which a limited number of licenses for a software application are shared among a larger number of users over time.”

 

We like to use the analogy of a family computer vs. a cell phone. Floating licenses are most similar to a family computer. More and more people have individual laptops and iPads, but not too long ago most families had a shared computer. Each family member had their own account. This allowed them a way to login with their own username and password. They could also save their own background, screensaver, files, and other preferences. In other words it would look and feel just like their own computer, but without having to buy each family member their own laptop. However, only one family member can use the computer at a time.

 

One floating licenses is just like that family computer. Multiple people can have a login and use Innoslate as if it were their own license, but only one at a time. This is a really great option if you have a large team and  maybe only a quarter will be using it at a time. For instance, if you have 100 engineers, but only 25 need to use a license at a time. Rather than buying 100 named licenses for each engineer, you could buy 25 floating licenses and save a lot of money.

 

Floating licenses are also a great option if you have a lot of employees joining or leaving a contract frequently. This option allows you to not have to be concerned with whose name is associated with the license. You can easily remove and add employees to a floating license.

 

Named Licensing – “an exclusive licensure of rights assigned to a single named software user. The user will be named in the license agreement.”

 

Back to the family computer vs. cell phone analogy. Named licensing is like a cell phone. Cell phones are not designed for sharing. There aren’t multiple logins. The saved preferences, downloads, and background will not change based on which family member is using the cell phone. They are meant for one person to use it always. Named licensing is exactly the same. Each named license is associated with a name.

 

A named license is cheaper than floating. You can also have free read only users. For example, say you purchased 1 named license. You can then invite as many people as you want to come review your project. They will be able to see the project you shared with them, leave comments, and chat. While if you have a floating license, a read only users consume a license for the duration they use the tool until they sign out.

 

If you know the team that will be using each named license and they will be using it together daily, then named licenses are right for you. It can also be the right option if you have a very large number of reviewers using the software daily.

When making the decision, floating or named, make sure to think about the following:

  • How many concurrent users do we have?
  • Do we have a lot of employee changeover?
  • How many total engineers/requirements managers will use the software daily?
  • How many reviewers will be using the software daily?
  • What is our budget?

Still not sure? Talk to us. We’d be happy to help you decide which option is best for you.

Read next: Innoslate Enterprise vs. Innoslate Cloud – What Is Right For Me?

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.

Why We Built Innoslate – About Us

As systems engineers who had been using modeling and requirements tools for decades, we kept running into the same problem: we needed a solution that spans the entire system lifecycle. Effective requirements analysis and management requires not only capturing and managing the requirements provided by the customer, but also the analysis and decomposition of those requirements into specifications for the buying and building of the system components.

Requirement Analysis includes modeling the processes and procedures related to the requirements and simulating those processes with realistic constraints in resources, bandwidth, latencies, and many other factors. And once we have a baselined set of requirements, we have to not only “maintain” them (as they constantly change over the lifecycle), but we also have to verify that the resulting components and systems meet the requirements at every level of composition (component, subsystem, system, system of systems, etc.).

We realized what most systems engineers needed was a requirements tool, a modeling tool, a simulation tool, a verification tool, a risk tool, a program management tool, and a document management tool. None of the existing software solutions had native integration for all these different tools. The International Council on Systems Engineering (INCOSE) provides a tools interoperability working group, which includes representatives from all the major tool vendors. Unfortunately, without native integration, users experience missing data points and a drain on time and resources to integrate. It also became unreasonably expensive to purchase so many different tools and to manually integrate and manage each one.  

SPEC Innovations built Innoslate to be the all-in-one solution for systems engineer and program managers. We also wanted engineers to start analyzing overall quality of the entire project early in the lifecycle. That’s why Innoslate provides analytical capabilities like Innoslate’s Requirements Quality Checker and Intelligence View. These two internal features identify problems with the requirements and the overall model, quickly, so they can be fixed early in the process, thus saving time and money. Not only that, you get the scalability and collaboration features you need to work not only small projects, but also very large ones.