DI-SESS-82304

Systems Architecture Deliverable

Provides the detailed representation of a system and its components, supporting viewpoints, architecture products, component relationships, and physical, functional, and software architecture priorities for a program.

Approval DateOctober 29, 2019

AMSC Number10120

Preparing ActivityMDA

Project NumberSESS-2019-069

OPR—

DTIC ApplicableNo

GIDEP ApplicableNo

Limitation—

Applicable FormsNo

Approval Limitation—

Form Version—

DID Formatfree_text

963C CompliantYes

DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.

Supersedes

—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

The Systems Architecture Deliverable (SysAD) provides the detailed representation of a system and the system components organized in a manner that supports viewpoints, architecture products, system component relationships, and additional descriptions that comprise the authoritative representation of the system architecture for the program. The SysAD details physical and functional architectures and interfaces, along with software architecture priorities of the system.

This Data Item Description (DID) contains the format, content, and intended use information for the data deliverable resulting from the work task described in the contract. This DID is applicable to all Department of Defense (DoD) acquisition programs through all program lifecycle phases.

Preparation Instructions

1Reference documentsThe 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. The SysAD shall describe the number, title, revision, and date of all documents referenced in the deliverable. This section shall also identify the source for all documents not available through normal Government stocking activities.

2FormatThe SysAD shall be in the form of a document, a digital system model, or a part of a larger digital system model that also encompasses other available system models that describe the system, e.g., system requirements, software architecture, system operational viewpoints, system behavior models, and system parametric models as specified in the contract statement of work. When delivered as a digital system model, the format shall be in the native model or standard-defined data format(s) as specified in the contract statement of work. If delivered as a document, the SysAD shall in the contractor's format.

3ContentThe SysAD shall be divided into paragraphs, as needed, to establish the context for the planning described in the deliverable. In the case of a digital system model, the terms "section" or "paragraph" in this DID shall mean the digital system model element(s) that fulfill the section or paragraph's requirements. The term "document" in this DID shall mean a collection of data regardless of its medium. The SysAD shall include the following:

3.1Document or model management and configuration control informationIdentify the version, release date, and other relevant management and configuration control information associated with the current version of the document or model. Include a change history, highlighting significant changes from version to version.

3.2Purpose and Scope of the SysADExplain the SysAD's overall purpose and scope. Explain the criteria for deciding which design decisions are architectural (and therefore included in the SysAD) and which design decisions are non-architectural (and therefore included elsewhere).

3.3How the SysAD Is OrganizedProvide a narrative description of the seven major sections of the SysAD (as identified by this DID) and the overall contents of each.

3.4Stakeholder Representation

3.4.1Stakeholders and their concernsIdentify the stakeholder roles considered in the development of the architecture described by the SysAD. For each identified stakeholder, include the concerns that the stakeholder has that can be addressed by the information in the SysAD. Indicate how serious each concern is to a stakeholder in that role. The following stakeholders shall be considered:

3.4.1.1Hardware and software developers

3.4.1.2Infrastructure developers

3.4.1.3End users

3.4.1.4Project Segment Teams

3.4.1.5Application system engineers

3.4.1.6Application and platform hardware engineers

3.4.1.7Security engineers and certifiers

3.4.1.8Safety engineers and certifiers

3.4.1.9Communications engineers

3.4.1.10System of system engineers

3.4.1.11Interoperability and Interface engineers

3.4.1.12Chief Engineer/Chief Scientist

3.4.1.13Lead System Integrator (LSI) Program manager(s)

3.4.1.14Government Program manager(s) (including those concerned with licensing)

3.4.1.15System integration and test engineers

3.4.1.16External test agencies

3.4.1.17Operational system managers

3.4.1.18Trainers

3.4.1.19Maintainers

3.4.1.20Other Service representatives

3.4.1.21Auditors (LSI internal, General Accounting Office (GAO), etc.)

3.4.1.22Program Protection Lead

3.4.1.23Trusted Systems and Networks Focal Point

3.4.1.24System Security Engineer

3.4.1.25Intelligence Analysis Engineer

3.5Use Cases or User Stories

3.5.1Stakeholder Scenarios for Using the SysADFor each stakeholder role identified, detail a few short scenarios that explain how that stakeholder would use specific sections of the SysAD to help address concerns.

3.6Viewpoint and View Definitions

3.6.1Introduction to ViewpointsProvide a short textual definition of a viewpoint and how the concept is used in the SysAD. The Systems Viewpoint, for Legacy support, is the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions. Systems Viewpoint will describe the systems and interconnections providing for or supporting DoD functions.

