Tag Archive for: systems engineering


In this blog, we define GAMP®5, the framework for a risk-based approach, with an introduction and conclusion provided by Jakob Khazanovich, Medical Device Solutions Consultant at Jama Software®.

This blog contains details sourced from the International Society for Pharmaceutical Engineering.

What is GAMP®5 and How Does Its Guidance Help Regulated Companies Using Computerized Systems?

When medical product companies decide to implement a new software tool, an important question arises regarding the level of computer system validation required to ensure the latest software complies with regulatory requirements and industry standards.

One major guidance document companies should reference to answer this question is Good Automated Manufacturing Practice (GAMP®5): A Risk-Based Approach to Compliant GxP Computerized Systems.

RELATED: Convergent Dental Selects Jama Connect® For Its Live Requirements Traceability


What is GAMP®?

GAMP® is a set of guidelines for producing quality equipment using the concept of prospective validation following a life cycle model. It was specifically designed by the International Society for Pharmaceutical Engineering (ISPE) to aid suppliers and users in the pharmaceutical industry.

GAMP stresses the use of critical thinking and risk-based assessments to justify the testing approach of a software tool. Its guidelines are widely supported by regulatory agencies and are used globally by regulated companies using computerized systems for compliance and validation.

What is GAMP®5?

GAMP®5 refers to the ISPE’s guidance document, “GAMP®5: A Risk-Based Approach to Compliant GxP Computerized Systems”. This GAMP®5 guide offers a framework for a risk-based approach to computer system validation in which a system is evaluated and assigned to a predefined category based on its intended use and complexity.

Though the steps in this guidance document are not mandatory, the framework provides a comprehensive approach to computer system validation that is generally accepted within the industry.

Additionally, its approach falls in line with the European EMA and US FDA regulations governing computer system validation, Annex 11 and 21 CFR Part 11.

Based on input from experienced IT, automation, and software practitioners, one of the reasons GAMP® guidance has always been successful is because it reflects the good practices for modern IT and software engineering teams.

RELATED: Jama Connect® and FDA 21 CFR Part 11

GAMP®5 Second Edition

Released in July 2022, GAMP® 5 Second Edition prioritizes patient safety and product quality over compliance and encourages the application of critical thinking. The overall GAMP® 5 framework, key concepts, and ICH Q9 aligned Quality Risk Management approach remain unchanged from the First Edition.

GAMP® 5 Second Edition supports standards set for forth by the FDA CDER (Center for Drug Evaluation and Research). Those standards call for “maximally efficient, agile, flexible manufacturing sector that reliably produces high-quality drug products without extensive regulatory oversight, where the vision requires moving beyond simply meeting minimum CGMP standards and towards robust quality management systems.”

This updated version of the guideline aims to help teams meet compliance expectations by offering best practices for IT teams, recommendations for optimal Quality Risk Management approaches, and ways to excel in software engineering, all while achieving better product quality and safety.


The risk-based approach to validation is a best practice seen in guidance documents and used by best-in-class medical industry organizations, many of which are Jama Connect® customers. In general, few tools require full validation but should have functionality confirmed through a subset of tests, the scope of which is determined based on the potential risk to the patient or product.

When your organization implements Jama Connect, consider consulting GAMP®5 guidance to avoid non-value-added over-validation and unnecessary constraints on your processes and systems.

DOD 5000

DOD 5000 Series

DOD 5000 Series consists of policy guidance and is backed by a collection of directives that describe a disciplined management approach for acquiring systems and materiel to satisfy valid military needs.

Six pathways of the adaptive acquisition framework: urgent capability acquisition; middle tier of acquisition (MTA); major capability acquisition; software acquisition; defense business systems (DBS); and defense acquisition of services. Up until a few years ago, it used to be that every program large and small had to follow the exact same acquisition process. Today, programs that are small and short-lived can follow a different process than that of a large multi-decade weapons system acquisition program. DOD 5000.02 policy encourages program managers to tailor, combine, and transition between pathways to create their own program strategies.

All programs regardless of the pathway share functional areas that must be considered during program execution. Acquisition Intelligence, Cybersecurity, Intellectual Property (IP) Policy, Mission Engineering, Systems Engineering, and Test & Evaluation are key areas every program must practice. Digital Engineering is a key constituent of program execution, and its vision is articulated by the Department of Defense 2018 Digital Engineering Strategy. It clearly highlights model-based systems engineering (MBSE) as a new approach to take. Digital Engineering crosses these functional areas and is where Jama Connect® assists program managers the most.

RELATED: Jama Connect®: Accelerating Systems Development with Requirements Management and Live Traceability™

Jama Connect® gives program managers and their acquisition team the ability to use Digital Engineering MBSE right from the start in an easy-to-use browser interface

The early phases of all DOD 5000.02 acquisition pathways require the definition of mission capabilities and needs. Instead of capturing this information in Word, Excel, or a SysML tool which requires a deep level of expertise; the Jama Connect solution will provide an Excel and Word-like experience but also segregate data as discrete model elements. An early acquisition MBSE approach in Jama Connect provides numerous benefits to the program team such as categorization of information; prioritization; version history of changes; status monitoring through workflow; real-time metrics on dashboards; exportable dashboard widgets for PowerPoint presentations; built-in document generation; activity monitoring; and more.

These MBSE data capabilities provide real-time monitoring of progress of the definition of mission needs and capabilities and more importantly gives all stakeholders the opportunity to participate in the capture and writing of the data. The learning curve of Jama Connect is five minutes to half a day compared to six months for SysML tools. This is especially important when there are urgent operational needs and other quick reaction capabilities need to be acquired. DoDD 5000.71 and DoDI 5000.81 both provide instruction for program management techniques to follow.

Jama Connect dashboard widgets.

DOD 5000.02 Acquisition Lifecycles

DOD 5000.02 instructions call for numerous reviews to take place throughout the acquisition lifecycles.

Acquisition Intelligence example use case: DOD 5000.86 Instruction provides policy and guidance on how to integrate intelligence information into the acquisition lifecycle. Typically, this is performed as a siloed activity with information captured in documents, passed back and forth, and reviews taking place in face-to-face meetings. Jama Connect enables the extension of the needs and requirements in the MBSE data model to threats, adversary capabilities, and adversary intentions. Jama Connect’s Live Traceability™ gives the program and intelligence teams the ability to share information and analyze it in a single model. Contextual collaboration mechanisms such as Review Center reduce cycle times spent on document review and approval. This integration of intelligence supports: (1) Characterization of the threat. (2) Identification of intelligence supportability plans, risks, and cost drivers. (3) Residual risk to inform stakeholders.

