How to Choose the Right MBSE Tool

Find the Model-Based Systems Engineering Tool for Your Team

A model-based systems engineering tool can provide you with accuracy and efficiency. You need a tool that can help you do your job faster, better, and cheaper. Whether you are using legacy tools like Microsoft Office or are looking for a MBSE tool that better fits your team, here are some features and capabilities you should consider.

Collaboration and Version Control

It’s 2018. The MBSE tool you are looking at should definitely have built in collaboration and version control. You want to be able to communicate quickly and effectively with your team members and customers. Simple features such as a chat system and comment fields are a great start. Workflow and version control are more complex features but very effective. Workflow is a great feature for a program manager. It allows the PM to design a process workflow for the team that sends out reminders and approvals. Version control lets users work together simultaneously on the same document, diagram, etc. If you are working in a team of 2+ people, you need a tool with version control. Otherwise you will waste a lot of time waiting for a team member to finish the document or diagram before you can work on it.

Built in Modeling Languages Such as LML, SysML, BPML, Etc.

Most systems engineers need to be able to create uniformed models. LML encompasses the necessary aspects of both SysML and BPML. If you would like to try a simpler modeling language for complex systems, LML is a great way to do that. A built in modeling language allows you to make your models correct and understandable to all stakeholders.

Executable Models

A MBSE tool needs to be much more than just a drag and drop drawing tool; the models need to be executable. Executable models ensure accurate processes through simulation. Innoslate’s activity diagram and action diagram are both executable through the discrete event and Monte Carlo simulators. With the discrete event simulator, you will not only be able to see your process models execute, but you will able to see the total time, costs, resources used, and slack. The Monte Carlo simulator will show you the standard deviation of your model’s time, cost, and resources.

Easy to Learn

It can take a lot of time and money to learn a new MBSE tool. You want a relatively short learning curve. First, look for a tool that has an easy user interface. A free trial, sandbox, or account to get started with is a major plus. This let’s you get a good feel for how easy the tool is to learn. Look for tools that provide free online training. It’s important that the tool provider is dedicated to educating their users. They should have documentation, webinars, and free or included support.

Communicates Across Stakeholders

Communication in the system/product lifecycle is imperative. Most of us work on very diverse teams. Some of us have backgrounds in electrical engineering or physics or maybe even business. You need to be able to communicate across the entire lifecycle. This means the tool should have classes that meet the needs of many different backgrounds, such as risk, cost, decisions, assets, etc. A tool that systems engineers, program managers, and customers can all understand is ideal. The Lifecycle Modeling Language (LML) is a modeling language designed to meet all the stakeholder needs.

Full Lifecycle Capability

A tool with full lifecycle capability will save you money and time. If you don’t choose a tool with all the features needed for the project’s lifecycle, you will have to purchase several different tools. Each of those tools can cost the same amount as purchasing just one full lifecycle MBSE tool. You will also have to spend money on more training since you will not be able to do large group training. Most tools do not work together, so you will have spend resources on integrating the different tools. This causes the overall project to cost a lot more. This is why Innoslate is a full lifecycle MBSE solution.

 

It’s important to find the tool that is right for your project and your team. These are just helpful guidelines to help you find the right tool for you. You might need to adjust some of these guidelines for your specific project. If you would like to see if Innoslate is the right tool for your project, get started with it today or call us to see if our solution is the good fit for you.

 

Why Do We Need Model-Based Systems Engineering?

MBSE is one of the latest buzzwords to hit the development community.

The main idea was to transform the systems engineering approach from “document-centric” to “model-centric.” Hence, the systems engineer would develop models of the system instead of documents.

But why? What does that buy us? Switching to a model-based approach helps: 1) coordinate system design activities; 2) satisfy stakeholder requirements; and 3) provide a significant return on investment.

Coordinating System Design Activities

The job of a systems engineer is in part to lead the system design and development by working with the various design disciplines to optimize the design in terms of cost, schedule, and performance. The problem with letting each discipline design the system without coordination is shown in the comic.

If each discipline optimized for their area of expertise, then the airplane (in this case) would never get off the ground. The systems engineer works with each discipline and balances the needs in each area.

MBSE can help this coordination by providing a way to capture all the information from the different disciplines and share that information with the designers and other stakeholders. Modern MBSE tools, like Innoslate, provide the means for this sharing, as long as the tool is easy for everyone to use. A good MBSE tool will have an open ontology, such as the Lifecycle Modeling Language (LML); many ways to visualize the information in different interactive diagrams (models); ability to verify the logic and modeling rules are being met; and traceability between all the information from all sources.

Satisfying Stakeholder Requirements

Another part of the systems engineers’ job is to work with the customers and end-users who are paying for the product. They have “operational requirements” that must be satisfied so that they can meet their business needs. Otherwise they will no longer have a business.

