Attachment_0091_Digital_System_Model_OTD.docx

Attachment 0091 One-time Data Item Description:

Digital System Model

Revision No.: 000 Solicitation No.: W56HZV-22-R-0026 Date: 29 March 2022

Distribution Statement A: Approved for public release; distribution is unlimited

DATA ITEM DESCRIPTION

Attachment 0091 - One-time DID Digital System Model

Title: Digital System Model

Number: OTD-XXX-XXX AMSC Number: XXX DTIC Applicable: XXX Preparing Activity: US Army Tank Automotive Command Applicable Forms: XXX

Approval Date: XXX Limitation: XXX GIDEP Applicable: XX Project Number: XXXXX Attachment 0091 - One-time DID Digital System Model

Use/relationship: The Digital System Model provides a consistent and cohesive representation of the system. It includes digitally traceable interrelationships between data and information grounded in an authoritative source of truth.

a. The model contains metadata. The metadata describes the organization, elements and views in a model. Packages and internal data structure are elements in a model. Representations are the types of elements used and shown in views. Supporting analysis is represented by the organization, certain element types, and views

b. This Data Item Description (DID) contains the format, content, and intended use for the data product resulting from the work task described in the contract Statement of Work (SoW).

Requirements:

1. Reference documents. The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as specified in the contract.

2. Format. The Digital System Model shall be delivered in the native file format(s) of the modeling tool(s) or developed directly in the Integrated Digital Data Environment (IDDE) as identified in the Contractor’s Systems Engineering Management Plan. The Digital System Model shall include documentation regarding necessary software tool(s) configurations, access types (e.g., read-only or write access), dashboards, views, data integrations, data flows, reporting mechanisms outside of dashboards (e.g., report building tools), security, size, and configuration management details.

3. Contents. The Digital System Model shall be organized into the following sections:

3.1. Scope. This section shall be divided into the following sub-sections:

3.1.1. Identification. This sub-section shall fully define the system and elements to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

3.1.2. System overview. This sub-section shall state the purpose of the system to which this document applies. It shall describe the general nature of the system; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other related documents.

3.1.3. Document overview. This sub-section shall summarize the purpose and contents of the Digital System Model and shall describe any security or privacy considerations associated with its use.

3.2. Referenced documents. This section shall list the number, title, revision, and date of all documents referenced in the Digital System Model.

3.3. Model Overview. This section shall contain the following:

3.3.1. Design assumptions and design decisions about the model.

3.3.1.1. Assumptions and decisions about requirements.

3.3.1.2. Assumptions and decisions about verification and validation.

3.3.1.3. Assumptions and decisions about architecture.

3.3.1.4. Assumptions and decisions about use cases.

3.3.1.5. Assumptions and decisions about the structural aspects of the model.

3.3.1.6. Assumptions and decisions about behavioral aspects of the model.

3.3.1.7. Assumptions and decisions about the model infrastructure including tool interfaces and data flows.

3.3.1.8. Assumptions and decisions about model integration requirements.

3.3.1.9. Assumptions and decisions about functional, allocated, and product baselines.

3.3.2. Model infrastructure. This sub-section shall contain the following:

3.3.2.1. Modeling language(s) and version(s).

3.3.2.2. Incorporated profiles.

3.3.2.3. Model and data repositories.

3.3.2.4. External dependencies.

3.3.2.5. Data integration and digital thread with external tools, data flows, data dictionaries, databases, and other repositories to maintain data consistency.

3.3.2.6. Interfaces (internally or externally) with external software, such as Requirements Management Tools; Product Lifecycle Management tools; reliability, availability, maintainability, and testability tools and databases; risk, issue, and opportunity tools and databases; and/or Model Based Simulation & Analysis (MBS&A) tools.

3.3.2.7. Means of synchronization between the model and the implementation.

3.3.2.8. Dashboards and/or visualizations to interrogate or visualize the model.

3.3.2.9. Authoritative Data Source(s) with certification plan.

3.3.2.10. Associated descriptions of Tools, Add-ins, Dictionaries, Software, and Applications used to develop, maintain, update the model(s) to details on any installation, customization, or configuration requirements (e.g., compute, hardware needs, memory, networking, cyber, training, etc.)