Cybersecurity example use case: DOD 5000.90 Instruction provides policy and guidance on how to incorporate cyber threat information produced by the Intelligence Community in development of their cyber security strategy and assessment of risk. Jama Connect lets the acquisition team see the relationships between designs and architectures and the identified risks. Live Traceability enables more informed decision making and could act as a conduit to the risk management framework (RMF) system. When new threats emerge, Jama Connect can provide instant impact analysis to a program’s existing mission requirements.

Systems Engineering example: DoDI 5000.88 begins by stating that engineering begins “at the identification of a military need and continues throughout sustainment of the end item.” Jama Connect can be used during all phases of the acquisition lifecycle and allows a systems engineering discipline to become central to program management rather than a siloed activity. Mission needs are captured in Jama Connect as discrete elements rather than Word documents or PowerPoint slides and can be reviewed, approved, and captured in the concept baseline. An element approach (aka digital engineering) allows for the easy consumption of data by digital tools in the tool ecosystem.

As ME products are developed in response to the mission needs and provide mission-based inputs to the requirements process, Jama Connect will establish trace relationships between needs, ME products, and the requirements. Live Traceability gives the ability for any stakeholder at any time to see the most up to date and complete upstream and downstream information for any requirement — no matter the stage of systems development or how many siloed tools and teams it spans. This enables the engineering process to be managed through data, and its performance improved in real time.

DoDI5000.88 calls for many technical and assessments throughout the life of a program. Digital engineering reviews in Jama Connect give the technical and non-technical engineer to not only redline, comment on, provide approval for the data itself, but allows for teams to give traceable reference. If the technical review is that of requirements, then reviewers would have the context to see the related mission needs, any analysis, architecture, any tests, as well as understand the evolution of change to each individual requirement in that review. Reviews in this manner provide significant reduction of cycle times and retains a traceable audit trail of commentors and approvers.

Jama Connect Review Center

Jama Connect Review Center, participant progress view.

RELATED: Ensure Product Quality with These Review Process Best Practices


Jama Connect can provide capabilities to assist government program management teams execute parts of the adaptive acquisition framework and tie together information via Live Traceability and collaboration mechanisms. Program decisions are informed by real time data and is accessible to engineering and non-engineering stakeholders alike.

In summary, there are many opportunities to use Jama Connect as a key enabler of Digital Engineering across all phases of the adaptive acquisition framework no matter which pathway is chosen.

Risk Traceability

Incorporating Risk Traceability into Manufacturing Production Software and Preparing for the Transition from CSV to CSA


Over the years, the burden of Computer Systems Validation (CSV) has resulted in medical device manufacturers avoiding implementation of automated manufacturing production systems or upgrading long-outdated versions of software. As part of the FDA’s ‘Case for Quality’ initiative in 2011 to study quality best practice in medical device manufacturing, the FDA found that the burden of compliance, such what is expected for Computer Systems Validation (CSV), deterred technology investments and as a result, inhibited quality best-practice.

As an outcome, the FDA is expected to release a draft guidance in 2022 that outlines their new approach of Computer Software Assurance (CSA) for Production and Quality System Software. The goal is to improve software quality by focusing on the software’s impact to patient safety, impact to product quality, and impact to quality system integrity. Using a risk-based approach, manufacturers can spend more time testing to ensure software meets its intended use, instead of ensuring test protocols and reports are fully scripted are error free.

As the key to right-sizing CSA activities is based on risk, managing risk, and risk traceability and incorporating is a key activity. And there’s no need to wait for the publication of the FDA CSA draft guidance, medical device manufacturers can incorporate these risk management and traceability practices now in their CSV activities.

Keep reading below for best practices on how to extend risk management and risk traceability from the medical device development to your manufacturing production software used to manufacture your devices.

Main Points for How

Consider the product risks and hazards

Even though we are discussing manufacturing production software and the software used on manufacturing equipment, the first step is to consider the product risks and hazards. Start with your master list of hazards, hazardous situations, and associated harms developed during medical device development and determine where and how failures in the manufacturing production software and production equipment can result in those risks and hazards. These are the areas to consider as the highest risks to control, mitigate, and validate.

Next, perform additional risk analysis from the lens of the environment and manufacturing personnel that will operate said equipment and software. It is important to also protect the environment and prevent injury and harm to those interacting with the equipment. You don’t want the unintended release of hazardous chemical reagents or equipment fires that could have been prevented with built-in high temperature shut-down feature.

RELATED: Managing Complexity in Systems Engineering for Product Development with Live Traceability

Create manufacturing production software intended uses and requirements

Just as one determines the intended use and design input requirements of a medical device, the same is to be done for the manufacturing production software and equipment. Incorporate the necessary features as manufacturing requirements (analogous to the design inputs of your medical device) that address the risks identified in the previous step.

One example is based on risk of the product and demonstrates how risk traces from the development of the medical device. Consider the design of a semi-automated assembly machine for a drug-delivery device. The machine aligns and press-fits together two plastic injection-molded halves of the delivery sub-assembly. One of the main product associated risks is ensuring proper flow efficiency to ensure the proper amount of drug is delivered correctly and to the proper anatomical location.

In this case the risk traceability and translation to the assembly machine design inputs is:

RELATED: Application of Risk Analysis Techniques in Jama Connect® to Satisfy ISO 14971

Perform software testing and equipment validation based on risk

Once ready to test the production equipment software and perform equipment validation, incorporate, you guessed it, risk. All manufacturing requirements then need to be verified, however, scale the amount and type of testing for each manufacturing requirement based on the risk. Aspects of the software and equipment that are of high risk, such as preventing severe harm to operators, or the end users and patients of the medical device will have more testing and documentation than those of lower risk.

Document risk traceability of testing and equipment validation

Just as documenting risk traceability for medical device is important, it’s also important for manufacturing production software and equipment. Using a tool like Jama Connect® makes it easy to link your master list of hazards, hazardous situations, and harms to your manufacturing requirements for manufacturing production software and equipment. This increases consistency and efficiency in the risk analysis and prioritizing efforts on where it matters for patient and operator safety. The interface of Jama Connect® also makes the traceability and documentation of the associated testing and validation easy to visualize, alerting teams to gaps and incomplete testing.


Extending risk traceability from your medical device development to your manufacturing production software and equipment brings focus to what can impact patient safety and scales the testing and validation work appropriately. Incorporate risk and you’ll also be well on your way for the upcoming FDA transition from CSV to CSA.

Systems Engineering

Editor’s Note: This blog was originally published through IEEE Innovation at Work, “Managing Complexity in Systems Engineering for Product Development with Live Traceability,” by author Nikhil Rai, IEEE Senior Member, Senior Director of Product and Solutions Marketing at Jama Software.

Systems Engineering for Product Development with Live Traceability

Complexity of Product Development is Exploding

In today’s world, technological innovations across embedded systems, the Internet of Things (IoT), and artificial intelligence (AI) are aggressively pushing the envelope on product complexity and accelerating digital transformation. The next generation of autonomous cars, electric vehicles, robots, and space shuttles are all complex systems that need to seamlessly interact with multiple layers of software, hardware, and humans across different environments.

Because complex technology products require intricate interfaces with various systems or sub systems, there is an inherent challenge of coordinating the multiple development teams, who are often geographically spread across the world. Furthermore, large teams typically work on different stages of product development within their own silos. The different development tools, architecture, and IT environments used across various teams and organizations can significantly add to the challenges of developing new technologies.

Manufacturing sectors will reap the AI technology benefits of enhanced monitoring and supply chain optimization. In financial institutions, AI techniques can be used to identify which transactions are likely to be fraudulent. Through AI, the industry could also adopt fast and accurate credit scoring while automating manually intense data management tasks. Disruptions in the transport and logistics realm could include autonomous trucking and delivery on the roads and automated picking in warehouses.

RELATED: Systems Engineers Career Path – How to Elevate

Reality of Today’s Complex Systems Development

Most complex system development starts with defining user needs and requirements, which involves design, software, and hardware teams developing deliverables that ultimately get tested and integrated for delivering the product. Given the disparate nature of these teams, there is an inherent need to optimize and continuously keep track of systems information from concept to development and delivery. However, there is often a gap in terms of how information is consumed across engineering departments, as well as its availability and traceability. The digital thread in engineering today is still a collection of different tools, which means traceability is usually accomplished in a cumbersome and manual fashion via time-consuming meetings and disconnected documents.

Challenges in Traceability

Traceability is a key both to product development and software engineering for tracking the systems development lifecycle. Helpful in achieving regulatory compliance, traceability can also be used within software engineering for running test cases and gaining valuable insights.

While some organizations make it a point to map product development stages and improve traceability to gain these benefits, traceability is often considered after-the-fact by others. This means that once an issue is identified, there is effort required to trace back where the error originally occurred to prevent that same failure from occurring in the future. This approach can cause multiple cost overruns, product delays, and inefficient management of change impacts. Think of addressing a car recall or fixing a complex medical device or industrial equipment— the costs can be enormous. By emphasizing the importance of traceability from the start, organizations can avoid the extra effort and cost associated with implementing it after an error has been made.

RELATED: Requirements Traceability – How to Go Live

Live Traceability™

The solution lies in bringing a practical approach of Live Traceability™ to the systems engineering world. Optimizing and measuring the systems development process with Live Traceability is a crucial competitive advantage that companies can leverage. For any complex product, systems, or software development, the requirements and user needs form the first level of abstraction. Live Traceability can be measured and monitored by using systems requirements as an anchor to manage information used in different stages of the systems development lifecycle.

At Jama Software, we define live requirements traceability as the ability for any engineer at any time to see the most up-to-date and complete upstream and downstream information for any requirement— no matter the stage of systems development or how many siloed tools and teams it spans. Live Traceability of system requirements is required by industry standards to ensure product safety and forms the foundation for digital engineering and model-based systems engineering. This enables the engineering process to be managed through data and its performance improved in real time.

Through better requirements management and a focus on traceability, companies can improve their systems development performance with higher quality products and improved cycle times. The industry is now embracing the idea that to improve engineering efficiency within the systems development process, we need to continuously monitor and measure traceability.


Adopting MBSE

This blog contains excerpts from a whitepaper titled, The Comprehensive Guide to Successfully Adopting MBSE, written by Lou Wheatcraft. 

Adopting MBSE: Challenging the Status Quo in Product Development

For product development teams to successfully implement a practice such as model-based systems engineering (MBSE), it requires the willingness of an organization to perhaps change processes and even tooling. Often, companies choose to stay with the status quo, but at what cost? Here’s a look at how adopting MBSE might help your teams, and the cost of not adopting MBSE. 

Understand the Need to Move for Change 

What is the Risk of Staying with the Status Quo? 

For the MBSE Implementation Project Team to be successful, management must recognize the need to change. How can management be convinced? Three words – RETURN ON INVESTMENT (ROI)!  

Think about these questions: 

  •  What has been the impact of the current, poorly executed product development efforts? 
  • What is the overhead associated with the current document-based approach?  
  • What are the current quality issues facing the organization that is catering it to profits: Failures, recalls, returns, warranty costs, lawsuits, negative reviews on social media, decreasing market share?  

The ROI argument usually works with management especially when they can be convinced that by investing in a data-centric practice of SE tailored to the organization’s needs, the overall product development process, product quality, time to market, and profitability can be improved as discussed previously. 

What is the ROI of Adopting MBSE? 

To entice anyone — especially an entire organization — to make a change, proving ROI on the resource investment is key. Here are some key points to consider: 

  • The more effective the Systems Engineer (SE) processes, the less rework and fewer cost and schedule overruns.  
  • By moving to a data-centric practice of SE, the probability of achieving a competitive advantage can be improved by removing obstacles to being able to deliver products on time, on budget, and that meet or exceed customer and quality expectations. 
  • From a cultural perspective, the personnel responsible for product development and will be most affected by the change must be shown, and how the change will benefit them.  

Visit our interactive content page for ROI Calculators and more! 

Combating Opposition to Change

A good process is not one that is something people have to do in addition to their job, rather it is one that helps people do their job more effectively. – LOU WHEATCRAFT

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

Get Team Buy-In

To get buy in from the product development teams, the MBSE Implementation Project Team must: 

  • Understand what problems the product development teams are having and show them how moving to a more data-centric practice of SE will address those problems and make their job easier than the current document-centric approach. If the change results in more work or makes communication harder, the battle will be lost. For example, the lead engineer or project manager may already be over their head and working 50–60-hour weeks. Requiring them to learn how to use a new tool or set of tools and implement a new process may be too much of a load for them to bear! However, if they are provided with a dedicated person that has the training, knowledge, and experience in the new processes and tools to help implement the changes and train other team members, they will be much more receptive. They will also be much more receptive if this results in them having to work fewer hours and having fewer crises to deal with each day! 
  • Be convinced of the utility of the changes, how the changes result in a better product and result in less rework for them. Frequently the reason project team members are working long hours is because they are always fighting fires, going from one crisis to another, which resulted from the lack of the proper SE tools, processes, data, and information in the first place! The culture needs to be changed from one of firefighting to one of fire prevention. As time passes, they will become advocates for the changes that have been made and welcome further change. 

