Tag Archive for: MBSE

This is Part 4 of a blog series covering a whitepaper titled, The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE. Visit Part I, Part II, and Part III.

04: Determine the Future State the Organization Needs to Be At

The descriptions made previously for each of the ten areas of capability represent the level of capabilities an organization should be at for a complete transformation from a document-centric to data-centric practice of SE. However, for each area, there is a range of capability levels, it is not just an either-or determination.

It is important for the enterprise to decide how, and to what extent, they are going to address each of the ten areas resulting in reaching the future state that is best for their organization. This decision must be based on the needs of the enterprise while being scaled to the level of rigor that allows the system development life cycle process activities to be performed by the projects with an acceptable level of risk and that will result in the needed outcomes.

It is important to realize that this journey towards practicing SE from a data-centric perspective can be made in a series of small steps. The enterprise doesn’t have to jump to a completely data-centric practice of SE at the beginning of their journey.

Some organizations may want to start with an electronic (vs. hard copy documents) requirement capability which supports allocation and traceability as well as can manage requirements (and other work products) across all system lifecycle process activities. This will help link requirements to the stakeholder needs from which they were transformed, to design outputs, and to verification and validation work products. The project can identify measures to track system development activities and identify and manage risks. The managers can then add the capability to use non-language-based diagrams as single entities without the underlying data, e.g., functional flow diagrams or context diagrams, and link the requirements to those diagrams. From there, the capability for analytical modeling can be added where the various diagrams, requirements, and other work products are visualizations of underlying sets of data (only if there is some benefit to be gained from doing so.)

The future state for each of the ten areas of data-centric capability can be expressed as a range of capability levels (CL) (e.g., 0 – 3). The MBSE Implementation Project team can define what capabilities are in terms of each of these levels. For each of the ten areas of capability, the level defined represents a goal which the project team will strive to meet along with any specific measurable objectives for each goal.

RELATED POST: MBSE Is Not SYSML

05: Identify the Gaps

Once the organization has assessed the current state of their practice of SE, they will need to address each of the ten areas in terms of what level of capability is best for the organization.

From an IT infrastructure requirements perspective, it is best for the projects to communicate the end state envisioned, so their IT department can provide the IT infrastructure and PM and SE toolsets that are scalable to be able to handle the needs of the organization for the envisioned end state.

Central to successfully implementing the levels of data-centric capabilities the organization needs to be at involves the selection of the SE tools that will be used. What capabilities are needed from an SE toolset depends on the product line, its complexity, green-field vs brown-field products, issues the organization is having and wants to address, and the workforce knowledge and experience.

Organizations need to understand what data and information best meets their needs and which set of SE tools they need to work with and manage this data. SE tools are like any other software application…one size does not fit all. The SE toolset that is best for an organization is the toolset that meets the organization’s requirements management, systems engineering, and modeling needs. Consider the outcomes needed as a result of using SE tools and the ROI resulting from these outcomes.

Table 2 shows the ten areas of capability, the present state (P) and future state (F) in terms of capability level as defined by the MBSE implementation project team. The difference between the present state and future state represents a “gap” which the project team will fill as part of their project.

 

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

06: Develop Action Plans

For each of the ten areas, the MBSE Implementation Project Team will develop an action plan. Each action plan represents a sub-project that will have its own mission statement, goals, objectives, measures of success, needs, requirements, budget, schedule, and stakeholders. Actions that will need to be addressed for each area include: 

  • Developing enterprise, business management, and business operations level policies, processes, and procedures needed to implement SE from a data-centric perspective.
  • Providing requirements to the IT department concerning the IT infrastructure needed, so these capabilities can be realized.
  • Selecting and procuring PM and SE toolsets that support the level of data-centricity decided on.
  • Training their managers and systems engineers in the use of the PM and SE toolsets and processes from a data-centric perspective. 

07: Implement the Action Plans

The project team will also need to assign a priority to each area of capability.It is important to realize that this journey towards practicing SE from a data-centric perspective can be made in a series of small steps. 