We use MBSE tools to help us analyze those requirements and manage them to ensure they are met at the end of the product development. As such, the systems engineer becomes the translator from the electrical engineers to the mechanical engineers to the computer scientists to the operator of the system to the maintainer of the system to the buyer of the system. Each speaks a different language. The idea of using models was a means to provide this communications in a simple, graphical form.

We need to recognize that many of the types of systems engineering diagrams (models) do not communicate to everyone, particularly the stakeholders. That’s why documents contain both words and pictures. They communicate not only the visual but explain the visual image to those who do not understand it. We need an ontology and a few diagrams that seem familiar to almost anyone. So, we need something that can model the system and communicate well with everyone.

Perhaps the most important thing about this combined functional and physical model is it can be tested to ensure that it works. Using discrete event simulation, this model can be executed to create timelines, identify resource usage, and cost. In other words, it allows us to optimize cost, schedule, and performance of the system through the model. Finally, we have something that helps us do our primary job. Now that’s model-based systems engineering!

Provides a Significant Return on Investment

We can understand the idea of how systems engineering provides a return on investment from the graph.

The picture shows what happens when we do not spend enough time and money on systems engineering. The result is often cost overruns, schedule slips, reduced performance, and program cancellations. Something not shown on the graph, since it is NASA-related data for unmanned satellites, is the potential loss of life due to poor systems engineering.

MBSE tools help automate the systems engineering process by providing a mechanism to not only capture the necessary information more completely and traceably, but also verify that the models work. If those tools contain simulators to execute the models and from that execution provide a means to optimize cost, schedule, and performance, then fewer errors will be introduced in the early, requirements development phase. Eliminating those errors will prevent the cost overruns and problems that might not be surfaced by traditional document-centric approaches.

Another cost reduction comes from conducting model-based reviews (MBRs). An MBR uses the information within the tool to show reviewers what they need to ensure that the review evaluation criteria are met. The MBSE tool can provide a roadmap for the review using internal document views and links and provide commenting capabilities so that the reviewers’ questions can be posted. The developers can then use the tool to answer those comments directly. By not having to print copies of the documentation for everyone for the review, and then consolidate the markups into a document for adjudication, we cut out several time-consuming steps, which reduce the labor cost of the review an order of magnitude. This MBR approach can reduce the time to review and respond to the review from weeks to days.

Bottom-line

The purpose for “model-based” systems engineering was to move away from being “document-centric.” MBSE is much more than just a buzzword. It’s an important application that allows us to develop, analyze, and test complex systems. We most importantly need MBSE because it provides a means to coordinate system design activity, satisfies stakeholder requirements and provides a significant return on investment.  The “model-based” technique is only as good the MBSE tool you use, so make sure to choose a good one.

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?

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.

 

Collaboration.

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.

How to Use Innoslate to Perform Failure Modes and Effects Criticality Analysis

“Failure Mode and Effects Analysis (FMEA) and Failure Modes, Effects and Criticality Analysis (FMECA) are methodologies designed to identify potential failure modes for a product or process, to assess the risk associated with those failure modes, to rank the issues in terms of importance and to identify and carry out corrective actions to address the most serious concerns.”[1]

FMECA is a critical analysis required for ensuring viability of a system during operations and support phase of the lifecycle. A major part of FMECA is understanding the failure process and its impact on the operations of the system. The figure below shows an example of how to model a process to include the potential of failure. Duration attributes, Input/Output, Cost and Resource entities can be added to this model and simulated to begin estimating metrics. You can use this with real data to understand the values of existing systems or derive the needs of the system (thresholds and objectives) by including this kind of analysis in the overall system modeling.

action diagram fmea

Step one is to build this Action Diagram (for details on how to do this please reference the Guide to Model-Based Systems Engineering. Add a loop to periodically enable the decision on whether or not a failure occurs. The time between these decisions can be adjusted by the number of iteration of the loop and the duration of the “F.11 Continue Normal Operations” action.

Adjust the number of iterations by selecting the loop action (“F.1 Continue to operate vehicle?”) and press the </>Script button (see below). A dialog appears asking you to edit the action’s script. You can use the pull-down menu to select Loop Iterations, Custom Script, Probability (Loop), and Resource (Loop). In this case, select “Loop Iterations.” The type in the number (choose 100) as see in the figure below.

Next change the duration of this action and the F.11. Since the loop decision is not a factor in this model, you can give it a nominally small time (1 minute as shown). For the “F.11 Continue Normal Operations” choose 100 hours. When combined with the branch percentage of this path of 90%, means that we have roughly 900 operating hours between failures, which is not unusual for a vehicle in a suburban environment. We could provide a more accurate estimate, including using a distribution for the normal operating hours.

The 90% branch probability comes from the script for the OR action (“F.2 Failure?”). That selection results in the dialog box below.

Now if you assume a failure occurs approximately 10% of the time you can then determine the failure modes are probabilistic in nature, the paths need to be selected based on those probabilities. The second OR action (“F.3 Failure Mode?) shows three possible failure modes. You can add more by selecting F.3 and using the “+Add Branch” button. You can use this to add more branches to represent other failure modes, such as “Driver failure,” “Hit obstacle,” “Guidance System Loss,” etc.

Note to change the default names (Yes, No, Option) to the names of the failure modes, just double click on the name and a dialog will pop-up (as on right). Just type in the name you prefer.

To finish off this model add durations to the various other actions that may result from the individual failures. The collective times represent the impact of the failure on the driver’s time. Since you do not have any data at this time for how long each of these steps would take, just estimate them by using Triangular distributions of time (see sidebar below).

This shows an estimate from a minimum of ½ hour to a maximum of 1 hour, with the mean being ¾ hour. If you do this for the other actions, you can now execute the model to determine the impacts on time.

Note, you could also accumulate costs by adding a related Cost entity to each of the actions. Simply create an overall cost entity (e.g., “Failure Costs” and then decompose it by the various costs of the repairs. Then you can assign the costs to the actions by using a Hierarchical Comparison matrix. Select the parent process action (“F Vehicle Failure Process”) and use the Open menu to select the comparison matrix (at bottom of the menu). Then you will see a sidebar that asks for the “Target Entity,” which is the “Failure Costs” you just created. Then select the “Target Relationship,” which is only one “incurs” between costs and actions, then push the blue “Generate” button to obtain the matrix. Select the intersections of the between the process steps and the costs. This creates the relationships in between the actions and the costs. The result is shown below.

hiearchical comparison matrix

If you have not already added the values of the costs, you can do it from this matrix. Just select one of the cost entities and its attributes show up on the sidebar (see below).

Note how you can add distributions here as well.

Finally, you want to see the results of the model. Execute the model using the discrete event and Monte Carlo Simulators. To access these simulators, just select “Simulate” from the Action Diagram for the main process (“F Vehicle Failure Process). You can see the results of a single discrete event simulation below. Note that the gray boxes mean that those actions were never executed. They represent the rarer failure mode of an engine failure (assume that you change your oil regularly or this would occur much more often).

To see the impact of many executions by using the Monte Carlo simulator. The results of this simulation for 1000 runs is shown below.

As a result, you can see that for about a year in operation, the owner of this vehicle can expect to spend an average of over $1560. However, you could spend as much as over $3750 in a bad year!

For more detailed analysis, you can use the “CSV Reports” to obtain the details of these runs.

[1] From http://www.weibull.com/hotwire/issue46/relbasics46.htm accessed 1/18/2017

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.

Design

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.

Procurement/Manufacturing

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

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.

How to Best Migrate Your Data to Innoslate

Image result for migrating

Leaving your old tool might seem daunting, but Innoslate is a modern, cloud-computing tool that makes moving your data simple. Here are a few simple step to make migrating your data to Innoslate easy.

 

#1 Organize Your Data

Assess how much data you really want to move into a Innoslate. It’s just like moving from your home. Get rid of the stuff you don’t need and only move the really valuable items. You may find there is very little data that needs to be moved into a new tool. This is true of existing, long term projects, as well as new ones. By getting rid of the clutter, you can improve your practice significantly.

 

#2 Extend the Schema to Meet Your Needs

During step #1, you’ll want to make note of your project’s schema. Make sure that Innoslate can accept the schema changes you’ve made and easily import the data from a CSV file or other format. See how to make changes to the schema here: https://help.innoslate.com/users-guide/database/schema/ Innoslate offers  

 

#3 Check Your Data’s File Types

Innoslate’s Import Analyzer can accept many different file types. The Import Analyzer provides drag and drop import capability for .csv, .docx, .xml files. There is also an advanced importer for .xmi, .pdf, and .txt files. Innoslate already has built-in analytics to replace their functionality or at least has an open Software Development Kit (SDK)/Applications Programmer Interfaces (API) that allows you to replicate that functionality. If you were previously using modeling tools, you should use one that has XMI or some other capability to read files exported from your existing tool. Note that since you may be coming from what is essentially a drawing tool into a data-driven tool, you may have to redraw some of the diagrams. That’s really an opportunity to make sure that the diagrams do not contain errors. You can test the results of your models to ensure accuracy using the Discrete Event simulator.

 

#4 Archive Your Data

After you have imported all of your data into Innoslate, create a copy of your project. This is a great safety measure. You can save your data here.

 

#5 Baseline All Your Documents

Then make sure to baseline all the data that you originally imported into Innoslate.  https://help.innoslate.com/users-guide/documents/requirements/baselining/ Baselining allows you to create You can create copies of your original project.

 

#6 Need Help, Ask For It

With the new software as a service (SaaS) model, support is part of the package and not an additional charge. Use that support to help you in this move. Think of them as movers you have already paid for. Contact support at support@innoslate.com.

If you want to learn more about innoslate, request or free trial or contact us. If you want to see a tool that has all these features and provides the support you need, then check out Innoslate® at www.innoslate.com.

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.