The MBSE Implementation Project Team’s mission statement will be something like: “Improve our product development processes by adopting MBSE within the organization by moving from a document-centric to a data-centric practice of systems engineering.” Along with this mission statement, they will need to define a set of specific goals and objectives along with measures of success. Once defined, they will need to get agreement from management on these goals, objectives, and measures. 

RELATED POST: Systems Engineers Career Path – How to Elevate

Get Management Buy-In 

Project success is dependent on having a high-level, C-suite project champion and getting management buy in. A major challenge for the project will be convincing management and other key stakeholders that it is time for adopting MBSE and moving from a document-centric to a data-centric practice of SE and knocking down the walls of resistance. Some common reasons for them not wanting to move to a data-centric practice of SE include: 

  • “We have been doing product development using our current processes for years, why should we change?” 
  • “Implementing SE from a data-centric perspective may work for others, but not for us.” 
  • “This all seems very complicated, we don’t have the knowledge, experience, or tools.” 
  • “Our current SE work products, like requirements, are managed in an RMT. FFBDs, and other diagrams we are currently using are models, so aren’t we already adopting MBSE?” 
  • “It is too expensive to procure the needed SE toolset, maintain the tools, and train our people to use those tools.” 
  • “We don’t have the budget to incorporate SE from a data-centric perspective at this time.” 
  • “The expense and associated process to get new SE toolset installed on organizational computers is too great.” 
  • “We would have to make signification IT infrastructure upgrades to accommodate the additional volume of data and performance requirements of the new SE tools.” 
  • “We deal with the development of classified systems; controlling access and maintaining security will be too difficult.” 

Sound familiar? Often the pushback can be attributed to a lack of understanding the risks associated with the current state of the organization, understanding the benefits of moving toward a more data-centric practice of SE, and what level of SE capability is appropriate for the organization.

RELATED POST: Whitepaper: A Path to Model Based Engineering (MBSE) with Jama Connect

Adopting MBSE: The Road to Success 

To inspire a shift from a document-centric to a data-centric practice of SE in your organization, it’s vital to show both teams and management the value and expected ROI in doing so. Moving away from a current way of doing things isn’t always an easy road, but the risks of staying with the status quo are often great—and the rewards for changing processes and culture are often even greater.  

An organization will be successful in practicing SE from a data-centric perspective when it is considered to be the “gold standard” for system development within the organization. However, the road to success is long — it takes very strong, unwavering leadership and experience to get this done right. It is human nature to try to push back and say that it isn’t possible, but it is.   


Systems Engineers Career Path

Most Systems Engineers we speak with have a common perspective on their role within their organization. Systems engineering as a concept is understood and supported by leadership. And, if systems engineering best practices are followed across all engineering disciplines, leadership also acknowledges the benefits the organization can realize. However, leadership will not force change on engineering disciplines (software, hardware, electrical, risk, verification, and validation) to remove barriers to systems engineering best practice adoption. This leaves most Systems Engineers in the challenging position of possessing responsibility for achieving systems engineering benefits without the authority to ensure engineers adopt best practices. 

The good news is that there is a way out of this situation. The first step to elevating your career is to realize that managing the product engineering process through data is the key and that the Systems Engineering role is the natural role to lead this. For most organizations, the product engineering process is the only process in the company that is not managed through data. No one can go to a system and see the status of all product requirements and where development, integration, risk, and testing stand at any point in time. There is no way to manage by exception. There are no alerts that requirements are not covered, test cases are missed or that hardware made a change that now impacts software. Most organizations have come to accept this state of affairs and try to manage the process through endless meetings, emails, and Slack messages.   

Until the product engineering process is manageable through data, Systems Engineers will be stuck in their current trap — endlessly trying to address issues after the fact, holding unwanted meetings, and the uphill battle of trying to persuade changes in behavior. Below is a 3-step approach that Systems Engineers we work with have used to solve this organizational challenge and have thereby elevated their careers. As with any process change, it is best to do it in stages. You can start with the following steps. 

  1. Baseline current process performance 
  2. Build the business case for change to gain support 
  3. Deliver quick wins

RELATED POST: How to Overcome Organizational Barriers to Live Requirements Traceability

Step One | Baseline Current Traceability Performance 

The first step towards moving the organization to manage the product engineering process through data is to baseline current process performance.  The best place to focus the baseline effort is on traceability since it spans the entire product development process, is a data management concept that is understood, enables systems engineering benefits, and is required by industry standards. To ease the baselining effort, we’ve developed a Traceability Diagnostic that you can use to assess your current situation. The Diagnostic inventories traceable data, the systems in which they reside, and your current Traceability Score™. This is a few-hour effort and forms the basis of the business case in step two.

In this no-cost, guided process, we’ll help you:

  • Understand the monetary risk of your current Traceability Debt™
  • Uncover the quantifiable ROI of moving to Live Traceability
  • Develop a clear plan of action, cost, and timing to achieve Live Traceability

To Get Started With Your Free Traceability Diagnostic,  CLICK HERE

Step Two | Build Business Case for Live Traceability™ 

Once you have established a baseline, it is now possible to build a business case for change that will resonate with leadership. Based on your baseline, the Traceability Diagnostic determines the probability of negative product outcomes (defects, delays, rework, cost overruns, etc.) and the magnitude of these events. This quantifies the risk of maintaining the status quo and doing nothing. In addition to the risk reduction potential of Live Traceability, the Diagnostic also calculates the engineering productivity gains from eliminating the need for time-consuming, manual, after-the-fact traceability efforts. 

Step Three | Start with Quick Wins 

Once you have secured support to move forward, it is common to be able to deliver some quick wins to the organization shortly after project kick-off.  The typical place to start is the painful and time-consuming after-the-fact traceability efforts.  For example, continuous syncing between requirements and software development task management in Jira or Azure DevOps can be set up quickly to automate traceability from requirements to user stories, eliminating a large source of risk and manual, after-the-fact traceability effort. Once quick wins are shown, organizational momentum increases even further and puts you on the success path to begin managing the product engineering process through data.     

Clients of ours that have taken this approach have received significant recognition, been promoted into roles with greater leadership, and have increased their external visibility through speaking engagements. Live Traceability is a unique opportunity to elevate one’s career. Don’t miss the chance. 


This is Part 2 of a blog series covering a whitepaper titled,The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE. Visit these links for the rest of this series: Part I, Part III, and Part IV.

Adopting MBSE

What does it mean to practice SE from a data-centric perspective?

Successfully adopting MBSE and moving toward a data-centric practice of SE is much more than just acquiring and using a specific tool, set of tools, or focusing on the use of a specific type of model. As stated previously, MBSE is not just about the development of SysML or other language-based models nor just practicing model-based design. MBSE is itself made up of puzzle pieces, all of which contribute to the successful adoption of MBSE. To be successful, the following ten areas of capability associated with data-centricity must be addressed.

01: Holistic Product Development

A key tenet of data-centricity is taking a holistic view of product development and managing data and information within an integrated/federated environment. The focus is on multidiscipline, collaborative, project teams (e.g., integrated product teams). Many organizations still operate in organizational silos, with team members’ loyalty toward their specific silo rather than to the project team. When issues occur, the tendency is to blame those in other silos. Each silo often has its own processes, specific toolsets, data, and artifacts. Often the data and information are generated independently from those in other silos and are not in a form to enable sharing. This can result in inconsistencies, correctness, completeness, and currency issues of the data maintained in these artifacts. When moving toward data-centricity, organizations must have a holistic view of product development, minimizing the silos, encouraging collaboration, and improving communications not only between team members but between different tools used to generate and maintain data and information. Rather than treating Systems Engineering separate from Project Management (PM), projects must integrate both sets of functions such that there is a single project team that does both functions.

02: Manage Product Development Across the Lifecycle

Rather than having tools that are specific to a given organizational silo, a key characteristic of data centricity it that related data and information that represents lifecycle activities and associated artifacts can be linked resulting in “digital threads” that link related information together across the product lifecycle. This linkage enables project team members to work collaboratively and establish traceability between needs, design input requirements, system analysis artifacts, diagrams, models, architecture, design, system verification artifacts, and system validation artifacts. Traceability aids in change impact assessment across the product lifecycle helping ensure completeness, correctness, consistency, and currency of the data and information and resulting artifacts.

03: Enterprise Level Data and Governance Policy, Processes, & Procedures

Because of the dependence of not just the project teams, but the overall organization on electronic forms of data and information and increasing threats associated with the security of this data and information; enterprise-level policies, processes, and procedures concerning data governance and information management must be defined, implemented, and enforced.

04: Project Level Data and Information Management

Within the context of the enterprise-level data governance and information policies, each project must include their specific implementation of these policies within their Project Management Plan (PMP) and Systems Engineering Management Plan (SEMP). Because of the importance of managing the project’s data and information, the project is encouraged to develop and enforce a project-level Information Management Plan (IMP). Other supporting plans (e.g., requirements management plan) need to comply with the data management policies within the higher-level plans for both the project and enterprise.

RELATED POST: The Real Intent of Model-Based Systems Engineering

05: Master Ontology

Terminology and language are key to successful communications not only between team members but between tools. For a given enterprise, an enterprise-level ontology (data dictionary and glossary) must be developed to clearly define specific terminology and relationships of various terms used within the organization and the project. This is critical when there are product lines, multiple project teams, and the need to share data and information between current projects as well as reuse data and information for future projects. Within the enterprise-level ontology, individual project teams can define their project-specific ontology consistent with the enterprise-level ontology.

06: Master Schema

Here the word “schema” is used to describe how the data and information are organized and managed within individual tools and associated databases. It includes the naming of individual data and information items, defining relationships between data items, and the import and export of data and information. From both an enterprise and project perspective it is important to define a master schema that the SE and PM tools within their toolset are compliant in order to enable data integration, shareability, and reuse.

07: Use of Attributes and Associated Measures

Data centricity enables the project to define and use attributes that can be used to manage project activities across all system life cycle stages. For needs and requirements, attributes can include rationale, priority, criticality, source, owner, traceability, risk, maturity of needs definition, needs and requirements definition status, design implementation, system verification, and system validation. Attributes can be defined to aid in reusability and product line management. Attributes can also be associated with key measures defined by stakeholders within their goals and objectives. These measures include key performance indicators (KPI), measures of suitability (MOS), measures of effectiveness (MOE), measures of performance (MOP), key performance measures KPP), technical performance measures (TPM), and leading indicators (LI). Data representing these measures and attributes can be used within the SE and PM tools to generate reports, dashboards, etc. which are used to better manage the project and system engineering processes providing managers near real-time status information and enabling them to identify and correct possible issues before they become problems.

08: Configuration Management

Adopting data-centricity, the project’s artifacts and underlying data and information are developed, analyzed, and managed holistically within the data and information model. Because the data and information are managed within the project’s data and information model, this model represents a single source of truth (SSoT) for the project. Rather than configuration control of each individual artifact represented by the data and information in the model, the project team can configuration control the model which represents the baseline state of the artifacts represented by the data and information in the model at any given time. “Visualizations” of the data and information in the form of the various artifacts represent the baseline version of that artifact. Even when these visualizations are extracted as reports, the SSoT is still the data and information model from which they were generated.

Note: for many organizations, this is often their biggest challenge in that it requires the organization to redefine its concept of configuration management. However, as stated previously, configuration management of individual artifacts requires significant overhead in both cost and time to individually configuration manage individual documents as compared to managing the data and information model that is representative of moving towards a data-centric practice of SE and PM.

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

09: Systems Engineering (SE) Tool Set

Data centricity requires projects to move beyond the use of common office applications: word processing, spreadsheets, presentations, basic drawing and diagraming tools, and requirement only management tools to define, analyze, record, and manage needs and requirements and other SE artifacts. Rather, projects must transform their SE process such that SE artifacts are developed using SE tools that are fully compliant with interoperability and data sharing standards, are consistent with the enterprise and project ontology, stores the data and information consistent with the project’s master schema, and allows linking of data and information across lifecycle activities and resulting artifacts. This data and information must be managed in a form that is shareable between the SE tools within the project’s toolset as well as shareable with the project’s PM tools. When selecting specific SE tools to be included in the project’s toolset, it is important that the project determine the types of information and methods of analysis that are needed based on their specific product line, culture, and workforce.

10: Project Management (PM) Tool Set

Data centricity also requires projects to move beyond the use of common office applications for project management e.g., budgeting, scheduling, cost management, risk management). Rather, projects must transform their PM process such that most of the PM artifacts are being developed using PM tools that are fully compliant with interoperability and data sharing standards, are consistent with the enterprise and project ontology, stores the data and information consistent with the project’s master schema, and allows linking of data and information across lifecycle activities and resulting artifacts. This data and information must be managed in a form that is shareable between the PM tools within the project’s toolset as well as shareable with the project’s SE tools. For example, Work Breakdown Structures (WBS) can be linked to Product Breakdown Structures (PBS) and physical architectures to enable management of budgets, schedules, resources, and risks associated with each system and system element within the product physical architecture.

Visit these links for the rest of this series: Part I, Part III, and Part IV.

To download the entire paper, visit: Whitepaper: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE

This is Part I of a blog series covering a whitepaper titled, The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE. Visit these links for the rest of this series: Part II, Part III, and Part IV.


In a previous paper, we discussed key questions concerning Model-based Systems Engineering (MBSE) including what MBSE is, its true intent, why organizations should adopt MBSE, and the benefits. If you haven’t read that paper, it’s worth taking a look. 

We made the point that the goal of an organization when adopting MBSE, is to move from a document-centric to a data-centric practice of Systems Engineering (SE) to realize the real intent of MBSE which is to develop, maintain, and manage a data and information model of the system being developed — along with a model of all the system life cycle process activities, resulting in artifacts, and their underlying data and information. 

This paper will go into more detail as to key factors associated with successfully adopting MBSE, what it means to practice SE from a data-centric perspective, and provide a methodology to define a road map tailored to your organization resulting in the successful adoption of MBSE. 

RELATED POST: The Real Intent of Model-Based Systems Engineering

Key factors associated with successfully adopting MBSE 

Sadly, the attempts of many organizations to successfully adopt MBSE often end in failure. The process of adopting innovative technology like MBSE and moving toward a data-centric practice of SE can be considered to be a project in its own right. There have been numerous studies and reports concerning factors of why projects fail, and factors associated with projects that succeed. When adopting MBSE, these factors must be considered. Organizations that are able to successfully adopt MBSE and move to a data-centric practice of SE address the following key factors: 

01 – Getting Corporate Level Management Buy-In and Support – Success Starts at the Top! 

In an earlier paper, we discussed issues associated with a document-centric approach to product development of today’s increasingly complex, software-centric products along with the benefits of adopting MBSE from a data-centric perspective to address these issues. There must be a project champion that can clearly communicate these issues and benefits at the corporate level in order to get buy-in across the organization. 

A key consideration when getting this buy-in is how these issues and benefits are communicated. The adage “know your audience” is important. A common mistake when approaching higher-level management is using terminology that does not address their needs in a language they understand. When getting buy-in concerning the company adopting MBSE, you must clearly communicate to them what MBSE is and how the organization will benefit in terms of outcomes they can relate to. Giving them a demonstration of a specific tool using a lot of technical jargon can result in them quickly losing interest. They are interested intangible outcomes of a proposed solution that addresses business-related issues (problems): less overhead, decreased time to market, higher quality, decreases in post-launch issues, fewer issues associated with a product being approved for use, increased profits, rising stock prices, and a growing company. They want to understand how adopting MBSE will result in these types of outcomes. 

02Forming a Dedicated Project Team 

Rather than leaving it up to individual project teams to each attempt to adopt MBSE, a corporate level dedicated MBSE Implementation Project Team (IPT) is needed. For smaller organizations and startups this IPT might be a single person. MBSE is just one puzzle piece in the larger set of organizational puzzle pieces. To be successful, the larger, integrated puzzle must be considered to ensure the MBSE puzzle piece will fit. Other puzzle pieces include data governance policies, information management plan procedures and work instructions, information technology (IT) infrastructure (networks, internet, clouds, applications, computing devices, etc.), the product line, product development processes, procurement processes, company culture, workforce, etc. A dedicated project team can deal with possible issues in all these areas from a corporate, holistic perspective across organizational silos enabling a successful adoption of MBSE, helping to ensure the MBSE puzzle piece can be integrated within the overall corporate puzzle. 

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

03Involving Key Stakeholders 

The various stakeholders involved in adopting MBSE must be included. These stakeholders must not only include the users, but other stakeholders that will be affected by the adoption of MBSE including those that will benefit, those involved in the activities required to adopt MBSE, and those from enabling and supporting organizations. Referring back to the puzzle analogy, stakeholders must be included that represent each of the above-listed puzzle pieces. Each stakeholder has expectations that must be addressed by the project team along with key drivers and constraints a successful project must consider in order to achieve a successful outcome. 

04 – Defining The Problem, Opportunity, Outcomes, Needs, and Requirements at the Beginning of the Project 

The project team and stakeholders at all levels of the organization must be aligned to a common understanding of the problem/opportunity that is driving the adoption of MBSE, to a common mission statement, goals, objectives, clear outcomes, needs, and requirements. Like any other project, these must be defined and agreed to from the beginning so that there is a clear roadmap to success and well-defined outcomes against which success can be measured. 

05 – Understanding the “Goldilocks Principle” 

The Goldilocks principle is about doing what is “just right” – not too little, not too much. When adopting MBSE and moving towards a data-centric practice of SE, the project team must understand the needs of the organization, what it means to practice SE from a data-centric perspective, and develop a practical and feasible roadmap. Delivering an MBSE capability that is too little can result in stakeholder expectations not being met, disappointment, and a failure of project teams to successfully adopt MBSE. Going overboard and implementing more than is needed can be overwhelming, turning people off to the concept and again a failure of project teams to adopt MBSE. 

This last point is especially important. “Just right” must be defined from a user perspective. The users are the product development project team members who will be conducting their project based on the processes and tools provided that will enable them to adopt MBSE for their project and move to developing their products from a data-centric perspective. They have expectations concerning being able to be more productive and effective. Meaning the processes and tools provided should not be viewed as things they have to do and use in addition to their job – resulting in more work; rather processes and tools they can follow and use that are an integral part of how they do their job – resulting in less work, a higher quality product with a shorter time to market. The new processes and tools enable them to deliver winning products: those that meet the needs of their customers, within budget and schedule, with the required quality. 

From a user perspective the following attributes must be addressed within the processes defined and tools selected for use: 

  • Full functionality; does what is needed, nor more, no less
  • Intuitive; easy to learn and use
  • Easy and fast to implement
  • Enable collaboration between team members, no matter their geolocation
  • Enable traceability of data, information, and artifacts across the system lifecycle
  • Enable change impact assessment across the system lifecycle
  • Reduces the time to define and manage needs and requirements
  • Supports verification and validation planning and execution
  • Tailorable to the organization’s product line, work instructions, and workflow
  • Helps ensure compliance with standards and regulations
  • Helps manage risk across the lifecycle
  • Enables management to track project status across the lifecycle 

Visit these links for the rest of this series: Part II, Part III, and Part IV.

To download the entire paper, visit: Whitepaper: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE

SysMLWith the trend of organizations practicing Systems Engineering to move towards what is referred to as “Model-based Systems Engineering” (MBSE), there are various perspectives as to just what is meant by MBSE. Similar to the old story of the blind men and the elephant, MBSE cannot be effectively practiced when viewed from just one perspective (requirements, models, patterns, standards, industry specific application, etc.). To successfully practice MBSE, wise systems engineers recognize and use each perspective as appropriate to their specific needs. Based on these needs, they choose the appropriate capabilities, tools, and visualizations that will meet their needs. One size doesn’t fit all.

The degree to which the data and information is captured and managed is driven by the needs of the organization and projects from a business and technical perspective based on the size and complexity of their systems, their product line, culture, processes, workforce, their diversity and complexity of supply chains, and types of engineering information that comprises a technical baseline for their system of interest.

SysML and other language-based modeling tools

MBSE is a concept that is maturing and means different things to different people.  To some practitioners, MBSE is equated to the use of SysML and other language-based modeling tools. With these tools, practitioners can develop detailed analytical, behavior, and architectural models of a system, with a primary focus of functionality, performance, and interactions between various entities defined to be part of the system being modeled. These types of models are useful tools for system analysis, developing simulations, and creating what is referred to as a “digital twin”.

To others, what they are calling MBSE is really Model-based Design (MBD). MBD design starts with a set of requirements and using various language-based modeling tools to architect and design a system, develop simulations to assess the behavior of the system, and then develop a set of design output specifications to which the system is built or coded. Often the MBD activities are completed in a silo separate from the other SE lifecycle process activities.

MBSE is much more than SysML!

The above language-based modeling approaches do not address the true intent of MBSE. While these capabilities can be useful, MBSE is much more than using language-based modeling tool to develop analytical, logical, behavioral, and architectural models.

The goal of an organization, when adopting MBSE, is to move from a document-centric to a data-centric practice of Systems Engineering (SE) so as to realize the real intent of MBSE which is to develop, maintain, and manage a data and information model of the system being developed along with a model of all the system life cycle process activities, resulting artifacts, and their underlying data and information.

MBSE is not really about any particular type of model or visualization of data and information – whether that be a model, diagram, report, document, sets of needs, or sets of requirements – but is about the underlying data and information model that enables consistency across the data and information that represents the various models and visualizations.

The data and information model that must be developed should represent SE artifacts generated during the product development process activities across all lifecycle stages. Information associated with the elicitation of stakeholder needs and requirements, lifecycle concepts definition, analysis, and maturation, deriving an integrated set of textual needs, transforming those needs into sets of textual design input requirements, verification the system meets those requirements, and validation that the system meets the needs must also be captured within the data and information model. In addition, relationships and dependencies of the individual data items must be captured (traceability) in order to help determine and ensure consistency across all lifecycle stages, prove compliance with standards and regulations, as well as help assess the impact of changes made to any of the data items across all lifecycle stages.

Can my organization adopt MBSE without using SysML or other language-based tools?

Sadly, there are many organizations that have a misconception concerning what the true intent of MBSE is – as a result they think that MBSE is not for them.

In a recent conversation with a system engineer, I was told that her organization was not going to adopt MBSE because they don’t see the utility of developing complex SysML models of their products. In addition, she noted that to do so would require a change in how their managers and engineers think based on the SysML standard as to how to construct models and the specific terminology used.  To them SysML modeling is not intuitive, has a large learning curve, and has little apparent utility and return on investment – for their organization, especially for their product line that has a minimum amount of software and complexity.

My response to her was: MBSE is not SysML!

I told her what the true intent of MBSE is to practice systems engineering with a data-centric perspective, establishing the capability to capture, manage, access data, and manage the interrelationships between SE work products can be accomplished through a variety of methodologies, which range from the establishment of a single relational database to a virtually integrated, but distributed, database by means of a federation (or data map/index) of disparate data sources.

The resulting data and information model can be captured using a variety of SE tools and applications. To effectively manage our ever increasing complex, systems there are benefits to managing this underlying data and information in such a way it can be shared across the system life cycle process activities, shared between the various SE tools used to create and manage this data and information, and shared between organizations involved in the development and operations of the system of interest. This sharing will help ensure correctness, consistency, and completeness of the data and information typical of our ever increasingly complex systems as well as enable collaboration between not only the project team members, but also external stakeholders involved in the development of the system.

Parting Thoughts

The answer to the question: “Can my organization adopt MBSE without using SysML or other language-based tools?” is YES!

Since one size doesn’t fit all, an organization must assess their needs and produce an MBSE solution that best fits its domain, product line (degree of complexity), and culture. As a minimum, they need to establish a capability to define and manage needs, requirements, verification, and validation across the system lifecycle.  These capabilities will allow the organization to build a data and information model of their products and systems engineering process activities and artifacts.

Based on these needs and desired capabilities, the organization can choose the appropriate SE toolset, update their processes, and train their people in these tools and processes.

Stay tuned for more to come from Lou Wheatcraft in the coming months. 

Model-Based Systems Engineering

For companies building complex systems whose stakeholders come from diverse engineering and business disciplines and need to have very precise and efficient communications, Jama Connect provides a collaborative, 100% web-based MBSE platform and a proven systems engineering approach to product development. Jama Connect provides a path to companies embracing MBSE where the application of collaboration, modeling, and methods reduces time and effort across the lifecycle. We call that path Jama Connect for Companion MBSE. 

Jama Connect for Companion MBSE is a single platform that combines requirements, architectures, behaviors, and V&V into a single model of the system by applying structure for the data; rules for the data; and a consistent interface language between parts of the system. A Jama Connect model provides engineers, project managers, business analysts, or any stakeholder, an organized way to address all aspects of the system consistently with the assurance of completeness. 

MBSE Defined by Industry 

The International Council on Systems Engineering (INCOSE) describes MBSE as the “formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing through-out development and later lifecycle phases.”  

NASA says MBSE “involves applying software-based tools to capture systems engineering evidence—typically called “artifacts”—in a systematic, disciplined way that allows people to manage complexity while communicating effectively across the life cycle of a system. 

What is a model? Don’t be fooled. 

It is a myth that a system model can only be created in a UML or SysML tool. Models can be expressed texturally, mathematically, visually, or physically and are meant to assist in helping people look at problems from different directions. Jama Connect represents a model as a project containing textural data items, views, graphical diagrams, and collaboration content.  