3.6.2Describe each viewpoint used in the SysADusing the following outline. The SysAD shall include the following viewpoints: Department of Defense Architecture Framework (DoDAF) Systems Viewpoint models SV-1, SV-2, SV-3, SV-4, SV-5a, SV-5b, SV-6, SV-7, SV-8, SV-9, SV-10a, SV-10b, and SV-10c (see https://dodcio.defense.gov/library/dod-architecture-framework/).

3.6.2.1Viewpoints

3.6.2.1.1Name the viewpoint

3.6.2.1.1.1AbstractProvide a brief overview of the viewpoint.

3.6.2.1.1.2Stakeholders and Their Concerns AddressedIdentify the stakeholders and their concerns that this viewpoint is intended to address. Indicate questions that can be answered by consulting views that conform to this viewpoint. Include significant questions that cannot be answered by consulting views conforming to this viewpoint.

3.6.2.1.1.3Elements, Relations, Properties, and ConstraintsDefine the types of elements, the relations among them, the significant properties they exhibit, and the constraints they obey for views conforming to this viewpoint.

3.6.2.1.1.4Language(s) to Model or Represent Conforming ViewsIdentify the language or languages that are used to model or represent views conforming to this viewpoint, and cite a definition document for each.

3.6.2.1.1.5Applicable Evaluation or Analysis Techniques and Consistency and Completeness Criteria

3.6.2.1.1.6Viewpoint SourceInclude a citation for the source of this viewpoint definition, if any.

3.7How a view is documentedIdentify the documentation organization for documenting a view.

3.8Relationship to Other SysADsIdentify the relationship and functional allocation between this SysAD and other architectures and requirements on the facility, system, hardware, interfaces, and software.

3.9Process for Updating the SysADIndicate the reporting process for discrepancies, errors, inconsistencies, or omissions from the SysAD. Include necessary point of contact information for submitting the report. If a form is to be used for reporting, a copy of the blank form or reference to an online electronic version shall be included in the SysAD. Indicate how error reports are handled, and how and when a submitter is notified of the issue's disposition.

3.10Architecture backgroundThe architecture background information shall be organized as follows and include the following information

3.10.1Problem BackgroundIn this section, indicate the constraints that significantly influenced the architecture, to include: any mission critical attribute, safety critical attribute, and other Configuration Item goals.

3.10.2System OverviewIndicate the general function and purpose for the system or subsystem whose architecture is described in the SysAD. Denote the functions that are mission critical and system critical (see Procedures for Protection of Critical Program Information, Mission Critical Functions, and Critical Components within the Missile Defense Agency, MDA MANUAL 5200.08-M; available via MDA/DS, 5700 18th Street, Building 245, Fort Belvoir, VA 22060-5573

3.10.3Goals and ContextIndicate the goals and major contextual factors for the system architecture. Include the role system architecture plays in the life cycle, relevant acquisition factors, the impact of the LSI model, the effects of incremental development, and the relationship to system engineering and system security engineering results and artifacts.

3.10.4Significant Requirement's DriversIndicate behavioral and quality attribute requirements (original or derived) that shaped the system architecture.

3.10.5Special ConsiderationsDescribe special system architecture design considerations, e.g., if the system will be a viable Defense Exportability Feature (DEF) candidate. Identify the impacts and risks to the system from Foreign Military Sales (FMS) and Direct Commercial Sales (DCS).

3.11Solution BackgroundIn this section, indicate why the architecture is the way that it is, and include a convincing argument that the architecture is the right one to satisfy the functional and quality attribute goals levied upon it. The solution background information shall be organized as follows and include the following information:

3.11.1Architectural ApproachesInclude a rationale for the major design decisions embodied by the system architecture. Indicate any design approaches applied to the system architecture. Include a rationale for the selection of those approaches, and indicate why they were chosen over other approaches that were seriously considered, but ultimately rejected. Indicate any relevant Commercial off-the-shelf (COTS) or Government off-the-shelf (GOTS) issues, including any associated trade spaces and security concerns. Indicate the incorporation of Open Systems Architecture (OSA) with a Modular Open Systems Approach (MOSA) to ease scalability and technology refresh. Note: "Open Standards" are widely accepted and supported by recognized standards organizations or the marketplace that support interoperability, portability, and scalability [Glossary of Defense Acquisition Acronyms & Terms, 13th Edition, Nov. 2009].

3.11.2Analysis ResultsInclude the results of any quantitative or qualitative analyses that have been performed that provide evidence that the system architecture is fit for purpose. If an architecture evaluation has been performed, the analysis sections of its final report shall be included.

3.11.3Requirements CoverageIndicate the requirements (original or derived) addressed by the system architecture. Include those requirements or constraints that are derived from higher-level SysADs.

3.11.4ConstraintsIndicate any constraints on elements or relations not otherwise described.

3.11.5Summary of Changes in Current VersionFor versions of the SysAD after the original release, include a summary of the actions, decisions, decision drivers, analysis and trade studies results that became decision drivers, requirements changes that became decision drivers, and how these decisions have caused the architecture to evolve or change.

3.12General relations among viewsIndicate the general relationship among the views chosen to represent the architecture. Include the context, operation, functions, interfaces, and activities of interoperability, interfaces, and integration. Identify consistency among those views, and any known inconsistencies.

3.13View-to-view relationsFor each set of views that are related to one another, show how the elements in one view are related to the elements in the other.

3.14Referenced materialsProvide citations for each reference used, giving enough information so that a user of the SysAD could be reasonably expected to locate the reference.

3.15DirectoryInclude an index of all element names, relation names, and property names. For each entry, identify where in the SysAD it was defined, and each place it was used.

3.15.1GlossaryInclude definitions of locally defined terminology used in the SysAD. If terms are used in the SysAD that are also used in a parent SysAD, and the definition is different, indicate why.

3.15.2Acronym listInclude a definition of the acronyms used in the SysAD.

3.16AppendicesAppendices shall be included, when necessary to provide information published separately for convenience in document maintenance (e.g., charts, classified data).

References

https://dodcio.defense.gov/library/dod-architecture-framework/ https://dodcio.defense.gov/library/dod-architecture-framework/

Schema v3.0Community-maintained · Verify against ASSIST

Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer