- 1. Requirements Management
- 1 What is Requirements Management?
- 2 Why do you need Requirements Management?
- 3 Four Fundamentals of Requirements Management
- 4 Adopting an Agile Approach to Requirements Management
- 5 Conquering the 5 Biggest Challenges of Requirements Management
- 6 Three Reasons You Need a Requirements Management Solution
- 2. Writing Requirements
- 1 Functional requirements examples and templates
- 2 How to write system requirement specification (SRS) documents
- 3 Adopting the EARS Notation to Improve Requirements Engineering
- 4 Jama Connect Advisor™
- 5 Frequently Asked Questions about the EARS Notation and Jama Connect Requirements Advisor
- 6 How to Write an Effective Product Requirements Document (PRD)
- 7 Functional vs. Non-Functional Requirements
- 8 What Are Non-Functional Requirements and How Do They Impact Product Development?
- 9 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 10 8 Do’s and Don’ts for Writing Requirements
- 3. Requirements Gathering and Management Processes
- 4. Requirements Traceability
- 1 What is Traceability?
- 2 Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development
- 3 What is Requirements Traceability and Why Does It Matter for Product Teams?
- 4 How to Create and Use a Requirements Traceability Matrix
- 5 Traceability Matrix 101: Why It’s Not the Ultimate Solution for Managing Requirements
- 6 Live Traceability vs. After-the-Fact Traceability
- 7 How to Overcome Organizational Barriers to Live Requirements Traceability
- 8 Requirements Traceability, What Are You Missing?
- 9 Four Best Practices for Requirements Traceability
- 10 Requirements Traceability: Links in the Chain
- 11 What Are the Benefits of End-to-End Traceability During Product Development?
- 5. Requirements Management Tools and Software
- 6. Requirements Validation and Verification
- 7. Meeting Regulatory Compliance and Industry Standards
- 1 Understanding ISO Standards
- 2 ISO 26262 and Recent Updates: Ensuring Functional Safety in the Automotive Industry
- 3 What is ISO 13485? Your Comprehensive Guide to Compliant Medical Device Manufacturing
- 4 A Guide to Automotive Safety Integrity Levels (ASIL)
- 5 What is DevSecOps? A Guide to Building Secure Software
- 6 Compliance Management
- 7 What is FMEA? Failure Modes and Effects Analysis
- 8 Failure Modes, Effects, and Diagnostic Analysis (FMEDA) for Medical Devices: What You Need to Know
- 9 What’s a Design History File, and How Are DHFs Used by Product Teams?
- 8. Project Management
- 9. Measuring Requirements
- 10. Systems Engineering
Digital Engineering Between Government and Contractors
How does a digital thread work when tool ecosystems are disconnected from each other? For the defense contracting world, THIS is the elephant in the room. The DoD (Department of Defense) wants its Digital Engineering (DE) vision to become a reality and they do realize it cannot happen overnight, so how is this being addressed today?
The short answer is that the DoD wants their contractors to set up their own DE ecosystems and then exchange deliverables. This is no different than what they have done for the past 50 years but the types of deliverables are changing. Namely, they want DE content to be delivered as models which means SysML, UAF (an enterprise architecture format), Computer Aided Design (CAD) I– if the government purchased the technical data for this during contracting – models. The DOD still requires deliverables in Word/PDF/Excel/MS Project for various project management deliverables and engineering analysis that is only representable in textural form as well.
“Within the new Digital Engineering Ecosystem, there are three possible scenarios for information access between customer and contractor. The scenarios are: 1. Provide access to controlled baselines in contractor environment. This is considered a low IP (Intellectual Property) and data rights loss risk option two. Provide access to controlled baselines in the contractor environment and provide selected models and data in accordance with contract data requirements. This is considered a medium IP and data rights loss risk option 3. Provide all required baseline models and data in accordance with contract data requirements. This is considered a medium-high IP and data rights loss risk option.” – (AIA Aerospace whitepaper)
Nightly Check-in Technique:
PLM tools are deemed the center of the ecosystem since these already have the digital twin information (hardware CAD, configuration management, and product management backbone) in place. Nightly check-ins of files (SysML model, CAD, requirements, Ansys, etc.) are thought to be timely enough to keep things in sync. With this model, both the government and contractors would utilize a shared or their own PLM systems.
SAIC ReadyOne – a ready-made DE ecosystem of tools that can be purchased and installed in one click. It is managed on AWS GovCloud and is available up to CUI level four today. It is meant to answer the call for an easy to deploy, cost effective, and powerful integrated environment that delivers Digital Transformation – SAIC created Ready 1. ReadyOne is comprised of two main components
The infrastructure which includes the servers, application stacks, and build automation
And the Digital thread platform with a custom data model – which you can think of as the plumbing that defines the available connections between the various data artifacts – like system models, parts, and simulations – within the ecosystem
ReadyOne is Built on a model based, low code, platform supporting openness, flexibility, and customization. OOTB applications allow domain specific content to be mapped to Items and artifacts as well as customization – ensuring uniqueness of process, instead of forcing synthetic commonality.
Developers use familiar domain specific applications for System Modeling, CAD, and simulation to author content. Domain tools utilize pre-configured connectors with business rules to ensure all data is connected and the single source of truth remains persistent. Enterprise configuration management is a foundational component ensuring each domain is utilizing the proper data and relationships to remove opportunity for errors.
INCOSE Digital Engineering Information Exchange Working Group (DEIX-WG)
Group Goal = “The DEIX WG primary goal is to establish a finite set of digital artifacts that acquiring organizations and their global supply chains should use to request an exchange with each other as well as internally between teams/organizational elements.”
- DEIXPedia: Micropedia of digital engineering topics to explain relevant DEIX topics. STATUS = In place and updating
- Primer: A Narrative that describes the concepts and interrelationships between digital artifacts, enabling systems, and exchange transactions. STATUS = DRAFT
- Digital Engineering Information Exchange Mode (DEIXM): A prescriptive system model for exchanging digital artifacts in an engineering ecosystem. STATUS = DRAFT
- DEIX Standards Framework (DEIX-SF): A framework for official standards related to MBSE (Model Based Systems Engineering) Information Exchanges. STATUS = DRAFT
Defense Systems Integrator – Digital Engineering Use Case and Lessons Learned
At the NDIA 25th Annual Systems and Mission Engineering Conference one large defense contractor presented their working tool ecosystem and explained their use case and lessons learned.
- Provide system stakeholders with visibility into the system
- Determine impact of a Change to the System (e.g., requirement, model, part.)
- Determine impact of Simulation to the System (e.g., validate or invalidate a requirement.)
- To do this, I will need a digital engineering ecosystem that:
Enables the integration of repositories, i.e., requirements database,
- SysML models, PLM system.
- Provides a framework for creating digital threads across data repositories.
- Provides a mechanism for querying / visualizing digital threads.
- Provides a way to compare/sync data repositories.
- Can perform model/data transformations, e.g., DNG requirement → SysML requirement.
Dassault Cameo Systems Modeler is being used as the main user interface to coordinate with other models in other engineering domains, e.g., Creo, DNG etc.
Intercax’s Syndeia Cloud and Cameo plugin is good at connecting artifacts across different engineering repositories (DNG, Teamcenter, etc.) This group felt that Syndeia was the easiest to use and offered the most connections to their various tools. (Cameo, Teamwork Cloud, DNG, Teamcenter, Creo, Jira, GitHub, MySQL, Volta, Matlab/Simulink, Excel) They felt that in most cases Reference Connections were ideal and that reporting and analysis of the digital thread in the Syndeia Cloud webapp was more robust than anything other tool in the marketplace. They felt that Syndeia Cloud’s export of digital threads relationships into Excel to give to government customers was satisfactory.
Their Lessons Learned:
- Define the Process for creating “reference connections”:
- Who creates and manages the links.
- Directionality of the link are consistent. Note: SysML element should always be identified as the source of the link.
- Identify what types of links (digital threads) you want to create, for example:
- Create reference connections from DNG functional requirement(s) to its SysML <
>block to show a < >relationship.
- Create reference connections from a Teamcenter part/item/assembly to a <
>SysML block to show a < >relationship.
- Create reference connections from DNG functional requirement(s) to its SysML <
- Establish operational and QA environments for Syndeia:
- For testing out new patches and upgrades.
- QA environment for training/experimentation.
- Use caution of using “Local Repositories” (because they are local!)
- Configuration manage your data repositories:
- Teamwork Cloud for Cameo.
- Global Configuration Management (GCM) for DNG.
RELATED ARTICLE: Write Better Requirements with Jama Connect Advisor™
Model-Based Acquisition (MBAcq)
An increasing number of RFPs are not only requiring MBSE but RFPs themselves are now starting to be created as SysML models and responses are expected to be returned in a SysML model file. Yes, there are SysML tool vendors (PTC, Spec Innovations) and even contractors (L3Harris) asking the DoD to drop its language so that the file format is compatible with Cameo. These vendors are trying to ensure they can export and import tool-agnostic SysML that is interoperable with each other.
The challenge to both the supplier and provider is the lack of standardization in the approach, resulting in a learning curve for every proposal as well as response. To address this concern, the OMG UAF MBAcq Working Group was formed to survey the current landscape with participation from government, industry, FFRDC’s, tool vendors, NDIA, and OMG standards org. The goal is to come up with process guidance and a SE (Systems Engineering) and architecture guidance.
- ARM template and guidance (how to specify model-based DIDs, CDRLs.)
- GRM template and guidance (includes guidance for how NOT to over-specify a system.)
- Sample model (as part of UAF sample model.)
- UAF Process Guide for Acquisition will:
- Define the CONOPS for how a program office will use all the models they will receive over the lifetime or a system.
- Demonstrate how to make models available for reuse for other/new systems.
- Provide portfolio management for the models/programs.
- Provide process and guidance that describes how to integrate MBSE approaches into pre-acquisition (before request for proposal release), request for proposal, contract award, and contract execution steps.
- Impact to existing policy with recommendations for change.
- Descriptions of what Sections K, L, and M could look like for model delivery.
- Taxonomies with precise definitions for concepts and terms.
Digital Engineering Tool Suites
According to SBE Vision, digital engineering tools are a mixed bag of silos:
- Not all tools lend themselves to remote linking data at rest.
- Some tools don’t have a web server.
- Many detail design tools require a “local” model data as a basis for initial processing.
- Sometimes a transformative capability of some kind is needed.
- Certain use cases require a mashup of three or more systems.
Two Worlds Apart
SBE Vision is also developing techniques for both OLSC and synced data approaches. Complications can arise from linking vs syncing, such as company product, use case dependent, and can change over time.
OSCLS – Linked Data:
- Remote linking of data
- Human oriented
- Data stays at rest
- Clean paradigm
- Semantics (relational)
- Configuration management
- Change management
- Consistency of standards implementation
- Creating (temporary) copies of data
- Human & machine Oriented
- Enables many use cases
- Simple, easy to use
- Rich transformation when needed
- Semantics (relational & transformative)
- Configuration management
- Change management
- Managing correlation/sync state
Jama Connect enables real-time team collaboration through traceability and digital threads. To learn more about achieving Live Traceability™ on your projects, please reach out for a consultation.
In This Webinar, Learn More About Systems Engineering in Jama Connect
Live Traceability™ is the ability for any engineer at any time to see the most up to date and complete up and downstream information for any requirement, no matter what stage of development it is in 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.
Ready to Find Out More?
Our team of experts is here to answer any questions and learn how we can help enable your continued success. Get started by filling out this form so we can connect!