NASA’s definition provides a good deal of information, but they don’t even use the word “model” in their description. Lenny Delligatti, one of the most respected MBSE experts in the world wrote that, “A modeling method is something like a road map; it’s a documented set of design tasks that a modeling team performs to create a system model. More precisely, it’s a documented set of design tasks that ensures that everyone on the team is building the system model consistently and working toward a common end point. Without such guidance, there will be wide variance in the breadth, depth, and fidelity that each member of the team builds into the system model.”  

For example, a switch in a system is expecting the command “On” but for some reason receives the command “Start.” The switch will not function. The “On” and “Start” is the communication language and must be consistent. 

What in simple terms is a model then? Wikipedia tells us that a “model is an informative representation of an object, person or system” and INCOSE defines a model as “a simplified version of a concept, phenomenon, relationship, structure or system.”  

Before the invention of SysML, we used to use a document called an “Interface Control Document (ICD)” to describe the syntax of interfaces between different parts of a system, often physical. While essential, the ICD lacked the ability to describe scenarios which the interfaces would be used for. While a SysML model allows for communication of scenarios to be documented, it often lacks the ability to communicate the depth of requirement needed to describe the core workings of each part. This puts a heavy onus on the verification needed to ensure a part on its own was working as intended.   

While SysML is a wonderful language to represent abstractions and there are some fine tools out there that let you do some powerful things (I want to say something different here); it is still immature in the core aspects of systems engineering as it relates to communication, cross-domain collaboration, project management including cost and schedule, and oversight of verification and validation activities to name a few.  

RELATED: MBSE Made Easy – Overcoming the Organizational Challenges 

Jama Connect for Companion MBSE – The Nuts and Bolts 

Jama Connect for Companion MBSEMBSE in simplest terms is a framework for problem solving and system expression. In traditional systems engineering the domains of requirements, architectures, V&V and behavior are recorded and analyzed in a series of documents or data structures with loosely connected affiliations. Our Companion MBSE combines these four domains into a single model of the system by applying: structure for the data; rules for the data; and a consistent interface language between parts of the system, which in combination we at Jama Software call a “framework.” The framework provides engineers, project managers, business analysts, or any stakeholder, an organized way to address all aspects of the system consistently with the assurance of completeness. 

The Jama Connect for Companion MBSE framework takes requirements, architectures, behaviors, and V&V and forms their data into a query-able mesh. As development progresses the mesh becomes more stitched together. A built-in ruleset that uses a consistent language, constrains users to create the correct associations between the data elements. The framework’s ruleset eliminates risk that manual methods or tools lacking these constraints introduce. Jama Connect for Companion MBSE also supports leveling – representation of system decomposition within a model. Each successive level will follow the same consistent ruleset. 

Visualization is an important part of Jama Connect for Companion MBSE and plays a major role in communication of information and ideas. Data is easily visualized in an easy to navigate hierarchal tree view. This view not only displays the content of the data but also how the elements are tied to each other. These structures can be represented visually as a series of diagrams within the model.  


Requirements are typically the first data elements to be worked on in the model. Jama Connect for Companion MBSE’s flexibility gives users the ability to define unlimited levels of requirements – even those considered outside the “system” level. A Need Requirement which is an input to the systems engineering process, might consist of multiple types such as: user needs, ConOPS, business requirements, mission objectives, goals, regulatory requirements, or even constraints to name a few. A needs analysis is performed to flesh out those requirements which are human-centric. Systems engineers will analyze all the broad and at times abstract needs and then refine them into system level requirements that are representative of the system and might describe all the functions that the system shall deliver as well as non-functional characteristics such as performance or reliability of the system.  

In Jama Connect each need and system requirement is captured as a unique entity with its own ID. As a single entity it can then be managed, version controlled, and linked to other entities. When using Jama Connect for Companion MBSE framework, it provides mechanisms that keep needs and system requirements appropriately leveled and describe how they are linked to each other. This link itself also has a name and is called “derivedReq” which is similar terminology used in the SysML language. 


Behaviors assist the systems engineer in identifying the functions, sub-functions, and interactions that the system performs. Behaviors can be elicited from needs and requirements through techniques such as use cases, activities, states, interactions, sequences and more. Behaviors are most often in the form of a verb (ex: regulate voltage, make deposit, heat water, charge controller, brake…). Capturing behaviors adds value because they help explain how the system will work and sometimes more importantly, what could go wrong. Behavior can assist in establishing the cost and complexity of the system. Functions can be analyzed and become a deciding factor for which requirements are then used to build the system.  

Jama Connect for Companion MBSE

In Jama Connect behaviors can be richly annotated so one can capture the full reasoning. This is extremely useful to stakeholders that are not necessarily modelers yet need this information to make informed decisions.  


Application of MBSE is not complete without tying in architectures and making them be a central point of data. Architectures can be defined to conceptually represent functions of the system, structure of the system to subsystems, physical components of the system, or even behaviors of the system. An architecture is organized so that its own structure conveys meaning and relationships between its members. In Jama Connect, architecture objects can be managed as discrete elements where relationships to other data such as requirements can be made. It is also possible to create diagram to illustrate the relationships between the elements. 

Jama Connect for Companion MBSE


The verification and validation of the model and its entities within it is the last major domain for MBSE. Any element defined within the model can be verified or validated through means of analysis alone, review, trace demonstration, or even by test execution collecting pass/fail status. An MBSE model  

Jama Connect for Companion MBSE tests and validates system characteristics early with engineers and stakeholders for fast feedback on design decisions and phase it is believed that this will: 

  • Predict performance 
  • Verify design choices 
  • Meet stakeholder expectations 
  • Avoid failures 
  • Reduce risk 

Visualizing the model is an integral part of MBSE. As maturity of stakeholder’s fluency in MBSE increases, reliance on heavy text in some areas will decline. Jama Connect facilitates the best of both worlds by providing fully textural representations of data as well as diagrams that can easily be annotated to describe the purpose behind the “line” the connection between two objects.  

Jama Connect for Companion MBSE

Why Jama Connect for Companion MBSE? 

The inefficiency of non-integrated data leads to wrong decisions. When MBSE is done properly, the result is an overall reduction of development risksJama Connect for Companion MBSE provides a flexible framework that is 100% web browser based for capturing and communicating the model to all stakeholders. The model can be queried programmatically to surface up gaps in the model, display progress information, and be validated against the rules of the framework. These rules enforce users to create and relate data in a consistent way. Jama Connect for Companion MBSE gives users easy graphical and textural views of information in real time and is structurally SysML ready if mature organizations wish to integrate Jama with these specialized tools. Most importantly, users do not need lengthy indoctrination into the semantics of modeling which is required for modeling tools. Jama Connect as a data-centric tool, does not have this barrier and so is much easier for every stakeholder to adopt.