Successfully providing the capability to practice SE from a data-centric perspective requires three key things to be addressed: people, process, and tools. All three are highly dependent. One of the first areas that should be addressed is the selection of the SE tools that will be used by all the product development teams. Tool selection will be influenced by the data governance policies, data and information management procedures, product line, culture, and work force. The product development process will need to be updated to reflect the levels of data-centricity decided on as well as the SE tools selected. The product development teams will then need to be trained in the processes and SE tools.

Use a Pilot Project

There is an old saying “The devil is in the details.” To bring the people, process, and tools together, the MBSE Implementation Project Team should choose a pilot project. A pilot project can be used to demonstrate the benefits and ROI of adopting MBSE and moving towards a data-centric practice of SE. It will allow the organization to gain an understanding of what works (provides value, ROI), what doesn’t, what is liked, what isn’t liked, and tailor the processes to best fit the needs of the organization. 

This pilot project can develop an example PMP, SEMP, and IMP that can be used as a template for other projects. A project ontology and schema can be developed that can also be reused by other projects. If the product that is the focus of the pilot project is highly regulated, the pilot project can import standards and regulations into the SE toolset, enabling their reuse for future projects. Armed with the lessons learned from the pilot project, the organization can fine tune their various processes, policies, and work instructions to help the organization move closer to achieving their mission, goals, and objectives to practice SE from a data-centric perspective. 

Several key steps include: 

  1. Develop a practical process that implements the chosen SCL. The process needs to fit the product line, domain, and culture of the organization. The implementation needs to be tailored to the project. Don’t try to follow a process developed by a tool vendor for some other organization or product line. 
  2. Invest in training in the proposed chosen processes and SE tools. 
  3. Pick a pilot project to apply the process and assign the grass roots data-centric SE advocates to that project. 
  4. Define and use measures so metrics can help document the ROI can be clearly communicated concerning the agreed-to level of data-centricity. 
  5. Show management how measures and metrics maintained within the PM and SE tools will help them better track the health and status of the project, enabling them to be better project managers and systems engineers. 
  6. Encourage team members to be actively involved in organizations like INCOSE and join working groups whose members can aid the implementation process.
  7. Invest in an outside consultant who has a proven track record in implementing SE capabilities consistent with the chosen level of data-centricity and chosen SE toolset. Often tool vendors will be able to provide that person or persons who can work with both the MBSE Implementation Project Team as well as the product development pilot project team members. The tool vendor will be able to help integrate their tool into the organization’s IT infrastructure as well as help the pilot project team members tailor the tool to their needs and be readily available to assist when issues come up. 

Once the pilot project is completed successfully (an assumption), the project can be used as an example for future projects. The core grass roots folks can be spread out among other projects and mentor other project managers and systems engineers and train them and their teams in the concept of practicing SE from a data-centric perspective and in the use of the chosen SE toolset. 

In many of the cases where adoption has been successful, there has been both advocacy at the top as well as a strong grass roots support that has gradually gained acceptance across the organization, but typically only after one team has proven success. 

Parting Thoughts

Success is possible if the organization addresses the key factors of success discussed above. Of particular importance is understanding the overall puzzle in which the MBSE puzzle piece must fit as well as understanding the importance of all the pieces concerning the various areas of data-centric capabilities that make up MBSE. 

Developing the roadmap discussed as well as using a pilot project are key to success. Since one size doesn’t fit all, an organization needs to assess the data-centric capabilities that best fit its domain, product line (degree of complexity), and culture. The level of capability an organization establishes needs to be tailored to the size and complexity of systems developed by the organization, whether small, medium, or large projects. 

Based on the needs of the organization and level of SE capability they choose, they will need to choose the appropriate SE toolset, update their processes, and train their people in these tools and processes. 

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.  

Thank you for joining us for tips on successful MBSE adoption!

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

This is Part 3 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 II, and Part IV.

Developing a roadmap to successfully adopting MBSE within your organization

In this section, we provide a general approach or roadmap to be used in your company’s journey in successfully adopting MBSE within your organization. We say “journey” because that is what it is. Transforming an organization doesn’t happen overnight. There are a lot of pieces of the puzzle to address so it is important to take small steps and not try to do everything at once. Success includes addressing the key factors of success discussed earlier and define a roadmap. This journey could take several years depending on the size of your organization.

As stated earlier, the organization should form a dedicated MBSE Implementation Project Team with membership from each of the key organizational elements that have a stake and role in the adoption of MBSE within the organization. A general roadmap the project team can follow is shown in Figure 1:

Figure 1: Roadmap to Successful Adoption of MBSE

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

01: Get Management Buy-In

As discussed earlier, 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 to adopt MBSE and move 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 doing 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 (Goldilocks principle discussed earlier).

02: Understand the Need to Move Toward a Data-Centric Practice of SE

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 it… 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.

The more effective the 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 how the change will benefit them. Changing culture is often met with opposition and existing stovepipes/silos often resist change.

To combat this opposition, determine which stakeholders are for and against the change and why. For each individual or group, identify their concerns and devise a strategy to get the change adversaries to become change advocates. Start with those stakeholders that have the most influence and convince them by addressing their concerns. The aid of other stakeholders may need to be obtained to help influence those that oppose the 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

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!

People at all levels must 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: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

03: Access the Organization’s Current Practice of SE

To do this, they need to first assess the organization’s current state of practice of SE in terms of the ten areas of capability associated with data-centricity discussed previously. Table 1 shows an example of what the results may look like for organizations that are firmly rooted in a document-centric practice of SE. Sadly, this is the state of many of today’s organizations!

 

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

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

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.

Introduction 

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. 

02 – Forming 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

03 – Involving 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. 


In January 2020, NASA reported that Model-Based System Engineering (MBSE), “has been increasingly embraced by both industry and government as a means to keep track of system complexity.”

And in order to help facilitate accelerated adoption of MBSE, we’re proud to introduce Jama Connect® for Traceable MBSE™.

Jama Connect for Traceable 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.

Accelerate Your Systems Development

Jama Connect for Traceable MBSE provides a path to companies embracing MBSE where the application of collaboration, modeling, and methods reduces time and effort across the lifecycle.

With this solution, you’ll get:

  • Framework aligned to industry best practices from INCOSE and SEBoK
  • MBSE Quick Start Guide
  • Document export templates and reports aligned with systems development
  • Standard features of Jama Connect including requirements management, test management, live traceability, review center, realtime collaboration, reuse & baseline management, workflow & configuration management, diagramming
  • Consulting and training customized to your teams’ MBSE processes

Download the solution overview to learn more about Jama Connect for Traceable MBSE.

An organizational paradigm shift from document centric to model-based systems engineering can be daunting. The learning curve for systems engineers can be steep and the return on investment is often not immediately apparent.  

In a recent workshop on MBSE adoption, we walked through how Jama Software for Traceable MBSE™ can be used to eliminate common MBSE challenges and provide tactics to help teams eliminate the barriers to broader adoption. We will demonstrate how Jama Connect’s Traceable MBSE can be used to streamline a collaborative, data-driven approach and provide more immediate systems engineering value to larger numbers of stakeholders.  

In this demonstration, we cover: 

  • Using Jama Connect to facilitate implementation of MBSE
  • Benefits of Traceable MBSE to the broader stakeholder community  
  • Keys to eliminating documents
  • Leverage OSLC and REST for Cross Tool linking

Below is an abbreviated transcript and a recording of the workshop.

In today’s hyper-connected world, we’re not only seeing increasing complexity of systems that are being built, but also experiencing increasing technological and sociological challenges in the work setting to develop those systems. Jama Connect helps address these challenges. Organizations can execute their MBSE journey without the headache of modeling languages or the licensing and rolling out of complex systems modeling tools.

Jama Connect for Traceable MBSE is a completely web-based application that is designed to make it easy for any stakeholder technical or non-technical to create models, consume data and participate in a collaborative systems engineering process. The Traceable MBSE template comes with data types to capture and segregate different types of requirements, behaviors, architecture, interfaces, and V & V data. It also has a structural template already laid out to organize the data and help users get started quickly.

We’re going to cover using Jama to facilitate that implementation of MBSE, then we’re going to talk about keys to eliminating documents. We’ll look at how you can leverage OSSE and rest for cross tool linking. And we’ll talk about the benefits of Traceable MBSE to the broader stakeholder community model based systems. Engineering is more than a modeling tool. It is not simply a tool but a process that demands change to take place, not only at the systems level, but at the project and program levels.

RELATED: Getting Started with Model-Based Systems Engineering (MBSE)

Document centered thinking and business practices needs to change at all levels in order to not only deal with system complexity, but to also become more agile organizationally, but leaping to a purely SysML tool is not a leap every organization is mature enough to tackle. MBSE is not all only about moving from document centric to a model. It’s also about being able to communicate the clarity that the modeled information gives to the stakeholders on other teams, whether that be at the implementation level or the program or customer level.

The first step every organization can take is to become more information centric. Our Traceable MBSE is designed to do just that. Under the hood, Jama Software’s Traceable MBSE is composed of an easy to navigate structure for the data. Automatic version control of the data and baselining, a model language, a diagram editor, a workflow engine, a collaboration engine, document import and export and model integration with wide varieties of tools in your ecosystem like other SysML tools, test execution and more.

Traceable MBSE is pre-configured with a meta-model that govern which elements were allowed to be connected together. And which type of TraceLink names are used when elements are connected. For instance, a need can be related to a validation test and its relationship name is validate. A system requirement can be related to a system architecture block and its relationship name is satisfies. Jama Connect automatically chooses the correct relationship name for the user. Users do not need to know any syntax or language.

They just associate one element with another and connect a prize applies the pre-configured trace rules to those elements. You can also easily extend these data element types and relationship names by creating your own. There are distinct benefits from moving away from a document centric to information centric paradigm. Discrete item types, and link names, make it easy to analyze and query the model. Teams using documents, wikis or legacy tools often go through a manual process to relate all that data together, which can be error prone, introduced inconsistent data, or when performed after the fact yield stale inaccurate data.

RELATED: MBSE Tool Maturity – Where does your organization stand?

Jama Connect lets you surface in real time data and display it on the model dashboard. Dashboards can be a central place for any stakeholder technical or nontechnical to come away with an understanding of the current status of the systems engineering effort. Let’s take a look at Jama in action. So I’ve opened up my model, my model essentially is just a Jama Connect project. We have the building blocks of a structure. So on the left, you see the structure of the model, all the different types of data types that we’re collecting in this model.

The thing important data types that we have that come out of the box with Traceable MBSE are our needs. So a need item type, that’s where you would capture, you would use this type of element to capture a stakeholder need or an expectation or a requirement. Some regulatory requirements or things like that. Then we have a system requirements. So we’re segregating different types of requirements. System requirement has its own object. So you can demonstrate traceability between the need. So if you have customer requirements that are coming in as need as a need, you can really easily demonstrate that traceability.

We have a third requirement item type is a subsystem requirement. You are not constrained to use our specific nomenclature. You can extend these item types. You can rename them as well. We also then have a use case type. So, this particular use item type in Jama Connect is used to capture textural based more traditional use case flows in a more verbal textural. We also have that the capability to more granularly define the elements within a use case. So if you have actors, if you have different states or activities and you need to granularly break those out of a textual use case so that you can trace them in some way you can do that.

We also have a part. A part is more like a SysML 2.0 construct where a part might be used to capture structural elements, such as system architecture elements, or function blocks or physical objects or abstract objects. We have the capability to capture an interface as well as various different verification validation objects. So we had Jama segregate, verifications and validations. So it’s really easy to demonstrate that you have done both verification and validation of the objects. The model and the other types are extensible. So while the Traceable MBSE comes with just a handful out of the box, the ones on the top, you can create your own additional ones to add to your model and extend it for your specific needs. And you can also rename things.

So if you don’t call something a subsystem requirement, maybe you call it a component requirement, or maybe you call it a software requirement, or maybe you even call it a user story. You can rename things as well. Now, Jama Connect does come with a method, we call it our Traceable MBSE method. It’s a top-down approach top down where you have at the most abstract within my model, I have my needs but it supports analysis, design and specification. And it starts off with a needs analysis. So, when I want to look at my needs analysis I can click on something in the tree and then it shows in context in the main area of the system.

Now my needs analysis I’m capturing each need as an individual item, typically like you would in a spreadsheet. So I could look at the different views of the needs, whether I have a spreadsheet view or a rich text view. Our diagramming capability is built right in as well. So, when you want to communicate more clearly to your audience a diagrammatic expression of your needs users don’t have to go to external tools. You don’t have to go to a modeling tool per se, but you can build those diagrams right here in Jama.

You want a Traceable MBSE is designed for anyone to get started with your MBSE journey and then bringing in and marrying up diagrams right here in the context of the needs is a really powerful thing. You don’t need to be an expert to know how to draw boxes and lines and add textual information to communicate the information that you need to your audience. You also have the ability to do the collaboration that Jama is really famous for. So, if I need to bring people in to look at this particular diagram, we have the capability to add that comment even use at mentioning. So, if I wanted to add, mention a coworker, I can just mention their name.

Can you verify whether we need the X, Y, Z and the act that the comments within Jama are actionable? So it’s not a static comment but I can tell Alex, Hey, I need you to answer this question specifically, or maybe I’m just a read only user of this Jama model, and I’m looking at something and I want to raise an issue, or they be an engineer and I need someone to make a decision about something I’m unclear. I need some direction, just help me make a decision about that. Under the covers comments go into people’s email, they can reply back through email. They can answer questions, or they could click on the link in that email that would essentially take them right to this context, and then they can answer back.

So now we can have that sort of a conversation live captured part of the auditable trail and bringing more people into participate. If I wanted to, I could have even had mentioned my customer by just putting in their email address, and then my customer could have replied back to the comment thread. Well, it’s all about having more people being able to participate in the MBSE process.

Watch the full training to learn more about overcoming barriers to MBSE adoption.

Have you ever heard the saying that a systems engineer is the chief cat herder? Have you as systems engineer ever been branded as the person who asks “Why?” all the time? A systems engineer often perceived as the person that says, “Why do you need that? No, that won’t work. No, that is out of scope.” All systems engineers want to say “yes” more often. Systems engineering is a reductionist discipline so saying yes is often difficult. But perhaps systems engineers get a bad reputation because stakeholders cannot “see” the same things as the systems engineer and information is not getting communicated clearly. If your organization is trying to adopt a model-based approach to systems engineering (MBSE), then a SysML model might be too intimidating for most to interpret and consume which could result in even worse communication with the broader stakeholder development team. 

A transformative systems engineering practice lets the data do the talking to stakeholders. It enables its data to be easily consumed and understood. As a tool vendor I spend a lot of time talking to all kinds of customers that are in various stages of maturity. One common theme I hear from systems engineers is that they can’t get people to look at their data. They are always asked to provide a document or slide or walk them through the model. The systems engineer then ends up spending far more time working as a librarian and tech writer. 

If you aren’t already doing good SE then MBSE with a SysML tool might not be the answer. The SERC study shows an overwhelming measure of lack of value and adoption of MBSE (check my previous blog here). It is my belief that organizations should not be using their SysML tool to perform the functions of requirements management, management of verification and validation, or change and configuration management of this data. 

Jama Connect® for Traceable MBSE™ is designed to make it easy for non-systems engineers to consume data and participate in a collaborative, systems engineering process. It provides familiar navigation and views of data along with an industrial-grade configuration management and a workflow engine at its heart. Actionable collaboration at the element level provides a thread of decision points and audit trail of who said what and changed what. It enables real-time collaboration, no waiting for publishing of a model file or meeting date for a design review. Actionable collaboration means comments on elements can be framed as questions, issues, or decision requests. Discussion for each comment is threaded and its status can be queried. Comments can optionally trigger notifications when @mentioning users or groups. Users don’t need to leave the element in the model they are working on and use an external email or collaboration tool get input from additional stakeholders since you can just add their email address to the comment. 