3.3.3. Model Development Methodology. This sub-section shall contain the following:

3.3.3.1. The model development plan including:

3.3.3.1.1. Model requirements formulation.

3.3.3.1.2. Model development process.

3.3.3.1.3. Model documentation and release schedule.

3.3.3.1.4. Discrepancy reporting and tracking.

3.3.3.1.5. Facility or facilities (if multiple locations) where the model will be developed.

3.3.3.1.6. Enforcement of proprietary restrictions.

3.3.3.1.7. Conformance with Government cybersecurity and classified system requirements.

3.3.3.1.8. User training and documentation.

3.3.3.2. Tool set and development environment, including all information needed for the Government to independently reproduce the development, verification, validation, configuration management, and test environment.

3.3.3.3. Model style guidelines shall cover the following:

· Naming.

· Properties and attributes.

· Ports.

· Interface definitions including Data Dictionaries, Data Flows, and Meta-data Tagging.

· Operations.

· Receptions.

· Parts.

· Documentation standards.

· Design patterns for structural and behavioral modeling.

· Inheritance including:

· Specialized classes having attributes or operations that are not in the parent class.

· Limitations on the number of inheritance levels and multiple inheritance.

· Avoiding cyclic inheritance relationships.

· Use and limitations on use of redefines.

· Use of multiplicities Use of flows and flow properties.

3.3.3.4. Methodology to evaluate and optimize modularity and extensibility (e.g., use of interfaces and boundary blocks or classes).

3.3.3.5. Methodology to evaluate and optimize abstractions and encapsulation to minimize dependencies on the internals of elements.

3.3.3.6. Verification, validation, and testing methods.

3.3.3.7. Configuration management methods and tools.

3.3.3.8. Programmatic methods and tools, such as cost, schedule, and risk information linked to the technical aspects of the model.

3.3.4. Model Organization. This sub-section shall contain the following:

3.3.4.1. Package diagrams that capture and describe the model organization.

3.3.4.2. Organization rationale (e.g. by diagram type, by hierarchy, or by Integrated Product Team.)

3.3.4.3. Description of model navigation and views that depict model organization.

3.3.4.4. Description and purpose for model diagrams, elements, and output including all external referenced models.

3.3.5. Model Views. This sub-section shall contain a description of model views that capture and communicate draft CDRL data as it matures for each CDRL included in Tables 1-3.

The model view(s) for each CDRL listed in Table 1-3 shall include, at a minimum, the data specified in the CDRL Architecture Model (attachment TBD).

The formal delivery of each CDRL listed in Table 1-3 shall be IAW the OFMV contract. The CDRL data being communicated via the system model does not supersede the CDRL data requirements specified in the contract.

Note: PdM OMFV is actively working to assess the specific data needs of each CDRL and identify necessary architecture view descriptions to meet the needs of the acquisition. These architecture view descriptions will convey the fidelity of associated data and the desired visualizations of said data. This includes model views both within the SysML System Architecture Model and potentially other digital engineering tools. Additional CDRL instructions and guidance will be communicated alongside this DID via an attachment to the SysML CDRL Architecture Model in the final RFP.

The following tables include the CDRLs referenced in section 3.3.5 and 3.3.6 that are associated with the SysML System Architecture Model. The CDRLs are split into three tables based on their level of CDRL data scope and data development and delivery via the SysML System Architecture Model. The expectations for all CDRLs listed in Tables 1-3 is that some level of draft/working data for each CDRL is to be delivered via the SysML model for awareness and insight into the deliverable data as it matures, reducing the number of formal (document-based) CDRL deliveries. Additional CDRL instructions and guidance will be included in the final RFP in the DD1423 CDRL forms and the CDRL Architecture Model (attachment TBD).

The CDRLs are categorized as follows:

Table 1: All data within these CDRLs are expected to be developed and delivered via the System Architecture Model (E041) IAW their respective DIDs, DD1423 CDRL forms, and the CDRL Architecture Model (attachment TBD). The DD1423 CDRL forms and the CDRL Architecture Model will specify which working/draft data within each CDRLs is expected to be delivered via the SysML model on a regular basis, the frequency of data updates, required baselines of data, and the final delivery of the CDRLs in their traditional, document-based format.

Table 1 - Full SysML Model CDRLs

Table 2: Includes the list of CDRLs in which parts of the CDRL data may be developed and managed outside of the SysML model; however, the draft CDRL data that needs to be reviewed as it matures will be represented and delivered via the SysML Model (E041). The CDRL Architecture Model (attachment TBD) will specify which data within each CDRL is required to be included in the SysML model on a regular basis, expected format/templates for this data, delivery timelines, etc. The CDRL DIDs and DD1423 forms will indicate the delivery requirements for each CDRL outside of the SysML model.

Table 2 - Partial SysML Model CDRLs

Table 3: The CDRLs in this table are expected to be mostly, or fully developed and managed outside of the SysML model; however, there is some level of reference in or traceability to the SysML model. Examples include outputs from tests and analyses tagged to model elements, reference to object IDs of data within other tools, etc. The CDRL Architecture Model (attachment TBD) will specify which data within each CDRL is expected to be referenced in or traced to the SysML model on a regular basis, expected format/templates for this data, delivery timelines, etc. The CDRL DIDs and DD1423 forms will indicate the delivery requirements for each CDRL outside of the SysML model.

Table 3 - Referenced/Traced SysML Model CDRLs

Model Exports and Report Generation. This sub-section shall contain the native model export/report generation files used to export data from the digital system model to an external file-type (Microsoft Word, Microsoft Excel, PDF, etc.) IAW the CDRL Architecture Model (attachment TBD).

Note: PdM OMFV is actively working to assess which CDRLs the Contractor is required to develop a model export/report generation script for, with the purpose of allowing the Government to pull draft CDRLs from the model to communicate across various stakeholders that do not have access to the model. The intent is to allow a wider audience, outside of those with access to the system model, insight to certain information in the model on a regular basis without the need for a formal CDRL delivery. Additional model export and report instructions and guidance will be communicated alongside this DID via an attachment to the SysML CDRL Architecture Model in the final RFP.

3.4. Modeling of System Requirements. This section shall be divided into the following sub-sections:

3.4.1. Requirements completeness. This sub-section shall describe how inclusion of all requirements from the technical baseline is ensured.

3.4.2. Requirements rationale. This sub-section shall describe the rationale for all requirements.

3.4.3. Requirements satisfaction and validation. This sub-section shall link model elements to the system requirements.

3.4.3.1. Link all requirements to the model element or elements representing the system element or elements designed to satisfy each requirement.

3.4.3.2. Link each system requirement to diagrams and model elements used to validate linked requirements.

3.4.4. Requirements relationships. This sub-section describes relationships among requirements (e.g. contain, derive, refine, copy), between requirements and test cases (e.g. verify), between requirements and system behavior, interface, and structural elements in the architecture model, and between requirements and other model elements (e.g. performance analysis models).

3.4.5. Government-provided profiles. This sub-section shall detail the use of Government provided profiles applied to requirements.

3.4.6. Annotations. This sub-section shall specify annotations by hierarchical level.

3.4.7. Requirements tables. This sub-section shall include all tables showing the relationship of any set of requirements to any other set of requirements, test cases, or model elements.

3.4.7.1. Requirements Verification Plans. This sub-section shall include the planned requirement verification activities for each OMFV platform and SSS requirement, including but not limited to the planned:

· Verification Method(s)

· Verification Activity (i.e. type of analysis, type of test)

· Verification Activity Timeline

· Verification Activity Relationships (if several verification activities are planned)

· Verification Location (If Applicable)

· Verification Success Criteria (i.e. analysis and test thresholds and parameters)

· Required Verification Resources and Equipment

· Expected Verification Artifact(s) (i.e. Acceptance Test Report, Qualification Test Report, Thermal Analysis, Electrical Loads Analysis, Electrical Schematic)

3.4.7.2. Requirements Verification Results. This sub-section shall include the actual requirement verification activities and results for each OMFV platform and SSS requirement, including but not limited to:

· Actual verification method(s) performed

· Deviations from planned verification method(s) with rationale

· Results of verification activity

· Problems, impacts, and corrective actions associated with issues during verification

· Link to verification results within the model

· Reference to final verification artifact:

· Document title

· Document number

· Document Revision

· Location of or link to verification artifact within the IDE

3.5. Use Cases. This section shall contain the following:

3.5.1. Description of uses cases that capture mission objectives and requirements.

3.5.2. Description of use cases that capture system operations.

3.5.3. Description of use cases that describe error conditions and alternatives.

3.5.4. The tracing of use cases to requirements.

3.5.5. The tracing of actors, including inanimate systems, to other model elements.

3.6. Structural Diagrams. This section shall contain the following:

3.6.1. Diagrams:

3.6.1.1. Domain and context diagrams to identify what is external to the system and the high level Input/Output interactions, and to establish the system boundary.

3.6.1.2. System architecture diagrams, such as a top level Internal Block Diagrams (IBD), or equivalent to show the logical components and their I/O interactions.

3.6.1.3. Diagrams, such as Block Definition Diagrams (BDDs) and IBDs, which show subsystem decomposition and the relationship between components.

3.6.1.4. Logical architecture diagrams, such as BDDs and IBDs, which show the relationships of system functions to requirements.

3.6.1.5. Physical architecture diagrams, such as BDDs and IBDs, which allocate the logical components to physical components that are implemented in hardware, software, data, and procedure.

3.6.1.6. Parametric diagrams to support engineering analysis in support of a functional, allocated, and product baseline (e.g., performance, reliability, availability, power, and other required engineering disciplines)

3.6.1.7. Categorization and grouping methods (e.g. stereotypes) to categorize and group types of components.

3.6.2. Interfaces:

3.6.2.1. Description of all system and human interfaces, each defined as an interface block with a reference and hyperlink to the interface specifications.

3.6.2.2. Description of all operations and receptions within interfaces, with pre- conditions, post-conditions, and exceptions, if applicable.

3.6.2.3. Naming convention for interfaces.

3.6.2.4. Description of all stereotypes and profiles for interfaces.

3.6.3. Blocks and Classes:

3.6.3.1. Description of all definitions, including the purpose, roles, and responsibilities.

3.6.3.2. Description of the use of all blocks and classes in behavioral diagram and structural diagrams.

3.6.3.3. Description of naming conventions for blocks and classes.

3.6.3.4. Description of all properties and attributes and typing.

3.6.3.5. Description of all operations, including purpose, description, pre- conditions, post-conditions, exceptions, parameters, and return values.

3.6.3.6. List of all application of profiles and stereotypes.

3.6.3.7. List of all boundary classes that communicate with externals (e.g. external systems, external hardware, or externally developed software).

3.6.4. Relationships on Block Definition Diagrams:

3.6.4.1. Description of structural and non-structural relationships between classes and blocks.

3.6.4.2. Naming conventions for relationships.

3.6.4.3. Justification for any class or block with no relationships to model elements.

3.6.5. Connectors on Internal Block Diagrams:

3.6.5.1. Naming conventions for connectors.

3.6.5.2. List and description of flow of inputs and outputs between parts.

3.6.5.3. List and description of invocation of operations on parts.

3.6.5.4. List and description of sending and receiving signals between parts.

3.6.5.5. List and description of flow properties (at least type and direction).

3.7. Behavioral Content. This section shall contain the following:

3.7.1. Behavioral Content Requirements:

3.7.1.1. Methods for capturing system behavior.

3.7.1.2. Identification of what behaviors are not captured.

3.7.1.3. Description of pre-conditions, post conditions, alternatives, and error conditions.

3.7.1.4. Description of interactions at each level of the system hierarchy. Interactions include within the system and inputs/outputs to the system including external interfaces and human interactions.

3.7.1.5. Identification of state-based behavior for all blocks and classes (e.g. control classes).

3.7.1.6. Identification of design assumptions or design decisions about dynamic views.

3.7.2. Activity Diagrams:

3.7.2.1. Name and purpose of each activity diagram.

3.7.2.2. Mapping of classes and blocks in class and block definitions from the static model to behavior diagrams.

3.7.2.3. Mapping of activity and sequence diagrams to use cases.

3.7.2.4. Naming conventions on actions, data, and control flows.

3.7.2.5. Description of interactions involved in error conditions and alternative paths in scenarios. Interactions include within the system and inputs/outputs to the system including external interfaces and human interactions.

3.7.3. Sequence Diagrams:

3.7.3.1. Name and purpose of each sequence diagram.

3.7.3.2. Naming conventions for messages and sequence fragments.

3.7.3.3. Identification of data, data type, format, and communication type (e.g. synchronous, asynchronous) for all message flows.

3.7.3.4. Mapping of blocks and classes to lifelines.

3.7.4. State Machine Diagram Requirements:

3.7.4.1. Name and purpose of each state machine diagram.

3.7.4.2. Mapping of structural elements to state machine diagrams.

3.7.4.3. Mapping of state charts to other behavior diagrams.

3.7.4.4. Naming conventions for states, triggers, events, and actions.

3.7.4.5. Identification of state charts that address error conditions and alternative paths.

3.8. Model Data. This section shall contain the following:

3.8.1. Description of the data in the model.

3.8.2. Description of the data governance including data protection and access control requirements in the model.

3.8.3. Description of data types for all attributes and properties.

3.8.4. Description of meta-data and data tagging attributes.

3.8.5. Naming conventions for names of parent and child entities and for names of mapping entities.

3.8.6. A glossary with a list of all model elements.

3.9. Non-Functional Requirements. This section shall contain the following:

3.9.1. Performance Modeling:

3.9.1.1. Identification of all parameters and data necessary, including environmental factors, to analyze and calculate response time, capacity, and schedulability at any architectural level.

3.9.1.2. A description of how parameters and data are exported to performance analysis tools and simulations and how results are imported back into the model.

3.9.1.3. A description of how parameters and data are imported from the results of external analyses.

3.9.1.4. A description of how performance and data parameters are rolled-up from components, to systems/sub-systems, to the vehicle level to show the status of key system attributes (i.e. power, weight, reliability, etc.)

3.9.1.5. A description of the software used to execute performance modeling.

3.9.1.6. A description of how the performance models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.1.7. A description of how the performance models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.1.8. Cross-references between all analyses and associated data for each parameter within the model.

3.9.2. Reliability Modeling:

3.9.2.1. Identification of all parameters and data necessary to analyze and calculate quantitative reliability attributes using analytical techniques, such as: reliability block diagrams, fault tree analysis, Markov modeling, and Petri net analysis.

3.9.2.2. A description of how reliability parameters and data are exported to quantitative analysis tools and simulations.

3.9.2.3. A description of how parameters and data are imported from the results of external reliability analyses.

3.9.2.4. A description of the software used to execute reliability modeling.

3.9.2.5. A description of how the reliability models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.2.6. A description of how the reliability models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.2.7. A description of how the model allows for the input, storage, and export of data necessary to support a Failure, Modes, Effects, & Criticality Analysis (FMECA)

3.9.2.8. Cross-references between all analyses and associated data for each parameter within the model.

3.9.3. System Safety Modeling:

3.9.3.1. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables in the 100, 200, 300, and 400 series of tasks in MIL-STD-882E, System Safety, that are required under the program contract.

3.9.3.2. A description of how the model allows for the input, storage, and export of data for the 100, 200, 300, and 400 series of tasks in MIL-STD-882E that are required under the program contract.

3.9.3.3. A description of how the model allows for the input, storage, and export of data for MIL STD 882E tasks 402 and 403 (related to explosive safety).

3.9.3.4. A description of how the model produces data deliverables for all tasks in MIL–STD- 882 that are required under the program contract.

3.9.3.5. A description of views to display the current status of activities that support safety or environmental certification approval by external agencies at any architectural level.

3.9.3.6. A description of the software used to execute system safety modeling.

3.9.3.7. A description of how the system safety models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.3.8. A description of how the system safety models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.3.9. A description of how the model specifies system requirements if any are concerned with preventing or minimizing unintended hazards to personnel, property, and the physical environment.

3.9.4. Cybersecurity Modeling:

3.9.4.1. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables for all cybersecurity standards or instructions required under the program contract.

3.9.4.2. A description of how the model enables data input, storage, and export for all tasks related to cybersecurity standards required under the program contract.

3.9.4.3. A description of the views and reports produced by the model for all tasks in all cybersecurity standards or instructions that are required under the program contract.

