System Requirements, Operational Concepts, and Design Descriptions
Engineers love documents, and large projects produce a bewildering zoo of them — CONOPS, OpsCon, design descriptions — that everyone nods at and few can actually tell apart. Operational concepts and design descriptions are the documents that capture how a system will be used and how it will be built — bridging the gap between the operational vision and the engineering detail.
This guide untangles what each document is for and how they fit together.
Table of Contents
Operational and Design Documents at a Glance
| Document | What it captures |
|---|---|
| ConOps | How the organisation will operate, at a strategic level |
| OpsCon | How a specific system will be operated, from the user’s view |
| Design description | How the system is built to meet its requirements |
Example System
Let’s dive into the practical use of document relationships through a specific system example in this blog. We’ll unravel how these crucial document connections influence the development process in real-life scenarios.
Generic Document Types
Before we dive deeper into the relationships between the documents, let’s gain clarity on the generic types of documents involved. The three key document types are:
System Requirements Specification (SRS)
The SRS serves as a specific record of the required characteristics and goals that any solution must possess. It outlines the essential features and attributes that the system needs to meet.
Operational Concept Description (OCD)
The Operational Concept Description (OCD) pivots on the system of interest. It meticulously identifies intended users and outlines the system’s anticipated uses. Moreover, it points out how users should operate the system. Furthermore, it forecast the external conditions under which the system will function.
Architectural Design Description (ADD)
The ADD identifies the elements of the solution to the system of interest. It outlines the key characteristics of each element and describes how these elements interoperate to fulfil the system’s requirements.
Relationships Between Key Documents
Unravelling the Interconnections: The System of Interest (SOI) encompasses the System Requirements Specification (SRS), Architectural Design Description (ADD), Aircraft System Requirements Specification (SRS), and Aircraft Operational Concept Description (OCD). These documents are interconnected in the following ways:
- The SOI SRS: The top-level problem and requirements that any solution must satisfy are defined in the SOI SRS. It includes measures of effectiveness, targets or goals, and value relationships.
- The SOI ADD: The selected concept of the solution to address the problem outlined in the SOI SRS is described in the SOI ADD. It provides an overview of the solution and its key elements.
- The Aircraft OCD: The Aircraft OCD focuses on the system-centric aspects related to the aircraft. It describes the users of the aircraft, its intended uses, the manner in which it will be used, and the external conditions during its operation. Additionally, the Aircraft OCD outlines the intended interactions of the aircraft with other elements of the SOI architecture, both within and outside the boundary of the SOI.
Importance of Complete Solution Development
Understanding Interactions and Dependencies: System of Interest (SOI) requirements often rely on element interactions within its architecture, like the aircraft. The aircraft directly interacts with the Operational Concept Document (OCD), which comprises other elements too. For example, a ground transportation system may not interact directly, but it still plays a crucial role in meeting overall requirements.
Creating a comprehensive SOI solution requires us to take into account various factors. These include aircraft requirements, requirements on elements that interact with the aircraft (discussed in the OCD), and requirements on SOI elements having no direct interaction with the aircraft.
Pitfalls of an OCD-Centric Approach
Avoiding Missing Vital Information: Relying solely on the OCD for deriving aircraft requirements can lead to unreliable outcomes. The OCD primarily provides an operational concept description and may not cover the entire system life cycle or provide detailed information necessary for requirement derivation. To ensure a reliable approach, it is crucial to create requirements for each SOI requirement, optimising the design to satisfy those requirements while aligning with the chosen solution concept described in the ADD. The optimum aircraft requirements are a subset of this set, representing an optimised design for the entire SOI.
Considerations for Non-Developmental Elements
Reconciling Characteristics for Seamless Integration: When incorporating non-developmental elements like Commercial-Off-The-Shelf (COTS) components into a solution, it is vital to reconcile their characteristics with the requirements developed based on the optimal design approach described earlier. These non-developmental elements should align with the overall design and meet the necessary requirements to ensure seamless integration within the system.
Conclusion
Unlocking the Relationships for Successful Development: Understanding the relationship between a System Requirements Specification (SRS), an Operational Concept Description (OCD), and a System/Subsystem Design Description is crucial for the development of effective solutions. By recognising the interdependencies and roles of these documents, engineers can ensure that all aspects of a system are considered and properly addressed.
Throughout this blog, we explored the relationships between these key documents and their significance in the development process. We began by providing an introduction to the topic and presented an example system to illustrate the practical application of these document relationships.
We then discussed the generic document types involved, including the SRS, OCD, and ADD, explaining their respective purposes in capturing system characteristics, describing the operational concept, and identifying solution elements.
Moving forward, we explored the interconnections between these key documents within the System of Interest (SOI). We highlighted the role of the SOI SRS in defining the problem and requirements, the SOI ADD in presenting the solution concept, and the Aircraft OCD in focusing on aircraft-specific details and interactions within the SOI architecture.
Furthermore, we emphasised the importance of considering the complete solution development process, acknowledging the interactions and dependencies between different elements within the SOI architecture. We cautioned against relying solely on the OCD for deriving aircraft requirements and instead advocated for a comprehensive approach that considers all requirements and optimises the design to meet the overall objectives.
Lastly, we discussed the considerations when incorporating non-developmental elements, stressing the need to reconcile their characteristics with the system requirements to ensure seamless integration.
By grasping the relationships between these key documents and their implications, engineers can navigate the development process more effectively, leading to successful system outcomes that meet the desired objectives.
Frequently Asked Questions
What is an operational concept document?
An operational concept (OpsCon) describes how a specific system will be operated from the user’s point of view — the scenarios, tasks, and conditions of use. It turns the broad CONOPS vision into something concrete enough to derive requirements from.
What is a design description?
A design description documents how a system is built to meet its requirements — its architecture, components, interfaces, and how they realise the required behaviour. It is the engineering counterpart to the operational concept.
What is the difference between ConOps and OpsCon?
A ConOps describes operations at the broad, organisational level; an OpsCon describes how a particular system will be operated from the user’s viewpoint. ConOps is the wider vision; OpsCon is system-specific and more detailed.
Related systems engineering guides
- Concept of Operations (CONOPS) — the operating vision
- From CONOPS to operational requirements — turning it into requirements
- What is systems architecture? — the design side
- CONOPS in action — worked examples