RELATED: Getting Started with Model-Based Systems Engineering (MBSE)

When getting started with your system model, a Traceable MBSE™ template can be used where systems engineers and stakeholders can begin entering data. The Traceable MBSE™ model provides a starting point with pre-configured types to capture and segregate different types of requirements, architectures, behaviors, and V&V objects. The types can be tailored where you might add additional fields to capture various attribute information or even enable a workflow to display lifecycle state information. 

The Traceable MBSE™ template also comes with a structure laid out to organize the data. The structure is easy to navigate by opening the nested hierarchy. The highest level of abstraction is at the top of the tree and subsystem/component level data is nested below. This specific data organizational approach is not only an aid to users who want to understand the breadth of an entire system but is also present to facilitate reuse strategies for parallel development, variants, or product lines. 

A Jama Connect model is like a chameleon. It can appear to users like a familiar document, or it can be browsed and consumed as just data to provide the best of both worlds. For those stakeholders who still need a document, the data can be easily annotated with textural information to capture relevant background information. The data can also be organized under section headings. This data driven approach makes it easy to segregate data from background information. Views of the information can easily be switched from a rich contextual view containing both background info, section headings, and data; to a view that just displays the data elements alone (i.e. requirement statements, block names…). These built-in views make it easy for any type of stakeholder to read and understand what they are looking at and saves the systems engineers lots of time doing that librarian/documentation work. 

Jama Connect does not limit modeling to just creation of elements but provides these mechanisms for textural and section headings to be applied to architecture, interfaces, behaviors, and V&V elements. Model documentation is captured right here and does not need to span to other tools. The rich text editor lets the user format text, add tables, bullets, insert images, or enter formulas. The built-in diagram tool is where model diagrams can be constructed. Users aren’t required to know a modeling language and can add descriptive to and annotate the lines between the elements in any way they choose.  

RELATED: MBSE Tool Maturity – Where does your organization stand?

For those that are used to capturing architectures in documents, it might seem attractive to use an issue tracker or wiki like Atlassian® Jira® and Confluence®. These tools are not model-based and offer only the most rudimentary of links. Connect lets you capture functions, blocks, behaviors, requirements, and individual elements in the Connect model. Each element can have a rich descriptive area and fields configured for commenting, relationships, and workflow. They can be viewed in list form, in the tree, or as documents. 

Jama Connect for Traceable MBSE™ provides easy ways to associate relationships between different objects. Traceable MBSE™ is pre-configured with a schema and naming syntax that govern which elements are allowed to be connected together and which type of trace link name us used when elements are connects. For instance a Need can be related to a Validation test and its relationship name is “validates.” A system requirement can be related to a system architecture block and its relationship name is “satisfies.” Jama Connect automatically chooses the correct relationship name for the user. Users do not need to know any syntax or language; they just associate one element with another and Jama Connect applies the pre-configured trace rule constraint to those elements.  

This data-driven approach using a combination of textural model elements and diagrams makes it easy for organizations to participate directly in MBSE activities; share systems engineering data with broader audiences; and report on progress. Discrete item types and link types make it easy to analyze and query the model. Teams using documents, wikis, or legacy tools often go through a manual process to relate all the data together which can be error prone, introduce inconsistent data, or when performed after the fact yield stale, inaccurate data. Connect lets you surface in real-time data and display it on the model dashboard. The model dashboard can be a central place for any stakeholder, technical or non-technical, to come away with an understanding of the current state of the systems engineering effort.  

Award-winning ease of use and built-in collaboration mechanisms combined with our approach to MBSE give both MBSE mature teams and teams new to MBSE the ability to deliver high value systems engineering. Systems engineers will find it easier to say “yes” and cat herding will be more of a delight than an act of hide and seek. 

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 Traceable MBSE™. 

Jama Connect for Traceable 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 Traceable MBSE™ – The Nuts and Bolts 

Jama Connect for Traceable MBSE™MBSE 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 Traceable 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 Traceable 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 Traceable 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 Traceable 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 

Requirements are typically the first data elements to be worked on in the model. Jama Connect for Traceable 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 Traceable 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 

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

Architecture 

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 Traceable MBSE

V&V

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 Traceable 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 
Visualization 

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 Traceable MBSE

Why Jama Connect for Traceable MBSE? 

The inefficiency of non-integrated data leads to wrong decisions. When MBSE is done properly, the result is an overall reduction of development risks. Jama Connect for Traceable 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 Traceable 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.  

MBSE Tool Maturity LevelsMy initial intention for this blog was to talk about what I describe as MBSE tool maturity levels. And I will surely get around to those levels. But first I think it is important to draw attention to the definitions of MBSE that experts use and offer some observations that might be helpful to those who are beginning their own MBSE initiatives.

What is MBSE?

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.” This is simple enough to digest and the only noticeable difference between it at their definition of systems engineering is the reference to “formalized application of modeling.” They do not however, define what “modeling” means.

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.

  • MBSE is to perform systems engineering – connects system relationships
  • Controlling system configurations
  • Communicates an overall system picture accessible to all
  • Makes it easier to integrate disparate material
  • Ensures everyone is working on the same up to date material at all times
  • Eliminates problems with version control

RELATED: MBSE Made Easy – Overcoming the Organizational Challenges 

What is a Model?

NASA’s definition certainly 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.” What in simple terms is a model then? Wikipedia tells us that a “model is an informative representation of an object, person or system.” These definitions are super informative.

An observation I have is that organizations instantly equate MBSE with the use of a SysML tool. The experts tell us however, that MBSE is the combination of methods to create a representation. None of them say that to perform MBSE one must adopt a graphical modeling tool. There are many different methods to create models/representations. Some are graphical and some are textural. At the heart of MBSE is the drive to move from static documents (Word and Excel) into an information-based paradigm. The table below eloquently articulates the differences and standout benefits of using an MBSE approach.

MBSE table

Table source: Laura Hart, Lockheed Martin

MBSE Tool Maturity Levels

There are certainly many organizations that are still performing systems engineering only using documents. For the rest, there are a plethora of tools in the ecosystem used to create models including tools that support SysML. To begin the journey of MBSE, you don’t have to adopt a SysML tool right away. Maturity of MBSE is still young. Very few organizations do it for a program in an end-to-end manner. The learning curve is steep. Generally, a few engineers become the “scribe” and then end up translating to the extended team. And keep in mind a systems engineer is a “cat herder.” This person is the one who sees the big picture, understands the problem, and is the translator across engineering domains and the business. A SysML tool won’t be the only tool in their arsenal.

MBSE Maturity Levels

This finally brings me to describing MBSE tool maturity levels. Many organizations are already performing MBSE without even calling it MBSE just by the tools and processes they use in the organization. Level 0 is what I describe as only using documents and having no model representations at all. Level 1 is barely a step up from level 0 but the have a requirements tool in place or possibly a Kanban board that is capturing loosely coupled relationships between data. Level 2 is where teams are now combining the use of the RM tool with diagrams. Perhaps they are drawing diagrams in Visio or a UML tool. Level 3 is the combination of requirements, architectures, diagrams are used in conjunction with a defined methodology for how the information is defined, related, and analyzed. The tool will programmatically constrain the data in order to provide consistency as well as provide the mechanisms to define once and then reuse. Level 4 tool maturity is where organizations use a requirements tool and SysML tool.

Jama Connect aligns as Level 3 maturity. Customers who use Jama Connect experience their requirements becoming a source for strategic information during all stages of the system lifecycle. Requirements are turning into actionable data. The software world with its mass adoption of agile practices is trickling into the systems space and requirements now take different shapes. MBSE takes more than use of a language-based graphical modeling tool. Even for a Level 4 maturity, natural language is still the great common denominator. Not everyone will be an engineer and able to interpret models. Requirements and the structured architecture within Jama Connect provides the necessary context. Jama Software’s Traceable MBSE™ approach can be seen as the bridge one uses to leave behind documents and move towards Level 4 maturity.