Information Management Framework
A practical approach for organizing, connecting, controlling, and communicating engineering information throughout the lifecycle of an interconnected system.
Overview
Information Management ensures that engineering knowledge remains organized, accessible, traceable, understandable, and maintainable throughout the lifecycle of a system.
Complex engineering programs generate information across requirements, system models, hardware designs, software repositories, interface definitions, procurement records, analyses, test procedures, verification evidence, decisions, and configuration changes. When these records are maintained in disconnected locations without consistent relationships, teams may struggle to determine which information is current, why a decision was made, what changed, or which systems are affected.
These challenges become increasingly significant within interconnected electromechanical systems. A change to a mechanical component may affect electrical connections, software behavior, interfaces, installation activities, test procedures, procurement needs, and verification evidence. Information must therefore be managed as a connected engineering asset rather than as a collection of isolated documents.
Model-Based Systems Engineering provides a formal method for creating and maintaining these relationships. When full MBSE infrastructure is not available, many of the same principles can still be applied through structured information architecture, linked repositories, consistent naming, configuration control, ownership mapping, and disciplined change management.
The Role of MBSE
Model-Based Systems Engineering does not replace the specialized tools used for mechanical design, electrical engineering, software development, simulation, procurement, or testing. Its value comes from connecting the authoritative outputs of those disciplines through a shared system architecture and traceable relationships.
The system model provides a structured view of requirements, functions, components, interfaces, behaviors, decisions, and verification activities. When an element changes, the connected relationships support impact analysis and help identify which engineers, documents, models, code, tests, and lifecycle activities may require review.
Objective
The objective of the Information Management Framework is to ensure that engineering information is:
Organized according to the system and its lifecycle
Connected to related requirements, components, interfaces, decisions, and evidence
Maintained under configuration and revision control
Accessible to the people responsible for acting upon it
Presented in a format that supports efficient understanding and decision-making
Preserved so that future engineers can understand, maintain, and modify the system
Questions Supported
Where is the authoritative information located?
Which version or configuration is current?
What hardware, software, and interfaces are affected?
What requirement or decision caused the change?
Who owns and maintains the information?
How are models, drawings, code, analyses, and test evidence connected?
Can a new engineer understand the system without relying on tribal knowledge?
How will changes propagate across interconnected systems?
What information must be updated before the change is considered complete?
Framework at a Glance
The Information Management Framework is organized into six connected areas:
Information Baseline and Authoritative Sources
System Architecture and Modular Organization
Requirements, Interface, and Dependency Traceability
Configuration, Change, and Decision Control
Software, Code, and Digital Artifact Management
Toolchain Integration and Engineering Continuity
Information Governance
Engineering information should be accessible to the people responsible for using it while remaining protected according to project, contractual, regulatory, proprietary, and security requirements.
Information governance should identify:
Authorized users and access levels
Information owner and approval authority
Proprietary, confidential, or controlled content
Release and distribution requirements
Retention and archival expectations
Approved external-sharing methods
Backup and recovery responsibilities
Records that must remain available after project completion
Accessibility does not mean unrestricted access. The objective is to ensure that relevant users can obtain the correct information without compromising configuration control, contractual obligations, intellectual property, or system security.
1. Information Baseline and Authoritative Sources
Purpose
Establish what engineering information exists, where it is maintained, who owns it, and which source represents the approved project record.
Before information can be connected or improved, the team must understand the existing information environment. This includes identifying duplicated records, outdated files, undocumented decisions, inaccessible repositories, and areas where knowledge is retained primarily by individuals.
Information Inventory
The initial baseline should identify:
Project overview and scope
Stakeholders, customers, vendors, and points of contact
Requirements and acceptance criteria
System architecture and models
Hardware drawings, specifications, and bills of material
Software repositories, modules, builds, and release records
Interface definitions and control documents
Analyses, assumptions, and technical decisions
Procurement and manufacturing records
Installation and integration documentation
Test plans, procedures, results, and verification evidence
Configuration records and revision histories
Risks, discrepancies, waivers, and open actions
Applicable standards, references, and external documentation
Authoritative Source
Each information type should have an identified authoritative source. The goal is not necessarily to store every artifact in one tool, but to provide one reliable location from which approved information and supporting records can be located.
A project may use a central Lifecycle Information Hub—such as a controlled webpage, spreadsheet, database, model, or project index—that provides:
A brief description of each information set
Its purpose within the lifecycle
Its responsible owner
Its current revision or configuration
Its relationship to other records
A direct link to the authoritative source
This structure provides a lightweight form of model-based information management when a fully integrated MBSE environment is not yet available.
Questions Supported
What information already exists?
Which source is authoritative?
What information is duplicated, missing, or outdated?
Who maintains each record?
Where should a new team member begin?
What information must be recovered before execution continues?
Information should not be treated as authoritative solely because it is stored in a controlled location. Its accuracy, completeness, timeliness, configuration applicability, ownership, and approval status must also be understood.
2. System Architecture and Modular Organization
Purpose
Organize engineering information according to the structure of the system so that hardware, software, interfaces, responsibilities, and lifecycle records can be understood together.
Complexity becomes manageable when the system and its information are decomposed into modular elements with clearly defined purposes, boundaries, interfaces, and owners.
System Organization
Information should reflect the technical hierarchy of the system:
System
Subsystem
Assembly or software service
Component or software module
Interface
Requirement
Responsible owner
Supporting documentation
Verification evidence
Hardware Modularity
Hardware information should identify:
Mechanical and electrical assemblies
Replaceable or configurable components
Connection points and physical interfaces
Power, communication, and environmental requirements
Installation and access constraints
Applicable drawings and specifications
Vendor and procurement information
Inspection and verification requirements
Modular hardware architecture improves maintainability, replacement planning, interface control, obsolescence management, and impact analysis.
Software Modularity
Software information should identify:
Applications, services, packages, and modules
Inputs, outputs, and expected behavior
Dependencies and external libraries
Interfaces, APIs, and communication protocols
Configuration parameters
Runtime and development environments
Build, deployment, and release requirements
Responsible developers and maintainers
Applicable requirements and test cases
Software modules should be sufficiently separated so that changes can be evaluated, tested, and implemented without creating unnecessary effects across unrelated functionality.
Modular Information Principle
A modular system requires modular information.
Each system element should be understandable as an individual unit while remaining connected to the larger architecture. The purpose, owner, interfaces, requirements, configuration, and evidence associated with each element should be identifiable without reconstructing the project from disconnected records.
Questions Supported
How is the system decomposed?
What information belongs to each system element?
What hardware and software modules support each capability?
What dependencies exist between modules?
Can one element be modified or replaced without creating uncontrolled impacts?
Who owns each element and its supporting information?
3. Requirements, Interface, and Dependency Traceability
Purpose
Maintain visible relationships between stakeholder needs, requirements, architecture, hardware, software, interfaces, analyses, decisions, and verification evidence.
This is where MBSE provides significant value. Instead of treating requirements, designs, and test evidence as separate records, a model-based environment can represent them as connected elements. When a requirement, component, or interface changes, the related elements can be identified and reviewed through impact analysis.
Requirements Traceability
Requirements should be connected to:
Stakeholder or customer needs
System capabilities
Systems and subsystems
Hardware and software elements
Interfaces
Design decisions
Analyses and assumptions
Verification methods
Test cases and acceptance criteria
Objective evidence
Approved changes and deviations
Traceability should allow a reviewer to follow the information in both directions:
Need → Requirement → Design → Implementation → Verification Evidence
and:
Verification Result → Implemented Element → Requirement → Original Need
Interface Management
Interfaces should be treated as controlled engineering elements rather than informal relationships between teams.
Each interface should identify:
Connected systems or organizations
Interface owner
Physical, electrical, software, data, or procedural characteristics
Inputs and outputs
Protocols, units, formats, and timing
Constraints and assumptions
Applicable requirements
Related models, drawings, and code
Configuration and change history
Verification method
Required downstream updates
Interface and Integration Tools
Depending on the project, interface information may be maintained through:
MBSE architecture and interface models
Interface control documents
Requirements-management systems
Electrical and mechanical design environments
Software API definitions
Data dictionaries and schema repositories
Network and communication models
Simulation and co-simulation environments
Integration test matrices
Dependency and interface matrices
Product lifecycle or configuration-management systems
Interface tools provide the structure for documenting, visualizing, and evaluating relationships, but the tools do not manage the interface by themselves. Effective interface management still requires clearly identified ownership, agreed technical definitions, configuration control, communication between connected parties, and verification that the implemented interface performs as intended.
Dependency Traceability
Dependencies should identify how one element enables, constrains, or affects another. These may include:
Hardware-to-hardware dependencies
Software-to-software dependencies
Hardware-to-software dependencies
Requirement-to-design relationships
Interface-to-test relationships
Vendor-to-component dependencies
Component-to-installation dependencies
Configuration-to-verification dependencies
Model-to-implementation relationships
Questions Supported
What requirement does this element satisfy?
What systems and interfaces depend on it?
What must change if this element changes?
What test demonstrates compliance?
Which documents, models, code, and procedures require revision?
Has the change been evaluated across the full system?
4. Configuration, Change, and Decision Control
Purpose
Preserve the approved state of the system and maintain a traceable explanation of how and why that state changed.
A revision number alone does not provide configuration history. Engineering records must explain what changed, why the change was required, who approved it, which elements were affected, and what evidence confirms that the updated configuration is acceptable.
Configuration Control
Configuration records should identify:
Current approved baseline
Hardware part numbers and revisions
Software versions, branches, builds, and releases
Model and drawing revisions
Interface versions
Applicable requirements
Approved deviations and waivers
Installation configuration
Test configuration
Associated verification evidence
Change Records
A change record should identify:
Problem, request, or requirement driving the change
Affected systems, subsystems, and interfaces
Hardware and software impacts
Documentation and model impacts
Procurement, manufacturing, and installation impacts
Test and verification impacts
Options considered
Selected solution and rationale
Responsible owner and approval authority
Implementation status
Required evidence and closure criteria
Decision Preservation
Technical decisions should remain linked to the information that supported them.
A decision record should preserve:
The issue being resolved
Applicable requirements and references
Known information and assumptions
Alternatives considered
Analysis performed
Selected approach
Decision rationale
Stakeholders and decision authority
Affected system elements
Required follow-up actions
A document at Revision F should provide enough history for a future engineer to understand how and why it reached Revision F.
Questions Supported
What configuration is approved?
What changed and why?
Who authorized the change?
Which elements and records are affected?
Has implementation been completed across hardware, software, documentation, and testing?
What evidence is required before the change can be closed?
5. Software, Code, and Digital Artifact Management
Purpose
Ensure that software, models, scripts, configuration files, and digital engineering artifacts remain understandable, reproducible, testable, and maintainable.
Software is both a system component and a source of engineering information. Poorly documented code can become a form of tribal knowledge, even when it is stored in a version-controlled repository.
Code Documentation
Software repositories should clearly identify:
Purpose and intended capability
Architecture and module structure
Inputs, outputs, and interfaces
Dependencies and required libraries
Development and runtime environments
Installation and build instructions
Configuration parameters
Known constraints and limitations
Test procedures and expected results
Deployment and rollback procedures
Responsible owner and maintainers
Code should include meaningful:
File and module descriptions
Function and class documentation
Comments explaining non-obvious engineering logic
Variable and unit definitions
Error handling
Interface and API documentation
Change history
Links to applicable requirements and test cases
Comments should explain why an approach was selected when the reasoning is not evident from the code itself.
Version and Release Control
Digital artifacts should be maintained through controlled practices such as:
Version-control repositories
Branching and merge strategies
Peer review
Issue and defect tracking
Build and release identification
Automated testing where appropriate
Configuration files maintained with the applicable release
Reproducible environments
Archived approved versions
Traceable deployment records
Models and Engineering Scripts
The same control should apply to:
Simulation models
MATLAB or Simulink files
Analysis scripts
CAD models
MBSE models
Test automation
Data-processing pipelines
Configuration files
Generated reports
Training and deployment datasets
Each artifact should identify its purpose, inputs, assumptions, expected outputs, applicable configuration, owner, and validation status.
Questions Supported
Can another engineer reproduce the result?
Is the software or model associated with the correct system configuration?
What requirements and interfaces does it support?
What changed between releases?
Are assumptions and dependencies documented?
Can the artifact be maintained after the original developer leaves?
6. Toolchain Integration and Engineering Continuity
Purpose
Connect engineering tools and repositories so that information can move between disciplines without losing context, ownership, configuration, or traceability.
No single tool normally contains every artifact required to manage a complex system. Engineering organizations may use separate environments for requirements, MBSE, CAD, simulation, software development, procurement, testing, and document control. The objective is therefore not necessarily to force all work into one application, but to create a controlled digital thread between the authoritative sources.
Toolchain Elements
A connected engineering environment may include:
MBSE architecture and behavior models
Requirements-management tools
Mechanical and electrical design environments
Simulation and analysis tools
Software version-control repositories
Issue and action tracking
Product lifecycle and configuration-management systems
Procurement and material systems
Test-management environments
Controlled document repositories
Dashboards and reporting tools
Integration Principles
Toolchain integration should preserve:
Common system and component identifiers
Consistent naming conventions
Configuration and revision status
Requirements relationships
Interface relationships
Ownership
Change history
Verification evidence
Access permissions
Links to authoritative information
Where automated integrations are unavailable, controlled links, shared identifiers, traceability matrices, and lifecycle indexes can provide a practical interim solution.
Visual Understanding
Engineering information should be presented so that someone not directly involved in the effort can understand:
What the system is intended to do
How it is decomposed
How hardware and software interact
Where major interfaces exist
Which requirements are satisfied
What changed
What risks or discrepancies remain
What testing has been completed
What evidence supports the current conclusion
Visual representations may include:
Architecture diagrams
System and subsystem maps
Interface diagrams
Requirements-traceability views
Configuration trees
Dependency maps
Workflow diagrams
Verification matrices
Status dashboards
Change-impact views
Engineering Continuity
Information management should support both current execution and future use.
A new engineer should be able to determine:
Where to begin
What the system does
Who owns each area
Which information is authoritative
What decisions shaped the current design
What assumptions remain active
What risks and discrepancies remain open
How the system was tested and verified
What must be considered before making a change
Questions Supported
Can information be followed across the engineering toolchain?
Do different disciplines use consistent identifiers and configurations?
Can an engineer move from a requirement to the related model, implementation, test, and evidence?
Can a manager understand status and impact without reviewing every technical record?
Can the project continue effectively after personnel or organizational changes?
Information Management Review
A recurring information-management review should confirm that project records remain current, connected, controlled, and usable.
Recommended Review Topics
Recommended review topics include:
Authoritative sources and information ownership
Missing, outdated, or duplicated records
Requirements and interface traceability
Hardware, software, model, and document configuration
Open changes and affected information
Decision records and supporting rationale
Verification evidence and closure status
Toolchain links and broken relationships
Access, onboarding, and knowledge-continuity concerns
Required updates, owners, and completion dates
Indicators of Effective Information Management
Effective information management is demonstrated when:
Authoritative information can be located quickly.
Hardware, software, interfaces, and requirements remain connected.
System changes can be evaluated across affected disciplines.
Current configuration and revision status are visible.
Decisions and their rationale remain traceable.
Code, models, and analyses can be understood and reproduced.
Verification evidence is connected to the applicable requirement and configuration.
Stakeholders receive information appropriate to their responsibilities.
New engineers can understand the effort without relying primarily on tribal knowledge.
The information structure supports future MBSE and digital-engineering adoption.
Closing Statement
Information Management is not limited to document storage. It is the engineering discipline of organizing, connecting, controlling, and communicating the information required to develop, integrate, verify, operate, maintain, and modify a system.
Effective information management creates continuity between stakeholder needs, requirements, architecture, hardware, software, interfaces, analyses, decisions, configurations, and verification evidence. Model-Based Systems Engineering strengthens this capability by making those relationships explicit and supporting impact analysis across interconnected system elements.
The goal is to ensure that the right information remains available to the right people, in the correct configuration and context, throughout the lifecycle of the system.