3.9.4.4. A description of the views and reports produced by the model to display the current status of activities required for cybersecurity accreditation or certification approval at any architectural level.

3.9.4.5. A description of the software used to execute cybersecurity modeling.

3.9.4.6. A description of how the cybersecurity models are used to verify the Digital System Model is internally consistent and compliant with the contractor's modeling style guide and modeling process.

3.9.4.7. A description of how the cybersecurity models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.4.8. A description of the model’s security, data protection, and/or privacy environment in which the system must operate, the type and degree of security, data protection, access controls, and/or privacy to be provided, the security, data protection, and/or privacy risks the system must withstand, required safeguards to reduce those risks, the security/privacy policy that must be met, the security/privacy accountability the system must provide, and the criteria that must be met for security/privacy certification/accreditation.

3.9.4.9. A Security Controls Traceability Matrix (SCTM) that cross examines the security controls against the systems requirements to identify gaps to controls, requirements, and Cybersecurity Survivability Attributes (CSA).

3.9.4.9.1. The SCTM shall identify the applicable policy controls, and how the system meets technical controls.

3.9.5. Maintainability and Sustainability Modeling:

3.9.5.1. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables for Logistics Product Data (LPD) (Reference: DI-SESS-81758A).

3.9.5.2. A description of the views and reports produced by the model all tasks in all maintainability, sustainability, storage, repair, packaging, shipping, and handling standards or instructions required under the program contract.

3.9.5.3. A description of the views and reports produced by the model to display the current status of activities required for all maintainability, sustainability, storage, repair, packaging, shipping, and handling standards or instructions required under the program contract.

3.9.5.4. A description of the software used to execute maintainability and sustainability modeling.

3.9.5.5. A description of how the maintainability and sustainability models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.5.6. A description of how the maintainability and sustainability models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.6. Environment Modeling:

3.9.6.1. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables for all environment standards or instructions required under the program contract.

3.9.6.2. A description of how the model enables data input, storage, and export for all tasks related to environments required under the program contract.

3.9.6.3. A description of the views and reports produced by the model for all tasks in all environments standards or instructions that are required under the program contract.

3.9.6.4. A description of the views and reports produced by the model to display the current status of activities required for environment requirement compliance at any architectural level.

3.9.6.5. A description of the software used to execute environment modeling.

3.9.6.6. A description of how the environment models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.6.7. A description of how the environment models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.7. Quality, Safety, and Mission Assurance (QSMA) Modeling:

3.9.7.1. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables for all QSMA standards or instructions required under the program contract.

3.9.7.2. A description of how the model enables data input, storage, and export for all tasks related to QSMA required under the program contract.

3.9.7.3. A description of the views and reports produced by the model for all tasks in all QSMA standards or instructions that are required under the program contract.

3.9.7.4. A description of the views and reports produced by the model to display the current status of activities required for QSMA requirement compliance at any architectural level.

3.9.7.5. A description of the software used to execute QSMA modeling.

3.9.7.6. A description of how the QSMA models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.7.7. A description of how the environment models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.8. Human Performance (HP) Requirements Modeling:

3.9.8.1. Identification of all parameters and data necessary to analyze and calculate quantitative HP attributes using analytical techniques.

3.9.8.2. A description of how the model incorporates HP requirements and elements facilitating human systems integration (HSI) activities and analyses for improved human performance, reducing total ownership costs during system design, and improving fidelity of the SE process to meet human capabilities and limitations

3.9.8.3. A description of how HP parameters and data are exported to quantitative analysis tools and simulations.

3.9.8.4. A description of how parameters and data are imported from the results of external HP analyses

3.9.8.5. A description of how the model allows for the input, storage, and export of data necessary to support all deliverables to support human integration to achieve system x

3.9.8.6. A description of the software used to execute HP modeling.

3.9.8.7. A description of how the HP models are used to verify the Digital System Model is internally consistent and compliant with the Contractor's modeling style guide and modeling process.

3.9.8.8. A description of how the HP models are used to validate system use cases, behavior, interfaces, and requirements implementation.

3.9.8.9. Cross-references between all analyses and associated data for each parameter within the model.

END OF OTD-XXX-XXX

image1.png