System Design

Role of System Design

The System Design follows the System Requirements development phase, which we covered in Chapter 6: System Requirements Specification.

The fundamental objective of the System Design phase is to meet all system requirements specified in the System/Sub-system Specification (SSS). It is essential to understand, however, that various different designs can satisfy the very same requirements. These designs frequently differ in aspects such as functionality, costs (development, manufacturing, operation, and maintenance), risks, and the ability to accommodate future modifications, just to name a few. A critical aspect of the System Design, then, is to analyze multiple design possibilities, weigh their relative benefits and drawbacks, and make design selections and decisions.

To demonstrate this, let us consider the example of developing a new car. Ideally, the spec will include the car size, weight class, dynamic characteristics (like maximum speed, desired 0-100 km/h acceleration time), and maximum fuel consumption. For most requirements, the designer can now select four different engine options: a pure internal combustion engine, a hybrid engine (combining an internal combustion engine and an electric motor), a plug-in hybrid engine, or a fully electric solution. Each of these options will have different price, maintenance requirements, weight, requirements from the car chassis, etc.

In some cases, the requirements may specify the use of a particular type of engine system, like hybrid. While this can be seen as over specification, it may well be a valid requirement from a marketing standpoint. Even in this case, the system designer has multiple design choices. One option is to integrate the internal combustion engine and the electric motor in a combined system (as seen in Toyota hybrid systems, for example). Another option is to connect only the electric motor to the wheels and use the internal combustion engine solely to charge the battery, thus eliminating the need for a gearbox (for example, like the new Nissan Qashqai e-POWER system).

There is also another aspect of system development that must be addressed during the System Design phase: ambitious, hard to implement and/or excessive requirements. During the design phase, different designs that address such requirements in different ways (including, when possible, refining the requirements), should be presented and evaluated, together with the stakeholders. There are many cases when even slight changes in some requirements can lead to significant savings in development or product costs, or allow for improved reliability or reduced risks. Later, we will demonstrate that on the UNEX example project used in this tutorial.

System engineers utilize various methodologies to transform system requirements into an effective system design. A widely used methodology in the development of multi-disciplinary projects is Functional Analysis and Allocation (FAA), described in DoD Systems Engineering Fundamentals (Chapter 5), or in earlier versions of the INCOSE Systems Engineering Handbook (e.g., version 2a, Chapter 9). The NASA Systems Engineering Handbook (NASA/SP-2016-6105 Rev 2) provides a comprehensive methodology for system design in Chapter 4, particularly sections 4.3 and 4.4. There are other well-known methodologies, geared more towards software and software-intensive system development, such as Model Based Systems Engineering (MBSE), Object Process Methodology (OPM), which is adopted by ISO/PAS 19450, and Object-Oriented Design (OOD).

It is crucial to understand that no methodology can replace the role of the system engineer in exploring multiple design possibilities, analyzing their relative benefits and limitations, making design decisions, and eliminating surplus requirements.

ReqView is a process-neutral tool that supports most, if not all, of these methodologies. You can choose the methodology that best fits your project's nature, one that you are accustomed to, or one required by your customer.

In the subsequent sections, we will demonstrate how to use ReqView to develop a System Design for the UX-1 Underwater Robotic Explorer platform in the UNEX example project. Please keep in mind that while the content is inspired by the UX-1 design and some originates from its actual design, other elements (such as specific design considerations and some sub-systems) are entirely devised for the purpose of this tutorial. All original UX-1 material used will be cited in section “2.2 Other referenced documents” of the UNEXssdd document, which we will create in the next section.

System Design Process Framework

In our UNEX example project, we will follow the general flow of the FAA method. We will continue to follow the MIL-STD-498 standard that we have chosen as the documentation standard for our tutorial project. The MIL-STD-498 Data Item Description (DID) describing system design is called System/Subsystem Design Document (SSDD). Using this DID for documenting system design that uses the FAA method is very convenient and straightforward, despite the fact that the MIL-STD-498 standard is older than the FAA.

First, let us create a ReqView document to be used as a template for the SSDD. Recall that we use ReqView project MIL-STD-498-DIDs created in the Section Create Project Storing Document Templates of Chapter 4 as the project that contains the ReqView documents to be used as templates. Ensure that the Git repository containing the ReqView project MIL-STD-498-DIDs is cloned into the Local Workspace. If necessary, clone it now before proceeding. To create the SSDD-DID document that will be used as a template for the project SSDD documents, take the following steps:

1. Open the MIL-STD-498-DIDs project in ReqView.
2. Right-click the document BARE-TEMPLATE in the Project pane and select Duplicate Document from the context menu. In the Duplicate Document dialog, enter “SSDD-DID” as the Document ID and “MIL-STD-498 System/Subsystem Design Document DID” as the Document name.
3. Import the contents of the MIL-STD-498 SSDD DID into the ReqView document SSDD-DID in a similar way as described in the Section Create Document Template for System Requirements of Chapter 4 for the SSS-DID document.
4. Customize attributes of the SSDD-DID document as needed for SSDD document template.
5. Commit updates in the MIL-STD-498-DIDs project to Git.

Now, create the new UNEXssdd document, using the following steps:

1. Open the UNEXsys project in ReqView. Select File→Project→Add Document from the main menu. ReqView will display the Add Document dialog.

2. Under Template, click Clone Document and select the directory MIL-STD-498-DIDs located in the Local Workspace as the Project folder. Then click the Select document dropdown box and select SSDD-DID.

3. Under Properties, enter “UNEXssdd” as the Document ID, and “UNEX System/Subsystem Design Document” as the Document name. Your screen will look like:

   

4. Click OK.

We can now start our design work and document it. The FAA flow usually includes the following steps:

1. Functional Analysis: Identify and define all functions the system must perform, and group them into higher level function groups.

2. Functional Allocation: Define specific physical components, sub-systems, or other elements and map the system functions to them.

3. Performance Requirements Development: Establish quantitative criteria for each function.

4. Functional Flow Definition: Determine the sequence, timing, and relationships between functions.

5. Interface Identification: Define interactions between functional elements.

Almost unnoticeably, we have actually finished the first FAA step in the Section Refine System Requirements into “Good Requirements” of Chapter 6. We created the document UNEXsss describing system requirements for all functions the system must perform and we grouped them under the appropriate sections of the UNEXsss document, creating new, functional sections where appropriate, e.g., “3.2.1 Environmental Sensors” (UNEXsss-81), or “3.2.4 Power” (UNEXsss-101). While our motivation was document readability and ease of review, this organizational work also completed the first step of functional analysis.

To finalize the System Design, we have to perform the remaining FAA steps, as well as some additional work (for example, requirements traceability into the design). Before diving into the work, let us outline the remaining FAA steps and their mapping to specific sections of the UNEXssdd document:

• FAA steps 2 & 3: Functional Allocation and Performance Requirements Development are mapped to section “4.1 System Components” (UNEXssdd-14). This section shall:

  • Define the specific physical components, sub-systems, and other elements of the system. Create subsections hierarchy that reflects the system hierarchy where needed.

  • Explicitly state the system functions allocated to each component or sub-system, along with their relevant performance requirements or criteria.

  • Establish traceability from these allocated requirements and performance criteria back to the system requirements in the UNEXsss document.

  • Present the top-level design of each sub-system/component. The level of detail should enable a clear assessment of its design feasibility.

  • Clearly mark design decisions that serve as requirements for the next level of decomposition.

  • When multiple design options or design tradeoffs exist for a component or sub-system, present and thoroughly evaluate the alternatives, with the chosen option explicitly stated and justified.

• FAA step 4: Functional Flow Definition is mapped to section “4.2 Concept of Execution” (UNEXssdd-16). This section shall:

  • Detail the sequence, timing, and relationships between the system components or sub-systems.
  • Create subsections hierarchy that reflects the system hierarchy where needed.

• FAA step 5: Interface Identification is mapped to section “4.3 Interface Design” (UNEXssdd-18). This section shall:

  • Define interfaces organized into subsections according to the system and interface hierarchies.

  • Alternatively, dedicated interface documents can be created. In such cases, the top-level subsection shall provide a reference to the relevant external document.

  • A hybrid approach combining internal definitions with external references is also acceptable.

After completing the remaining FAA work, we shall also complete the remaining sections of the UNEXssdd: “1 Scope and General Description”, “2 Referenced Documents”, and “5 Requirements Traceability”. You may also choose to add relevant notes and/or appendices.

System-wide Design Decisions

It is common practice to defer design decisions to the lowest possible level. The rationale behind this approach is to grant sub-system designers the flexibility to develop solutions that best meet requirements without unnecessary upfront constraints. This policy also generally maximizes future modification flexibility, as the implications of each change are more localized. However, most projects have certain design decisions that must be made early. These are decisions that significantly influence the entire project, typically impacting aspects such as project feasibility, cost, technical risks, and the ability to implement critical requirements. This Section specifies these early design decisions, analyzes them, weighs them against alternatives, and clearly explains their justifications.

First, we need to correctly identify topics that necessitate system-wide decisions. Prior system knowledge, system engineering expertise, and expert brainstorming sessions can all provide valuable input. ReqView, in conjunction with our defined process, can offer additional, systematic assistance: we should carefully consider all system requirements categorized as Difficult or Very Difficult.

It is straightforward to generate this list of candidates using ReqView's excellent filtering capability. For example, to list all system requirements in the UNEXsss document with the attribute Difficulty set to “Very Difficult” or to ”Difficult” use the following filter:  Type: Requirement Difficulty: Difficult, Very Difficult. This yields eight requirements: UNEXsss-107, UNEXsss-84, UNEXsss-86, UNEXsss-112, UNEXsss-97, UNEXsss-71, UNEXsss-74, and UNEXsss-80. Note that this is just a candidate list; not all of these requirements will necessarily lead to system-wide design decisions.

Next, we refine this candidate list by considering the specific constraints of our project. The UX-1 robot is highly constrained by its size, limited by requirements to a diameter of 60 cm, and to a maximum weight of approximately 111 kg (derived from the diameter and the principle of positive buoyancy; this will be less if the shape is not a perfect sphere). Furthermore, it must operate within harsh environmental conditions, including flooded mines, depths of up to 500 meters, and, in some cases, acidic environments with a pH level ranging from 3.0 down to 1.5.

Given these project constraints, it becomes clear that two critical requirements demand immediate attention and system-wide decision-making for successful project completion:

• Requirement “The robot shall withstand water pH level of at least 3. There is a design goal of withstanding pH level of 1.5, with a decision to be made at the robot design review, based on complexity and price.” (UNEXsss-71):

  Prolonged exposure to an acidity level of pH 3.0 or below can significantly impact the robot's material selection, consequently affecting its total weight and volume, price, usable lifespan, and maintenance procedures and costs.

• Requirement “The robot must be capable of constant communication with a base station during the mission while the robot is up to 500 meters underwater.” (UNEXsss-97):

  Implementing an underwater communication system for a range of 5 kilometers and depth of 500 meters is extremely challenging, especially considering the robot's size and energy constraints, as well as the structure of the mines to be explored: long, narrow, and winding passages.

All other requirements on the list do not necessitate system-wide decisions. They are either fundamental project constraints (such as maximum diameter, maximum depth, or turbid water) or implied project constraints (like requiring an autonomous, environment-based navigation system) that can be addressed effectively at the sub-system level.

Once this refined list is established, each topic requiring a system-wide design decision should be thoroughly analyzed. This analysis should weigh various alternatives, with the chosen design decisions and their justifications clearly explained. We will demonstrate this process using our UNEX example project.

We recommended to create section “3. System-wide design decisions” of the SSDD document (as well as most other content) directly in ReqView. You can add information either hierarchically or serially, or by mixing and matching the two methods as convenient.

In the hierarchical approach, you first define the sub-section headers, thereby specifying the document layout, and then complete the content of each sub-section. In the serial approach, you add a sub-section header and its content at a time before moving to the next. ReqView does not impose any specific order on you; just pay attention to the desired hierarchy when adding new items by using Add Before, Add Child or Add After from the context menu as appropriate.

We will use a combination of both the hierarchical and the serial methods in our example. To create section “3 System-wide design decisions” (UNEXssdd-10), take the following steps:

1. Populate UNEXssdd-11 with a general description of the refinement process that results in the list of topics demanding immediate attention and system-wide decision-making, and explicitly name these topics.

2. Add two dedicated child sections of UNEXssdd-10:

   • “3.1 Achieving Acidic Environment Resilience” (UNEXssdd-30), and
   • “3.2 Providing Constant Mission Communication” (UNEXssdd-31).

3. Using the hierarchical approach for UNEXssdd-30, add three child sections:

   • “3.1.1 UX-1 Hull Requirements and Challenge Discussion” (UNEXssdd-32),
   • “3.1.2 Design Alternatives” (UNEXssdd-33), and
   • “3.1.3 Final Decision and Justification” (UNEXssdd-34).

4. Create content objects for the sections created above:

   • Create object UNEXssdd-35 describing hull requirements as a child of UNEXssdd-32.
   • Create objects UNEXssdd-36 to UNEXssdd-41 describing design alternatives as children of UNEXssdd-33.
   • Create objects UNEXssdd-42 and UNEXssdd-43 describing design decisions as children of UNEXssdd-34.

5. Using the serial approach for UNEXssdd-31, create objects:

   • “3.2.1 UX-1 Communication requirement and challenge discussion” (UNEXssdd-44) as a child of section UNEXssdd-31,
   • UNEXssdd-45 describing UX-1 communication requirements as a child of UNEXssdd-44, and
   • “3.2.2 Design Alternatives” (UNEXssdd-46) as a child of section UNEXssdd-31.

6. Using the hierarchical approach, create objects:

   • “3.2.2.1 Wired Communication” (UNEXssdd-47) as a child of section UNEXssdd-46,
   • “3.2.2.2 Wireless Communication” (UNEXssdd-48) also as a child of section UNEXssdd-46,
   • UNEXssdd-49 describing wired communication as a child of section UNEXssdd-47, and
   • UNEXssdd-50 describing wireless communication as a child of section UNEXssdd-48.

7. Returning to the sequential approach, create objects:

   • “3.2.3 Why Constant Mission Communication may be Required?” (UNEXssdd-51) as a child of UNEXssdd-31, and
   • UNEXssdd-52 describing possible needs behind the requirement for constant mission communication as a child of the UNEXssdd-51.

8. As the last step, create objects:

   • “3.2.4 Final Decision and Justification” (UNEXssdd-53) as a child of UNEXssdd-31, and
   • UNEXssdd-54 and UNEXssdd-55 justifying final design decisions as children of section UNEXssdd-53.

You can clone the UNEXsys project with document UNEXssdd at its current state from the GitLab repository ReqView > Starter Guide > UNEXsys ch7_s1_describe_design_decisions or download the project folder unexsys-ch7_s1_describe_design_decisions.zip.

Main Challenges of System Design Phase

The System Design Phase is a critical stage where the system is progressively decomposed into smaller, more manageable sub-systems. Each sub-system is designed to implement specific, well-defined functionalities that fulfill a portion of the system requirements. Furthermore, the refinement process also generates crucial design decisions that effectively become new, lower-level requirements for subsequent development phases (e.g., size constraints, internal interfaces, identification of new sub-systems).

During this process, development teams frequently encounter the following characteristic challenges:

• Determining Optimal Design Detail: Finding the optimal granularity for each sub-system's design is a persistent challenge: too little detail can lead to ambiguity and costly rework in later stages, while excessive detail can limit future flexibility.

• Selecting Requirement Traceability Strategy: A key question is whether system requirements should be duplicated within design documentation or whether it is preferable to establish robust traceability links from design back to the original, higher-level requirements without any duplication.

• Handling Sub-system Requirement Allocation Patterns: A single top-level requirement may be relevant to, and thus allocated to, multiple sub-systems, or its functionality may need to be split across several sub-systems. This can make it difficult to accurately identify all requirements applicable to a given sub-system, within the overall system context.

• Capturing and Tracing Derived Requirements: Derived requirements are new requirements that emerge during the design process (also called design-driven requirements). The challenge is to specify these new requirements in a clear, unambiguous, and, most importantly, fully traceable manner back to the design decisions that generated them.

We will now discuss these challenges in more detail and present the recommended approaches for addressing them.

Determining Optimal Design Detail

The optimal granularity for each sub-system's design is crucial to project success. Too little detail can result in an underspecified solution. Such a solution, when refined in later development stages, can prove unfeasible from an overall system perspective, leading to costly rework. On the other hand, providing too much detail can slow down the System Design phase, and consequently the entire project. It may also limit the design options for the sub-system, potentially resulting in suboptimal (i.e. costlier, or harder to develop) sub-system design.

Let us illustrate this challenge using the UNEX underwater robot example: From the requirements, it is clear that the robot will need a propulsion system capable of six-degrees-of-freedom (6DoF) motion. This is essential for navigating and exploring flooded mine tunnels and chambers (requirements UNEXsss-113, UNEXsss-89, UNEXsss-114 and others). The propulsion system also needs to fit inside the robot, which is 60 cm in diameter, along with all other components (requirement UNEXsss-80). Furthermore, the propulsion system must consume minimal power to enable mission completion within the available energy budget. A naive approach would simply allocate all these requirements to the propulsion system, specify thrusters for 6DoF motion capability, and defer all other design details to later phases.

During detailed design, designers would discover that controlling motion along the Z (Vertical/Heave) axis consumes significant energy, as thrusters must work continuously to maintain depth. Interestingly, the required depth is usually constant for relatively long periods during the mission. A natural solution for this exists: Base the Z-axis motion on a ballast system as is common in submarines (see How Submarines Work).

This ballast system would be a sub-system within the propulsion system, but it has significant implications for the overall design: it requires internal volume within the robot, has weight that must be accounted for, and needs to be located at a specific position to ensure that changes in the robot's weight will not compromise its stability. Designing it during the System Design phase, alongside the robot's other sub-systems, is natural and straightforward. Adding a ballast system at a later phase, after all robot sub-systems have been detailed, would necessitate a major re-design, affecting many other sub-systems.

So, what constitutes optimal granularity for sub-system design? Here are some guiding rules that can help:

• Prove Feasibility Early: Design each sub-system to the level of detail that proves the overall system design is feasible and implementable. In our case, assessing the total power needs of a thruster-only solution would have revealed prohibitively high power requirements, making this solution infeasible.

• Design High-Risk or Complex Interfaces: Any interfaces between sub-systems that are complex, new, or carry significant technical risk should be specified in considerable detail during the system design phase. Failure to do so can lead to severe integration issues, unexpected dependencies, and costly delays in later stages.

• Defer Independent Design Decisions: When design alternatives exist for a sub-system, and all these alternatives do not affect other sub-systems (or their effects can be adequately accounted for in advance), defer the final design selection to the detailed design phase for that sub-system.

• Consider Team Autonomy and Specialization: If different teams or external vendors are responsible for different sub-systems, a more detailed design may be necessary to ensure clear boundaries and to minimize misinterpretations. This aids independent development while maintaining overall system coherence and reducing communication overhead.

Selecting Requirement Traceability Strategy

Managing traceability of system requirements allocated to sub-systems is a significant challenge for development teams. There are three common approaches to handling these allocations:

• Duplicate Requirements: In this approach, system requirements are duplicated within the design documentation, either in a central location or within each relevant sub-system section.

  The main advantage of this approach is that the SSDD document serves as the sole source of all requirements for the sub-systems, eliminating the need to reference higher-level documents. This also simplifies further decomposition, as engineers have all requirements in one location.

  The primary risk is that this duplication can lead to inconsistencies when an original requirement changes without all copies being updated.

• Rely Solely on Traceability Links: In this approach, no requirements are duplicated. The process relies entirely on establishing traceability links from the sub-system design documentation back to the original system requirements.

  Since each system requirement exists in exactly one location, changes cannot create inconsistent duplicates.

  However, this approach has a significant drawback: the complete set of requirements for a sub-system is scattered across multiple documents. Engineers must consult multiple sources to understand the complete scope, increasing the risk of overlooking requirements during implementation. As the design is decomposed into deeper levels, this fragmentation intensifies: verifying completeness requires cross-referencing multiple documents at multiple levels, and change impact analysis becomes increasingly complex.

• Copy and Link Requirements: The recommended approach is a hybrid that combines the benefits of duplication (resulting in having all requirements in one location) with robust traceability links (maintaining synchronization with source requirements).

  ReqView enables teams to duplicate the relevant system requirements in the design documentation, while clearly linking these duplicates back to the original higher-level requirements using specific link types. Whether to duplicate all requirements in a central place or within each sub-system documentation will be discussed in the next section.

  This strategy creates a clear and concise description of the required functionality of all sub-systems. It also facilitates further decomposition: the current SSDD becomes the primary source of requirements for the next design level, eliminating the need to reference higher-level documents during detailed design. When a higher-level requirement changes, ReqView's traceability capabilities enable rapid impact analysis. Teams can quickly identify all affected sub-systems and duplicated requirements, assess the implications, and systematically update all copies.

We will use the third approach (Copy and Link Requirements) consistently throughout our design process. This combines the benefits of having all requirements in one location with robust traceability links for synchronization.

Implementation details for this approach are provided in the Section Copy and Link UNEX System Requirements.

Handling Sub-system Requirement Allocation Patterns

A crucial part of the FAA Functional Allocation step is mapping system functions to specific physical components, sub-systems, or other system elements. Managing this allocation is a challenge due to several factors:

• A single system requirement (e.g., a system-wide functionality or safety requirement) may be relevant to, and thus allocated to, multiple sub-systems.
• The implementation of a single system functional requirement may need to be distributed across several sub-systems (e.g., handling different system states or distributing complex functionality).
• We must be able to verify that each system requirement has been assigned to all necessary sub-systems.

We address this challenge by defining a new multi-value enumeration attribute Sub-systems in ReqView, with all possible sub-systems as the enumeration values and set this attribute to all relevant sub-systems for each requirement. We can then filter requirements by sub-system as needed. The detailed setup and usage process is provided in the Sections Define Top-level UNEX Sub-systems and Allocate UNEX System Requirements to Sub-systems.

Capturing and Tracing Derived Requirements

Derived requirements are new requirements that emerge during the design process, often as a direct consequence of specific design choices, or a transformation or consolidation of system requirements. For instance, these could be performance targets for a particular module, interfaces between sub-systems, or the requirements of new sub-levels of components. These requirements can apply to the overall system or its individual sub-systems, and are sometimes called ”design-driven requirements”.

This phenomenon is essential and widespread in the development of any non-trivial system, regardless of the discipline, methodology, or development process employed. Design decisions made at one level of abstraction or decomposition translate into concrete requirements for the subsequent levels of design, development, and implementation.

Like all requirements, we must specify these new, derived requirements in a manner that is clear, unambiguous and fully traceable back to the design decisions that spawned them. To address this need, we use a systematic approach involving:

• Marking derived requirements with specific attributes
• Creating traceability links using a consistent link type
• Organizing requirements into appropriate SSDD sections

We provide detailed instructions how to mark, link, and organize derived requirements in the Sections Marking Derived Requirements and Organizing and Refining Sub-system Requirements.

System Design Process Execution

The goal of the system design process is to create a valid design that implements the system requirements. In the process, we decompose the system into sub-systems, each implementing (or participating in implementing) some of the system requirements or their derivatives. In this process, we need to establish robust requirements traceability by creating a complete, verifiable chain of connections from the highest-level concept down to the final physical work product.

After setting up all concepts and building blocks in the previous sections, we can now summarize the whole process and its implementation throughout the system design:

1. Copy and Link System Requirements: Copy all system requirements from the SSS document into a dedicated sub-section in the SSDD section “4.1 System components” while creating Derivation links from copied requirements to their source system requirements. In our UNEX example, this is sub-section “4.1.1 Top-Level (UNEXsss) Requirements Allocation” (UNEXssdd-56).

2. Decompose System: Based on these requirements, decompose the system into sub-systems.

3. Allocate System Requirements: Allocate the system requirements to specific sub-systems by using the multi-value enumeration attribute Sub-systems.

4. Organize and Refine Sub-system Requirements: Move requirements into the relevant SSDD section, or derive requirements that need further decomposition into new requirement(s) that will be located in the relevant SSDD section(s), or both.

5. Design Sub-systems: Decompose each sub-system to a level of detail sufficient to demonstrate a viable, implementable, and verifiable system design. A key challenge is to avoid over-designing – it is best to leave detailed design decisions for later project phases. It is common for sub-systems to have different levels of detail based on their complexity or risk.

6. Iterate When Further Decomposition is Needed: There are cases where some of the newly decomposed sub-systems need further decomposition in order to demonstrate a viable, implementable solution. In this case, treat the sub-system as a new system and iterate by repeating Steps 1-5 at this deeper level:

   • Copy sub-system requirements (from the parent sub-system section) into a new dedicated sub-section (Step 1)
   • Decompose the sub-system into smaller sub-systems (Step 2)
   • Allocate, organize, and design these sub-systems (Steps 3-5)

   This creates another level in the decomposition hierarchy, with the same process applied recursively.

7. Create Implementation Links: When sub-system requirements are suitable for direct implementation by the sub-system(s), no further decomposition is needed. Link each requirement to the sub-system(s) that fulfill it by using Implementation links.

Most of the steps are straightforward and do not require further explanation. There are, however, three topics that deserve further explanation: marking derived requirements, organizing and refining sub-system requirements, and Implementation links. Let us explain these three topics now.

Marking Derived Requirements

As discussed before, derived requirements emerge during the design process. In order to assure project requirements traceability, we must properly mark all derived requirements. To clearly mark derived requirements, take the following steps for each derived requirement:

1. Type attribute: Set the Type attribute to “Requirement”.

2. Requirement Type attribute: Set the Requirement Type attribute to the relevant categories, such as “Interface Requirement” or “Safety Requirement”. When the requirement is derived from another requirement, examine the Requirement Type attribute of the parent requirement for relevant categorizations to be copied.

3. Derivation Link: Link each derived requirement to its source higher-level requirement(s) or design decisions using Derivation links. This ensures full traceability and provides context for why the derived requirement exists.

   Note that ReqView traceability links shall point from child to parent. While creating links, the derived requirement (lower-level) should be the source, and the design decision or parent requirement (higher-level) should be the target.

Organizing and Refining Sub-system Requirements

We begin this step with all system requirements in the “4.1.1 Top-Level (UNEXsss) Requirements Allocation” section, and each system requirement is allocated to the relevant sub-system(s) implementing it.

For each sub-system, we need to organize all its requirements in an order allowing us to get a clear and verifiable picture, and that supports further decomposition. To accomplish this, we create relevant document sub-sections in the SSDD and then move requirements into the appropriate sub-section, deriving requirements into new requirement(s) located in the relevant sub-section(s), or both. We can create these subsections in advance, or when working on each sub-system and the need for the relevant sub-section arises.

To create these types of sub-sections:

1. Under the SSDD section “4.1 System components” (UNEXssdd-14), for each sub-system, create a sub-section “4.1.x <sub-system>”.

2. Under each “4.1.x <sub-system>” section, create a sub-section “4.1.x.1 <sub-system> Upper-level Requirements”.

   This sub-section initially contains all upper-level requirements allocated to the current sub-system. These requirements can be allocated solely to the current sub-system or to the current sub-system as well as to additional sub-systems.

   As the design of the current sub-system evolves, some of the contents of this sub-section may change:

   • We will move some requirements from this section into more appropriate document sections during the process.

   • We will add some derived requirements for the current sub-system, especially requirements that apply to all the sub-system components.

3. Under the SSDD section “4.3 Interface design” (UNEXssdd-18) describing all relevant interface requirements, create a sub-section “4.3.x <sub-system-a> - <sub-system-b> Interfaces” for each couple of sub-systems connected by interfaces.

We re-organize requirements into the relevant SSDD sub-sections according to the following possible categories of upper-level requirements:

Note that the exact category of requirements belonging to Categories I or II might not be clear at the initial allocation phase. The sub-system design may reveal that they need to be further decomposed.

To refine requirements for a given sub-system, follow these steps:

1. Move requirements of Category I and II (allocated only to the current sub-system) into the sub-section “4.1.x.1 <sub-system> Upper-Level Requirements”.

   Note: If the current sub-system needs further decomposition, some of these requirements will be later moved, or copied and linked (using a Derivation link) into the decomposed sub-system's sub-section, during the iteration.

2. Move requirements of Category III (interface requirements) to the appropriate subsection “4.3.x <sub-system-a> - <sub-system-b> Interfaces”.

   If an interface requirement needs further decomposition, derive new requirements describing the interface in an exact and detailed manner in this section.

   If you need to defer the decomposition of an interface requirement into later design phases, create derived requirements in the sub-section “<sub-system> Upper-Level Requirements” of each sub-system that the requirement relates to, and set its description to “The <sub-system> will implement the ... interface.”. The derivation hierarchy is important, since it ensures that a future change in the interface will be propagated into all relevant sub-systems.

3. For each requirement of Category IV (non-interface requirements allocated to several sub-systems) that is suitable for implementation, derive appropriate requirements and place them in section “4.1.x.1 <sub-system> Upper-Level Requirements” corresponding to the allocated sub-systems.

   Leave all requirements of Category IV that are not suitable for implementation intact – we will derive from them in the next decomposition phase.

Implementation Links

The purpose of Implementation links is to provide definitive proof that each requirement is fulfilled by a specific deliverable artifact (tangible work product). Each final, lowest-level requirement should be traced by an Implementation link to the specific work product that implements the requirement. Higher-level requirements that do not require any further derivation should also be traced by Implementation links to the specific work products implementing them.

An Implementation link could originate from :

• The SSDD section that describes the sub-system that fulfill the target requirement.
• The SSDD section that details the implementation of the target requirement.
• Or both.

In our UNEX example, most sub-systems are not fully detailed. Therefore, we will create Implementation links leading from document sections that define sub-systems in the SSDD section “4 System architectural design” (UNEXssdd-12) to the sub-system requirements.

The difference between Derivation and Implementation links is that Derivation links trace the logical breakdown of requirements, while Implementation links provide the ultimate proof that requirements are satisfied by specific deliverable artifacts (work products).

Summary

This system design process creates, for each system requirement, a hierarchical, traceable, linked tree of sub-system requirements. Each sub-system requirement is back-linked to the higher-level requirements document by a Derivation link. If a sub-system requirement needs decomposition, all derived requirements are linked to their parent requirement(s), also by a Derivation link. The process of sub-systems decomposition may take several levels of hierarchy. Requirements are moved to the appropriate document sub-section, under the lowest relevant sub-system(s).

Any sub-system requirement – whether upper-level or derived – that is ready for direct implementation and requires no further refinement must be linked to the specific sub-system(s) that will fulfill it. This is done using an Implementation link, which serves as the final step in the end-to-end traceability chain, proving that a top-level requirement is satisfied by a specific deliverable.

ReqView provides efficient traceability analysis to help you ensure that each requirement is implemented. The traceability analysis can be performed across multiple documents, residing in the same ReqView project or in a ReqView sub-project, composing a hierarchical project tree. We will demonstrate the application of this process to our UNEX example project in the Section Completeness and Consistency Checks. In the next Chapter of our tutorial we will decompose a large sub-system as a ReqView sub-project, and demonstrate the use of traceability analysis across multiple documents in a hierarchical project tree.

Functional Analysis and Allocation of UNEX System

After making the necessary system-wide design decisions and laying out the framework for design decomposition in the previous sections, we now proceed to complete the Functional Analysis and Allocation (FAA) for the UNEX system. Note that this order is important: the initial system-wide design decisions directly affect the FAA, particularly in defining the sub-systems to be implemented and potentially in how they interact.

The remaining FAA phases map naturally to the following SSDD sections:

• FAA phases 2. Functional Allocation and 3. Performance Requirements Development map to SSDD section “4.1 System Components” (UNEXssdd-14).

• FAA phase 4. Functional Flow Definition maps to the SSDD section “4.2 Concept of Execution” (UNEXssdd-16).

• FAA phase 5. Interface Identification maps to the SSDD section “4.3 Interface Design” (UNEXssdd-18), or alternatively to separate Interface Design Description (IDD) documents common for large systems.

While the phrasing above might suggest that these phases are executed sequentially, it is a common practice to execute these phases in parallel, often in an iterative manner. System engineers should expect back-and-forth refinement as design insights from one phase inform decisions in another. The sequence presented here should be viewed as a logical framework rather than a strict procedural order.

To complete the definition of physical components and sub-systems and their associated performance requirements, take the following steps and document the resulting artifacts under the SSDD section “4.1 System Components” (UNEXssdd-14):

1. Define the specific physical components, sub-systems, and other elements of the system. Where needed, create a hierarchy of subsections that reflects the system's physical structure.

2. Explicitly state the system functions allocated to each component or sub-system, along with their relevant performance requirements or criteria.

3. Establish traceability from these allocated requirements and performance criteria back to the requirements in the UNEXsss system requirements document.

4. Document the top-level design of each sub-system/component, to a level of detail that will enable a clear assessment of its design feasibility.

5. Identify, document and tag design decisions that serve as derived requirements for the next level of decomposition.

6. Thoroughly evaluate and present the alternatives when multiple design options or design trade-offs exist for a component or sub-system, and explicitly state and justify the chosen option.

In the following sections, we demonstrate the completion of the FAA process for selected UNEX sub-systems in our UNEX example project. Since this project aims to demonstrate how to use ReqView in an actual project development, we will not complete the analysis for all sub-systems. This remains an exercise for the interested reader.

Define Top-level UNEX Sub-systems

In Chapter 6: System Requirements Specification, we created the UNEXsss document containing the UNEX system/sub-system specification. From this document, we identify the following five top-level sub-systems that comprise the UNEX system:

• UNEX Underwater Exploration Vehicle (or Robot)
• Robot Charger
• Mission and Robot Control Station
• Transportation Cart
• Storage Container

The UNEX sub-systems exhibit varying levels of complexity, which is normal when designing large-scale systems.

Treat this list as a starting point for system decomposition. While you should make reasonable effort to identify all required sub-systems initially, the list can evolve as the design matures—adding sub-systems when new needs emerge or removing sub-systems found to be redundant or unnecessarily decomposed.

To document and define these sub-systems and allocate their top-level requirements within the UNEXssdd document, follow these four steps:

1. Describe the sub-systems
2. Create a sub-section for requirements allocation
3. Create dedicated sub-sections for each Sub-system
4. Define an attribute for sub-system allocation

Each step is detailed below:

1. Describe Sub-systems:

1. Ensure that UNEXssdd document editing is enabled (select Document→Start Editing Document if needed).

2. Navigate to the empty object UNEXssdd-15 located in section “4.1 System Components” (UNEXssdd-14).

3. Open the rich-text editor in the Description column and provide a list of the identified top-level sub-systems.

2. Create Sub-section for Requirements Allocation:

Create a sub-section to contain the system requirements from the UNEXsss document during their allocation:

1. Right-click the object UNEXssdd-15 and select Add After from the context menu.
2. In the Add Object After dialog, enter “Top-Level (UNEXsss) Requirements Allocation” as the heading
3. Click OK

This creates sub-section “4.1.1 Top-Level (UNEXsss) Requirements Allocation” (UNEXssdd-56).

3. Create Sub-sections for Sub-systems:

Using the same procedure described above in 2. Create Sub-section for Requirements Allocation, create dedicated sub-sections for each of the five sub-systems. After completion, you should have:

• “4.1.2 The UNEX Underwater Exploration Vehicle (or Robot)” (UNEXssdd-57)
• “4.1.3 The Robot Charger” (UNEXssdd-58)
• “4.1.4 The Mission and Robot Control Station” (UNEXssdd-59)
• “4.1.5 The Transportation Cart” (UNEXssdd-60)
• “4.1.6 The Storage Container” (UNEXssdd-61)

4. Define Attribute for Allocating Sub-systems:

Define the multi-value enumeration attribute Sub-systems that will be used to tag the allocation of each system requirement to its relevant sub-system(s):

1. Select Document→Customize Attributes from the main menu to open the Document Attributes dialog.

2. On the empty line at the end of the attributes list, define the new attribute subSystems:

   • ID: “subSystems”
   • Type: “multi enum. values”
   • Name: “Sub-systems”

3. Click on the right side to add the following enumeration values:

   • Key: “subSysRobot”, Value: “Robot”
   • Key: “subSysCharger”, Value: “Charger”
   • Key: “subSysMissionStation”, Value: “Mission Station”
   • Key: “subSysTransCart”, Value: “Transportation Cart”
   • Key: “subSysStorageCont”, Value: “Storage Container”

4. Click OK

   

Copy and Link UNEX System Requirements

Copy all system requirements to the design document and link them to their origin using the Derivation links, as discussed in the Section Traceability Between System and Sub-system Requirements:

1. Select Requirements:

   Open the UNEXsss document and apply the following filter  Type: Requirement to display only system requirements. Then, press CtrlA to select all system requirements.

2. Copy Requirements:

   Press CtrlC (or right-click and select Copy from the context menu, or select Edit→Copy from the main menu) to copy the selected requirements to the clipboard. You will see all requirements marked for copy by a copy icon appearing in their ID field.

3. Paste Requirements:

   1. Switch to the UNEXssdd document and select section heading “4.1.1 Top-Level (UNEXsss) Requirements Allocation” (UNEXssdd-56).

   2. Press CtrlV (or right-click and select Paste from the context menu, or select Edit→Paste from the main menu).

   3. In the Paste popup, make sure that Copy Attributes, Copy Attachments and Create Derivation Link options are enabled. The popup should look like this:

      

   4. Finally, click Paste As Child to create a copy of all system requirements, already linked to their origin.

Allocate UNEX System Requirements to Sub-systems

To allocate each copied UNEX system requirement to the relevant sub-system(s), take the following steps.

1. Customize table view
2. Allocate requirements
3. Display selected sub-system requirements

Let us detail each step:

1. Customize Table View:

Set the table view to display columns ID, Type, Requirement Type, Description, Sub-systems and Links (in this order) and to list requirements only. Optionally, save the view to reuse it later.

To add missing columns, select View→Columns from the main menu (or right-click on the table header and select Columns), and then enable missing columns. Afterwards, order the columns and adjust their width by mouse drag and drop on the table header.

To display only requirements, click Filter on top and apply the condition  Type: Requirement.

To save the table view, click Table Views on the left (or press CtrlAltV). In the Table Views pane, click on the toolbar. In the Create Table View dialog, enter “Requirements Allocation” as the table view name, check the Duplicate current document view, and click OK.

Your screen will look like:

2. Allocate Requirements:

Walk through all system requirements displayed in the table view Requirements Allocation and allocate each requirement to the related sub-system or sub-systems by setting its Sub-systems attribute.

To set this attribute for a selected requirement, double click the Sub-systems attribute in the table view or in the Attributes pane and check all relevant sub-systems on the popup editor box that appears.

To allocate multiple requirements to the same sub-system(s), select all of them (click on the first requirement, then hold Ctrl and mouse left click to add additional requirements, or hold Shift and mouse left click on the last requirement to select a range). Then, hold Ctrl and double click on the Sub-systems column of one of the selected requirements and set the attribute as described above.

The result of the allocation process is:

Notes:

• UNEXssdd-111 still requires modification according to the system-wide design decision taken in section “3.2.4 Final Decision and Justification” (UNEXssdd-53). We will handle this during the Robot design decomposition described in Chapter 8 of this tutorial.

• UNEXssdd-117 was not assigned to the robot since the robot requirement is already covered by UNEXssdd-120

3. Display Selected Sub-system Requirements:

We can easily display all top-level requirements that are allocated to a given sub-system, which will help us both in identifying all requirements allocated to a given sub-system, as well as checking the correctness of our requirements allocation. In order to do that, we will first define a helper template column, identifying all objects that have links to the relevant upper-level document, and then use this column, together with other attributes, to filter the required objects.

To define the helper column, we will use the Traceability Column Wizard:

1. Using the main menu, select Document→Add Template Column→Traceability Column. The Traceability Column Wizard dialog will appear.

2. Enter “Upstream Links” in the Column Label text box. This will be the name of the column.

3. In the Link Type drop-down box, select “Derives”.

4. In the Linked document drop down box, select the UNEXsss document.

   Your Traceability Column Wizard dialog will look like:

   

5. Click OK.

Now we can easily display all requirements that are allocated to a given sub-system by applying the following simple filter:

•  Type: Requirement to filter all requirements, AND
•  Upstream Links is set to filter only objects that have links to upper-level documents, AND
•  Sub-systems: <sub-system> to filter all requirements allocated to a given sub-system, e.g., “Robot”.

You can clone the UNEXsys project at its current state from the GitLab repository ReqView > Starter Guide > UNEXsys ch7_s2_allocate_reqs_to_subsystems or download the project folder unexsys-ch7_s2_allocate_reqs_to_subsystems.zip.

Analyze Transportation Cart Sub-system

First, we will demonstrate the functional analysis and system design for the Transportation Cart sub-system. This is a relatively simple sub-system, at least from the system design perspective of the UNEX project. While starting with one of the simplest sub-systems is not always a typical approach, it allows us to demonstrate some working methods that we will use later for more complex sub-systems. The process is composed of the following steps:

1. Identify upper-level requirements
2. Handle requirements allocated to a single sub-system
3. Handle requirements allocated to multiple sub-systems
4. Handle interface requirements
5. Finalize sub-system requirements

Let us detail each step:

1. Identify Upper-level Requirements:

To identify all upper-level requirements that were assigned to the Transportation Cart, apply the following simple filter to the UNEXssdd:  Type: Requirement Upstream Links is set Sub-systems: Transportation Cart.

As a result, nine requirements are displayed:

Seven requirements are solely allocated to the Transportation Cart (UNEXssdd-122 and UNEXssdd-127 through UNEXssdd-132), and two are also allocated to the Storage Container (UNEXssdd-117 and UNEXssdd-134).

2. Handle Requirements Allocated to Single Sub-system:

Let us handle first the seven requirements that are solely allocated to the Transportation Cart and move them to the corresponding SSDD section “4.1.5 The Transportation Cart” (UNEXssdd-60).

We can easily select these requirements using the filtered view. However, the active filter will prevent us from creating required sub-sections and/or moving requirements to a new desired place, since the filtered view hides the document structure and sections.

The most convenient way to do this operation is to use two ReqView windows for copying or moving requirements within the document. The first window has the filter activated and is used for selecting copied or moved requirements from the filtered list. The second window has the filter deactivated and is used for pasting moved or copied requirements, creating new sub-sections when needed, and adding new derived requirements.

1. Open Second ReqView Window: To open the second window, select View→New Window from the main menu. Place both windows side by side or on different monitors. In the left window, leave the filter active, it will be our source window.

2. Deactivate Filter: In the right window, deactivate the filter, it will be the target window. To toggle the filter, click on the left side of the filter box (or press CtrlAltF).

3. Add Document Sub-sections: In the right window, select the section “4.1.5 The Transportation Cart” (UNEXssdd-60), and add two new sub-sections under it:

   • “4.1.5.1 Transportation Cart Upper-Level Requirements” (UNEXssdd-135), and
   • “4.1.5.2 Transportation Cart Top-Level Design (UNEXssdd-136)”.

4. Move Requirements: In the left window, select the seven requirements (UNEXssdd-122 and UNEXssdd-127 through UNEXssdd-132) and press CtrlX (or right-click on a selected requirement and select Cut from the context menu, or select Edit→Cut from the main menu). The selected requirements will be highlighted in blue and will display icon in the ID column.

   In the right window, select the section “4.1.5.1 Transportation Cart Upper-Level Requirements” (UNEXssdd-135), press CtrlV (or right-click the section and select Paste from the context menu, or select Edit→Paste from the main menu), and finally select Paste As Child from the popup. All seven requirements will appear in their new location.

We still have to handle requirements UNEXssdd-117 and UNEXssdd-134 allocated to both the Transportation Cart and the Storage Container. Although both are shared requirements, they fall into two distinct categories: the requirement UNEXssdd-117 is a functional requirement that applies to multiple sub-systems, while the requirement UNEXssdd-134 is an interface requirement. The handling of each category will be described next.

3. Handle Requirements Allocated to Multiple Sub-systems:

Requirement “The robot and the support equipment width shall enable their hauling inside narrow mine tunnels and openings (0.6 meters).” (UNEXssdd-117) is a functional requirement that applies to three sub-systems: the Robot, the Transportation Cart, and the Storage Container.

We will handle this kind of requirement by leaving the upper-level requirement (UNEXssdd-117) in its current place, and copying it into separate derived requirements for the Transportation Cart and the Storage Container (the Robot already has the size requirement independently, and thus we do not need to create a duplicated derived requirement).

To handle the requirement UNEXssdd-117:

1. Create Derived Requirement: Add a new requirement at the end of the section “4.1.5.1 Transportation Cart Upper-Level Requirements”.

   Right-click UNEXssdd-132, which is the last requirement in section, and select Add After from the context menu. Set its description to: “The transportation cart width shall enable their hauling inside narrow mine tunnels and openings (0.6 meters).”

   This creates the requirement UNEXssdd-137.

2. Set Requirement Attributes: Update the new requirement UNEXssdd-137 as follows:

   • Set the attribute Type to “Requirement”.

   • Set the attribute Requirement Type to “Functional Requirement”.

   • Set the attribute Sub-systems to “Transportation Cart”.

3. Link Requirements: Right-click the derived requirement UNEXssdd-137 and select Start Link from the context menu. Then right-click the source requirement UNEXssdd-117 and select Place Link from the context menu. In the Create Links dialog, select “Derivation” as the link type from the dropdown list and click OK.

   Deriving a new requirement from UNEXssdd-117 for the Storage Container, using the exact same technique, can be handled now or alternatively delayed to the time when we deal with the storage container sub-system. We will defer this until later.

4. Handle Interface Requirements:

Requirement “The transportation cart and the storage container will include means to securely harness the storage container onto the transportation cart.” (UNEXssdd-134) is actually an interface requirement that applies to the Transportation Cart and the Storage Container (although, erroneously, not marked as such).

We will move interface requirements into the appropriate sub-section of section “4.3 Interface design” (UNEXssdd-18). If such sub-section does not yet exist, we will create one prior to moving the first requirement into it.

Interface requirements, as defined in the SSS document, may be general and usually need further decomposition into detailed derived requirements in order to technically design and specify the exact interface. These derived requirements should be inserted into the appropriate sub-system sections at the current phase.

To handle the interface requirement UNEXssdd-134:

1. Add Subsection: Create a new sub-section under the section “4.3 Interface design” (UNEXssdd-18) to store requirements describing interfaces between the Transportation Cart and the Storage Container sub-systems.

   To do this, right-click the section “4.3.1 Interface identification and diagrams” (UNEXssdd-20) and select Add After from the context menu. Set the section heading to “Transportation Cart – Storage Container Interfaces”.

   This creates the section “4.3.2 Transportation Cart – Storage Container Interfaces” (UNEXssdd-138).

2. Move Requirement: To cut the requirement UNEXssdd-134, select the requirement and press CtrlX. To paste the requirement at the new location, select the target section UNEXssdd-138, press CtrlV, and select Paste as Child from the popup.

3. Mark As Interface Requirement: To mark the requirement UNEXssdd-134 as “Interface Requirement” (correcting the omission) set the attribute Requirement Type to “Interface Requirement” in addition to the current “Functional Requirement” and “Safety Requirement” values.

4. Create Derived Requirement: Add a new object at the end of the section “4.1.5.1 Transportation Cart Upper-Level Requirements” (UNEXssdd-135).

   Right-click UNEXssdd-137, which is the last requirement in section, and select Add After from the context menu. Set its description to “The transportation cart will include means to securely harness the storage container onto the transportation cart.”

   This creates the requirement UNEXssdd-139.

5. Set Requirement Attributes: Update the new derived requirement UNEXssdd-139 as follows:

   • Set the attribute Type to “Requirement”.

   • Set the attribute Requirement Type to the same values as the original requirement UNEXssdd-134: “Functional Requirement”, “Interface Requirement”, and “Safety Requirement”.

   • Set the attribute Sub-Systems to “Transportation Cart”.

6. Link Requirement: Right-click the derived requirement UNEXssdd-139 and select Start Link from the context menu. Then right-click the source requirement UNEXssdd-134 and select Place Link from the context menu. In the Create Links dialog, select “Derivation” as the link type and click OK.

In the same manner as in the previous section, we will defer deriving a new requirement from UNEXssdd-134 for the Storage Container until later.

5. Finalize Sub-system Requirements:

We have all requirements for the Transportation Cart sub-system in place now. Let us examine these requirements for correctness and completeness, and evaluate the needed level of further decomposition in order to demonstrate a viable, implementable and provable system solution. This examination leads to the following two conclusions:

• The requirements are clear, and do not present any great engineering or implementation challenges and/or risks. Thus, no further decomposition is needed at this level, and we can defer the actual design of the transportation cart to the next project development phase.

• We made a mistake during the initial requirement allocation when we allocated the requirement “A storage and transportation container will be designed for the robot.” (UNEXssdd-122) to the Transportation Cart instead of to the Storage Container sub-system.

To finalize the system design phase for the Transportation Cart:

1. Create Implementation Links: As we explained in the Section Traceability of Sub-system Requirements to Implementation, implementation links provide the definitive proof that each requirement is satisfied by a specific deliverable.

   You can conveniently create all implementation links at once.

   To create the links, right-click the section “4.1.5 The Transportation Cart” (UNEXssdd-60) and select Start Link from the context menu. Then select requirements UNEXssdd-127 to UNEXssdd-132, UNEXssdd-137 and UNEXssdd-139 located in section “4.1.5.1 Transportation Cart Upper-Level Requirements” (UNEXssdd-135), right-click and select Place Link from the context menu. In the Create Links dialog, select “Implementation” as the link type and click OK.

2. Correct Allocation of Requirement: We need to fix allocation of the requirement UNEXssdd-122.

   Select this requirement and change the attribute Sub-systems to “Storage Container”.

   Move the requirement back to the section “4.1.1 Top-Level (UNEXsss) Requirements Allocation” (UNEXssdd-56), right after the requirement UNEXssdd-121. To do so, right-click UNEXssdd-122, select Cut from the context-menu, then right-click UNEXssdd-121, select Paste, and finally select Paste After from the popup.

3. Add Conclusion: Under sub-section “4.1.5.2 Transportation Cart Top-Level Design” (UNEXssdd-136), add an information object stating that we defer the design of the Transportation Cart to a later development phase due to its relative simplicity and lack of risks.

You can clone the UNEXsys project at its current state from the GitLab repository ReqView > Starter Guide > UNEXsys ch7-s3_analyze_transportation_cart or download the project folder unexsys-ch7-s3_analyze_transportation_cart.zip.

Analyze Storage Container Sub-system

The Storage Container is yet another simple sub-system, at least from the system design perspective of the UNEX project. The functional analysis and system design phase of the Storage Container is very similar to that of the Transportation Cart, which was presented in the previous section. Therefore, we will cover it only briefly.

1. Add Document Sub-sections:

   Under the section ”4.1.6 The Storage Container” (UNEXssdd-61), create two new sub-sections:

   • ”4.1.6.1 Storage Container Upper-Level Requirements” (UNEXssdd-141) and
   • ”4.1.6.2 Storage Container Top-Level Design” (UNEXssdd-142).

2. Identify Upper-level Requirements:

   Apply the relevant filter:  Type: Requirement Upstream Links is set Sub-systems: Storage Container.

   As a result, the following seven requirements are displayed: UNEXssdd-117, UNEXssdd-122 to UNEXssdd-126, and UNEXssdd-134. As before, some are allocated solely to the Storage Container, while others are also allocated to other sub-systems.

3. Handle Requirements Allocated to Single Sub-system:

   Move all requirements that are allocated solely to the Storage Container (UNEXssdd-122 to UNEXssdd-126) under the section ”4.1.6.1 Storage Container Upper-Level Requirements” (UNEXssdd-141).

4. Handle Requirements Allocated to Multiple Sub-systems:

   Create a new requirement UNEXssdd-143 derived from the requirement UNEXssdd-117 and place it at the end of the section ”4.1.6.1 Storage Container Upper-Level Requirements” (UNEXssdd-141).

   Update the derived requirement UNEXssdd-143 as follows:

   • Set the description to “The storage container width shall enable their hauling inside narrow mine tunnels and openings (0.6 meters).”.
   • Set the attribute Type to “Requirement”.
   • Set the attribute Requirement Type to “Functional Requirement”.
   • Set the attribute Sub-systems to “Storage Container”.

   Finally, link the derived requirement UNEXssdd-143 to its source requirement UNEXssdd-117 using the Derivation link type.

5. Handle Interface Requirements:

   Create a new requirement UNEXssdd-144 derived from the requirement UNEXssdd-134 and place it at the end of the section ”4.1.6.1 Storage Container Upper-Level Requirements” (UNEXssdd-141).

   Update the derived requirement UNEXssdd-144 as follows:

   • Set the description to “The storage container will include means to securely harness the storage container onto the transportation cart.”.
   • Set the attribute Type to “Requirement”.
   • Set the attribute Requirement Type to “Functional Requirement”, “Interface Requirement” and “Safety Requirement”.
   • Set the attribute Sub-systems to “Storage Container”.

   Finally, link the derived requirement UNEXssdd-144 to its source requirement UNEXssdd-134 using the Derivation link type.

6. Finalize Sub-system Requirements:

   The requirements of the Storage Container are clear, and do not present any great engineering or implementation challenges and/or risks. Thus, no further decomposition is needed at this level, and we can defer the actual design to the next project development phase.

   Link all requirements in section ”4.1.6.1 Storage Container Upper-Level Requirements” (UNEXssdd-141) to the object ”4.1.6 The Storage Container” (UNEXssdd-61) using the Implementation link type, to provide the definitive proof that each requirement is satisfied by a specific deliverable.

   Under the section ”4.1.6.2 Storage Container Top-Level Design” (UNEXssdd-142), add an information object UNEXssdd-145 stating that we defer the design of the Storage Container to a later development phase due to its relative simplicity and lack of risks.

This concludes the decomposition of the Storage Container sub-system in the system design phase.

You can clone the UNEXsys project at its current state from the GitLab repository ReqView > Starter Guide > UNEXsys ch7-s4_analyze_storage_container or download the project folder unexsys-ch7-s4_analyze_storage_container.zip.

Analyze Underwater Exploration Vehicle (Robot) Sub-system

The UNEX Underwater Exploration Vehicle (the Robot) is by far the most complicated sub-system in our project, and also poses the most significant development risks. To demonstrate that we have a viable and robust system design, we will need to further detail its design.

To decompose the robot we will carry out steps 3. Allocate System Requirements and 4. Organize and Refine Sub-system Requirements described in the Section Sub-system Requirements Development Process, and then we will reiterate, decomposing the robot into sub-systems and repeating the process. For some of the Robot sub-systems, we will demonstrate a partial design process.

The key question here is how to implement the re-iteration in a precise, yet work-efficient manner. Given the complexity, the Robot will clearly require its own sub-project (called a Linked Project in ReqView) to contain its requirements, top-level design, verification documents (test plan and test description document(s)), and probably risk reduction plan. The dilemma here is how to divide the work between the current, system-wide SSDD, and the future requirements and design artifacts in a ReqView sub-project for the Robot. There are three possible approaches:

All three approaches are viable, each with its distinct trade-offs. Approach I is the traditional, fully hierarchical approach. Approach II has the benefit that all relevant Robot design is done in a single document (the Robot SSDD in the Robot project) instead of being split between two documents (the system level SSDD and the Robot SSDD) as in Approach I. This improves focus and prevents errors. There are no real drawbacks to this method: we have to create the Robot sub-project anyhow, so we just do it earlier instead of doing it in the next development phase. Approach III is a customized version of approach II, saving an extra document (a separate Robot SSS) and an extra level of requirements copying and linking, while also creating the opportunity for a clearer, concise SSDD.

We will use Approach III in the UNEX project. In this section we will handle Robot requirements in the UNEXssdd document: allocate requirements and process Robot requirements that are interface requirements or that are assigned to additional sub-system(s). This is an already familiar process, so we will describe its steps briefly:

1. Add document sub-sections
2. Identify upper-level requirements
3. Handle requirements allocated to a single sub-system
4. Handle requirements allocated to multiple sub-systems
5. Finalize sub-system requirements

Before finalizing the Robot requirements in the UNEXssdd, we also need to formalize the design decisions that we took in UNEXssdd section 3. System-wide Design Decisions as requirements because we skipped it.

In the next Chapter 8, we will cover the creation of the Robot sub-project with the customized SRDD and the top-level Robot decomposition.

Let us briefly detail the steps of handling the Robot requirements in the UNEXssdd document:

1. Add Document Sub-sections:

Under the section “4.1.2 The UNEX Underwater Exploration Vehicle (or Robot)” (UNEXssdd-57), create sub-section “4.1.2.1 Robot Requirements” (UNEXssdd-146).

Note that for other sub-systems, we created subsections “<sub-system> Upper-Level Requirements” and “Additional <sub-system> Requirements”. For the Robot sub-system, we create a single sub-section only because we will separate the Robot sub-system into another ReqView sub-project and move all the Robot requirements to this ReqView sub-project in the next Chapter 8. Remember that the placement of requirements into subsections, as well as the subsections headings, serve only ordering and ease-of-reading purpose. They are not supposed to affect the engineering work — decomposition and design. You may create the “regular” two subsections if you prefer.

2. Identify Upper-level Requirements:

Set the table view to Requirements Allocation and apply the relevant filter:  Type: Requirement Upstream Links is set Sub-systems: Robot.

Activating the filter reveals all requirements allocated to the Robot: UNEXssdd-62 to UNEXssdd-91, UNEXssdd-93 to UNEXssdd-99, UNEXssdd-102, UNEXssdd-103, UNEXssdd-111 to UNEXssdd-116, UNEXssdd-118 to UNEXssdd-121 and UNEXssdd-133. Some requirements are allocated solely to the Robot, while others are also allocated to additional sub-systems.

3. Handle Requirements Allocated to Single Sub-system:

Move all requirements allocated solely to the Robot (UNEXssdd-62 to UNEXssdd-69, UNEXssdd-71, UNEXssdd-73 to UNEXssdd-78, UNEXssdd-81, UNEXssdd-87 to UNEXssdd-89, UNEXssdd-113 to UNEXssdd-121 and UNEXssdd-133) to the section “4.1.2.1 Robot Requirements” (UNEXssdd-146).

4. Handle Requirements Allocated to Multiple Sub-systems:

Let us examine remaining requirements. There are requirements allocated to:

• Robot & Charger (UNEXssdd-79, UNEXssdd-80, UNEXssdd-82, and UNEXssdd-84 to UNEXssdd-86) and
• Robot & Mission Station (UNEXssdd-70, UNEXssdd-72, UNEXssdd-91, UNEXssdd-93, UNEXssdd-94, UNEXssdd-96 to UNEXssdd-99, UNEXssdd-102, UNEXssdd-103, UNEXssdd-111 and UNEXssdd-112).

We can now process all remaining requirements. As in previous sub-systems, the processing order is unimportant; we will process Robot-Charger requirements first, then Robot-Mission Station requirements.

4.1 Handle Robot & Charger Requirements:

1. Change the filter to match requirements with the attribute Sub-system set to “Robot” and “Charger”:

    Type: Requirement  Upstream Links is set  Sub-systems: Robot  Sub-systems: Charger

   The filtering will result in six requirements: UNEXssdd-79, UNEXssdd-80, UNEXssdd-82 and UNEXssdd-84 to UNEXssdd-86.

2. Create two SSDD sub-sections:

   • “4.1.3.1 Charger Upper-Level Requirements” (UNEXssdd-147) under the section “4.1.3 The Robot Charger” (UNEXssdd-58) and
   • “4.3.3 Robot - Charger Interfaces” (UNEXssdd-148) under the section “4.3 Interface design” (UNEXssdd-18).

3. Process the filtered Robot & Charger requirements:

   • “The robot batteries can be loaded or charged while the robot is in water.” (UNEXssdd-79) is a functional requirement from the Robot and the Charger, and an interface requirement between the Robot and the Charger.

     • Move it to the section “4.3.3 Robot - Charger Interfaces” (UNEXssdd-148).

     • In section “4.1.2.1 Robot Requirements” (UNEXssdd-146), derive a new requirement with the same text description (UNEXssdd-151), mark it as a functional requirement, allocate it to the Robot, and add a Derivation link to the requirement UNEXssdd-79.

     • In section “4.1.3.1 Charger Upper-Level Requirements” (UNEXssdd-147), derive a new requirement “The Charger will be able to charge the robot batteries while the robot is in water.” (UNEXssdd-152) mark it as a functional requirement, allocate it to the Charger, and add a Derivation link to the requirement UNEXssdd-79.

   • “The robot will be powered by chargeable batteries.” (UNEXssdd-80) is a functional requirement from the Robot only.

     • Set its attribute Sub-system to “Robot”.
     • Move it to the section “4.1.2.1 Robot Requirements” (UNEXssdd-146).

     We do not need to derive any further requirements since the relevant Charger requirements already exist:

     • “The project will implement a robot charger …” (UNEXssdd-83) and
     • “The robot charger will be able to charge the robot batteries to their full capacity in 5 hours maximum.” (UNEXssdd-84).

   • “The charging control circuitry will be able to report the battery charge status to the robot main controller and to the battery charger.” (UNEXssdd-82) imposes functional requirements in the Robot and the Charger sub-systems and an interface requirement between these sub-systems. It also aggregates two functional requirements into one (reporting the battery charge status to the robot controller and to the charger). We need to separate the aggregated requirement and then to handle the interface (and functional) requirement:

     • In section “4.1.2.1 Robot Requirements” (UNEXssdd-146), derive a new requirement “The charging control circuitry of the robot will be able to report the battery charge status to the robot main controller.” (UNEXssdd-153), mark it as a functional requirement, allocate it to the Robot, and add a Derivation link to the requirement UNEXssdd-82.

     • In section “4.3.3 Robot - Charger Interfaces” (UNEXssdd-149), derive a new requirement “There will be an interface so that the charging control circuitry in the Robot will be able to report the battery charge status to the battery charger.” (UNEXssdd-154) mark it as a functional and interface requirement, allocate it to the Robot and Charger sub-systems, and add a Derivation link to the requirement UNEXssdd-82.

     • In section “4.1.2.1 Robot Requirements” (UNEXssdd-146), derive a new requirement “The charging control circuitry in the Robot will report the battery charge status to the battery charger using the stated interface.” (UNEXssdd-155), mark it as a functional and interface requirement, allocate it to the Robot, and add a Derivation link to the requirement UNEXssdd-154.

     • In section “4.1.3.1 Charger Top-Level Requirements” (UNEXssdd-148), derive a new requirement “The Charger will be able to monitor the battery charge status of the Robot using the stated interface.” (UNEXssdd-156), mark it as a functional and interface requirement, allocate it to the Charger, and add a Derivation link to the requirement UNEXssdd-154.

   • “The robot charger will be able to charge the robot batteries to their full capacity in 5 hours maximum.” (UNEXssdd-84) is a functional requirement for the Robot and the Charger and an interface requirement between these sub-systems.

     • Move this requirement under sub-section “4.3.3 Robot - Charger Interfaces” (UNEXssdd-148), mark it as an interface requirement (in addition to being a functional requirement), and change its text description “The robot charger will be able to charge the robot batteries to their full capacity in 5 hours maximum and the interface should facilitate this charging capability.”

     • In section “4.1.2.1 Robot Requirements” (UNEXssdd-146), derive a new requirement “The robot batteries will be able to be charged to their full capacity in 5 hours maximum by the robot charger using the stated interface.” (UNEXssdd-157), mark it as a functional and interface requirement, allocate it to the Robot, and add a Derivation link to the requirement UNEXssdd-84.

     • In section “4.1.3.1 Charger Top-Level Requirements” (UNEXssdd-148), derive a new requirement “The robot charger will be able to charge the robot batteries to their full capacity in 5 hours maximum using the stated interface.” (UNEXssdd-158), mark it as a functional and interface requirement, allocate it to the Charger, and add a Derivation link to the requirement UNEXssdd-84.

   • “The robot charger will display the charging status of the robot's batteries, the remaining time to full charge, and its own technical status.” (UNEXssdd-85) is a requirement solely for the Charger. We will correct the allocation and handle it with other Charger requirements.

     • Set the attribute Sub-systems to “Charger”.

   • “If possible, charging will be implemented as wireless charging.” (UNEXssdd-86) is both a functional requirement for the Robot and the Charger and an interface requirement between these sub-systems.

     • Move this requirement under the sub-section “4.3.3 Robot - Charger Interfaces” (UNEXssdd-148).

     • In section “4.1.2.1 Robot Requirements” (UNEXssdd-146), derive a new requirement with the same text description (UNEXssdd-159), mark it as a functional requirement, allocate it to the Robot, and add a Derivation link to the requirement UNEXssdd-86.

     • In section “4.1.3.1 Charger Top-Level Requirements” (UNEXssdd-148), derive a new requirement with the same text description (UNEXssdd-160), mark it as a functional requirement, allocate it to the Charger, and add a Derivation link to the requirement UNEXssdd-86.

4.2 Handle Robot & Mission Station Requirements:

1. Change the filter to match requirements with the attribute Sub-system set to “Robot” and “Mission Station”:

    Type: Requirement Upstream Links is set Sub-systems: Robot Sub-systems: Mission Station.

2. Create three SSDD sub-sections:

   • “4.1.4.1 Mission Station Top-Level Requirements” (UNEXssdd-149) under the section “4.1.4 The Mission and Robot Control Station” (UNEXssdd-59) and
   • “4.3.4 Robot - Mission Station Interfaces” (UNEXssdd-150) under the section “4.3 Interface design” (UNEXssdd-18).

   After examining the listed Robot & Mission Station requirements, it is clear that they belong to three distinct categories: data exchange requirements, control requirements, and physical interface requirements. To group requirements according to these categories: create three SSDD sub-sections under the section “4.3.4 Robot - Mission Station Interfaces” (UNEXssdd-150):

   • “4.3.4.1 Robot-Mission Station Data Exchange Requirements” (UNEXssdd-161),
   • “4.3.4.2 Robot-Mission Station Control Requirements” (UNEXssdd-162), and
   • “4.3.4.3 Robot-Mission Station Physical Interface Requirements” (UNEXssdd-163).

3. Process the listed Robot & Mission Station requirements:

   • “The robot will be able to create an online map of the environment for navigation purposes.” (UNEXssdd-70) is a functional requirement for the Robot only (the Mission Station already has the requirement UNEXssdd-94 that covers the Mission Station side). We will reallocate this requirement to the Robot only.

     • Set the attribute Sub-systems to “Robot”.
     • Move the requirement into the section “4.1.2.1 Robot Requirements” (UNEXssdd-146).

   • “The robot will be able to use previous information about the map: both historical information from the mine or from previous surveys, incrementally.” (UNEXssdd-72) is a functional requirement for the Mission Station only to compose such maps.

     • Rephrase the requirement description to: “The mission station will be able to compose mine maps, to be later used by the robot, using all available previous information and/or maps: both historical information from the mine or from previous surveys, incrementally.”
     • Set its attribute Sub-systems to “Mission Station”.
     • Move it into the section “4.1.4.1 Mission Station Top-Level Requirements” (UNEXssdd-149).

   • “The Mission Design System will implement a GUI, enabling the operator to control all related activities.” (UNEXssdd-91) is a functional requirement for the Mission Station only (specifying the interface to the operator).

     • Set its attribute Sub-systems to “Mission Station”.
     • Move it to the section “4.1.4.1 Mission Station Top-Level Requirements” (UNEXssdd-149).

   • “The Mission Design System will enable the operator to specify the desired area for exploration in the next robot mission.” (UNEXssdd-97) is a functional requirement for the Mission Station only because the corresponding interface requirement UNEXssdd-93 already exists.

     • Set its attribute Sub-systems to “Mission Station”.
     • Move it to the section “4.1.4.1 Mission Station Top-Level Requirements” (UNEXssdd-149).

   • “The Mission Design System will facilitate the loading of mine maps, marked with desired exploration area, to the Robot.” (UNEXssdd-93) is a data exchange requirements for the interface between the Robot and the Mission Station.

     • Rephrase the requirement description.
     • Mark the requirement as a functional and interface requirement.
     • Move it to the section “4.3.4.1 Robot-Mission Station Data Exchange Requirements” (UNEXssdd-161).
     • In section “4.1.4.1 Mission Station Top-Level Requirements” (UNEXssdd-149), derive a new requirement UNEXssdd-164, rephrase it, mark it as a functional requirement, allocate it to the Mission Station, and add a Derivation link to the requirement UNEXssdd-93.
     • In section “4.1.2.1 Robot Requirements” (UNEXssdd-146), derive a new requirement UNEXssdd-165, rephrase it, mark it as a functional requirement, allocate it to the Robot, and add a Derivation link to the requirement UNEXssdd-93.

   • “The Mission Design System will be able to receive the actual path explored by the robot in a given mission (timestamped location data + distance to walls/obstacles).” (UNEXssdd-94) is also a data exchange requirements for the interface between the Robot and the Mission Station and we will handle it the same way as the previous requirement UNEXssdd-93.

     • Rephrase the requirement description, mark it as a functional and interface requirement, and move it to the section “4.3.4.1 Robot-Mission Station Data Exchange Requirements” (UNEXssdd-161).
     • In section “4.1.4.1 Mission Station Top-Level Requirements” (UNEXssdd-149), derive a new requirement UNEXssdd-166.
     • In section “4.1.2.1 Robot Requirements” (UNEXssdd-146), derive a new requirement UNEXssdd-167.

   • “The Mission Design System will be able to load from the robot the environmental exploration data collected in the mission and to store it for future reference.” (UNEXssdd-99) is copied from UNEXsss-174 (with the exact same wordings) and is composed of two separate requirements: a data exchange requirement for the interface between the Robot and the Mission Station, and a storage requirement for the Mission Station only. We will split it into two distinct requirements.

     • First, we will make UNEXssdd-99 the data exchange requirement for the interface. Rephrase the requirement UNEXssdd-99 to “There will be an interface that will allow The Mission Design System to load the environmental exploration data collected in the mission from the robot.”. Mark it as a functional and interface requirement, and move it to the section “4.3.4.1 Robot-Mission Station Data Exchange Requirements” (UNEXssdd-161).

     • Then, in section “4.1.4.1 Mission Station Top-Level Requirements” (UNEXssdd-149), derive from UNEXssdd-99 a new requirement “The Mission Design System will be able to load the environmental exploration data collected in the mission from the robot, using the stated interface.” (UNEXssdd-168).

     • Finally, complete the storage requirement for the Mission Station fulfilling only part of the original UNEXssdd-99 (copied from UNEXsss-174). In section “4.1.4.1 Mission Station Top-Level Requirements” (UNEXssdd-149), create a new requirement “The Mission Design System will be able to store the environmental exploration data collected in the mission by the robot for future reference.” (UNEXssdd-169). Link the new UNEXssdd-169 requirement directly to the originating UNEXsss-174 requirement, which is now fully fulfilled by the two requirements: UNEXssdd-99 and UNEXssdd-169.

     • In section “4.1.2.1 Robot Requirements” (UNEXssdd-146), derive a new requirement from UNEXssdd-99: “The robot will be able to transfer the environmental exploration data collected in the mission to the mission station.” (UNEXssdd-170). This requirement specifies the Robot side requirement for implementing the interface.

   • The requirements UNEXssdd-96, UNEXssdd-98, UNEXssdd-102 and UNEXssdd-103 are control requirements between the Robot and the Mission Station. Using the same procedure for handling interface requirements:

     • Rephrase them and move them to the section “4.3.4.2 Robot-Mission Station Control Requirements” (UNEXssdd-162).
     • For each requirement, derive two requirements, one in section “4.1.2.1 Robot Requirements” (UNEXssdd-146) and the other in section “4.1.4.1 Mission Station Top-Level Requirements” (UNEXssdd-149). The derived requirements are: UNEXssdd-171 and UNEXssdd-172 from UNEXssdd-96, UNEXssdd-173 and UNEXssdd-174 from UNEXssdd-98, UNEXssdd-175 and UNEXssdd-176 from UNEXssdd-102 and UNEXssdd-177 and UNEXssdd-178 from UNEXssdd-103.

   • “The robot system shall have a wireless communication for easy setup and parametrization.” (UNEXssdd-112) is a physical interface requirement between the Robot and the Mission Station. Using the same procedure for handling interface requirements:

     • Rephrase it and move it to the section “4.3.4.3 Robot-Mission Station Physical Interface Requirements” (UNEXssdd-163).
     • In section “4.1.4.1 Mission Station Top-Level Requirements” (UNEXssdd-149), derive a new requirement UNEXssdd-179.
     • In section “4.1.2.1 Robot Requirements” (UNEXssdd-146), derive a new requirement UNEXssdd-180.

   • “The robot shall be capable of constant communication with a base station during the mission while the robot is up to 500 meters underwater.” (UNEXssdd-111) is also a physical interface requirement between the Robot and the Mission Station. However, according to our design decision UNEXssdd-54, documented in section “3.2.4 Final Decision and Justification”, this requirement needs a major refinement.

     • Move UNEXssdd-111 into section “4.3.4.3 Robot-Mission Station Physical Interface Requirements” (UNEXssdd-163), rephrase it to match our design decision and add a Derivation link to UNEXssdd-54.
     • In section “4.1.4.1 Mission Station Top-Level Requirements” (UNEXssdd-179), derive a new requirement UNEXssdd-181.
     • In section “4.1.2.1 Robot Requirements” (UNEXssdd-146), derive a new requirement UNEXssdd-182.

5: Finalize Sub-system Requirements

To finalize the Robot requirements in the UNEXssdd, we must formalize the design decisions UNEXssdd-42, UNEXssdd-43 and UNEXssdd-54 in the SSDD section 3. System-wide Design Decisions. We will create a derived requirement for each design decision object and link it to the corresponding design decision using the Derivation link type. You should do this as soon as design decisions are created, in order not to leave them uncovered by matching requirements, and thus without appropriate implementation.

In section “4.1.2.1 Robot Requirements” (UNEXssdd-146), derive new requirements UNEXssdd-183 and UNEXssdd-184 from the design decisions UNEXssdd-42 and UNEXssdd-43 and allocate them to the Robot sub-system.

Design decision UNEXssdd-54 was already handled by changing the requirement UNEXssdd-111 to reflect it and linking the two objects with the Derivation link type.

Analyze Charger Sub-system

Handling the requirements of the Charger is simple, and follows the same procedure:

1. Add Document Sub-sections:

   We already created the necessary sub-section “4.1.3.1 Charger Top-Level Requirements” (UNEXssdd-147) when handling the Robot & Charger requirements.

2. Identify Upper-level Requirements:

   Apply the relevant filter:  Type: Requirement Upstream Links is set Sub-systems: Charger.

   Activating the filter reveals all requirements allocated to the Charger. Out of these, only two requirements are allocated solely to the Charger: UNEXssdd-83 and UNEXssdd-85.

3. Handle Requirements Allocated to Single Sub-system:

   Move both requirements UNEXssdd-83 and UNEXssdd-85 under the section “4.1.3.1 Charger Top-Level Requirements” (UNEXssdd-147).

Analyze Mission Station Sub-system

Since our goal is not to design the complete system but rather to demonstrate a development process using ReqView, we will stop here and will not handle the Mission Station requirements and top-level design, leaving it as an exercise for enthusiastic ReqView users. This will also enable us to demonstrate later how ReqView can help identify missing and/or incomplete work.

You can clone the UNEXsys project at its current state from the GitLab repository ReqView > Starter Guide > UNEXsys ch7_s6_7_8_Robot_Charger_Mission_subsystems or download the project folder unexsys-ch7_s6_7_8_Robot_Charger_Mission_subsystems.zip.

Sub-system Interface Design

Principles of Sub-system Interface Design

Interface Design is another important aspect of the system top-level design. The designer needs to consider and to balance multiple aspects during the system and sub-system interface design in order to produce long-standing, efficient and useful design:

• Stability: The interface should be stable enough to serve as a reliable contract between the participating sub-systems, allowing parallel development by separate teams without constant renegotiation.

• Adaptability and Scalability: The interface should be designed to accommodate evolving requirements and technical evolution throughout project development, as well as to allow future growth (e.g., increases in capacity, throughput, or functionality) without requiring fundamental redesign.

• Level of Details: Over-specifying interfaces, particularly when done prematurely, can constrain innovation and can create costly rework when inevitable changes occur, while under-specifying them risks integration failures and delayed discovery of implementation incompatibilities.

• Low Coupling: Sub-systems should depend on each other as little as possible. The interface should be as simple and minimal as possible, isolating sub-systems from each other's internal implementation.

• High Cohesion: Each sub-system should be self-contained and focused. Related functionality should be kept within the same sub-system rather than spread across multiple sub-systems. While this is more a sub-system design criterion rather than an interface design criterion, its implementation (or lack thereof) highly influences the interface. Sub-systems that have high cohesion usually result in clear and minimal interfaces, while sub-systems that lack it result in complex and bloated interfaces.

• Completeness: The interface should define all necessary parameters to ensure correct and unambiguous interaction between the participating sub-systems, leaving no critical aspect undefined.

• Verifiability: Every interface requirement should be verifiable — it must be possible to confirm that the interface has been correctly implemented by each of the participating sub-systems.

• Standardization: Where possible, use established industry standards (e.g., standard connectors, protocols, data formats) rather than proprietary solutions. When correctly selected, this will enable the use of proven technologies, algorithms, hardware and software and will reduce cost, risk, and integration complexity.

• Safety and Security: The interface should not introduce safety hazards or security vulnerabilities, especially in environments where failure could cause harm or data compromise.

Designing an interface is much like a tango dance – moving together in a back and forth manner between the involved sub-systems. We have already identified some functional and interface requirements during the sub-systems decomposition but these requirements are rarely enough. Completing the interface design may require making design decisions, and/or deriving more requirements affecting the involved sub-systems.

Parallel decomposition and design work on multiple sub-systems, common in projects of non-trivial size, demonstrates this challenge. As different teams work simultaneously, previously hidden interdependencies emerge, requiring coordinated updates across affected sub-systems. This iterative interaction between sub-systems is natural and expected.

For example, the design of the Robot sub-system (described in the next Chapter 8) is conducted in parallel with design of other sub-systems in the main SSDD (described in this Chapter), uncovering requirements and design decisions that necessitated updates to both, thereby illustrating the bidirectional nature of interface development.

Interface Control Documents (ICDs) or appropriate sections in the SSDD/SRDD serve as binding contracts between teams. Thus, the timing of interface definition completion is particularly critical: interfaces must be frozen sufficiently early in the project schedule to allow parallel work on different sub-systems, to prevent downstream rework, and to allow procurement of long-lead items, but not so prematurely that teams still lack the technical maturity to make informed decisions. A staged approach to interface definition often works best, with early versions capturing critical constraints and later versions adding detailed specifications. Therefore, it is common for interface design documents to have several revisions, with the final revision containing all technical details to a contractual level, which should be reviewed in a formal design review.

Sub-system Interface Design Steps

Designing good interfaces, like many other system design activities, requires engineering skills, experience, and art. Following the next steps can help obtain optimal results:

1. Scan known interface requirements and identify alternatives

2. Obtain required design data

3. Evaluate possible interface design alternatives

4. Complete the design of the selected alternative

5. Update involved sub-systems requirements and design when necessary

Remember that interface design, like other system engineering activities, is an iterative process. The steps are listed sequentially, but there will be cases where you will need to iterate. For example, you may elect to concentrate on a promising design solution, but later data may render this approach unviable, forcing you to make an additional design iteration through steps 3 to 4, or sometimes even 2 to 4.

Let us detail each step:

1. Scan Interface Requirements and Identify Alternatives:

Thoroughly examine all available requirements and data, including possible design constraints of the participating sub-systems. Identify hidden requirements, assumptions, and possible design alternatives.

2. Obtain Required Design Data:

For each design alternative you selected, identify all required data needed in order to complete the design of the interface. For example, when designing a charging interface, the needed power is crucial. This power is a derivative of the battery capacity (and the maximum required charging time). The battery capacity, in turn, is a derivative of the sub-system design, which may not be completed or known yet. In such cases, you can use upper bounds to complete the interface design. Be aware that too-high bounds may unnecessarily complicate the interface design, and also that these bounds should be checked against the actual system design, when available, to make sure that they were not violated.

3. Evaluate Interface Design Alternatives:

Using all the requirements at hand, the possible design alternatives, and the design data obtained, evaluate the leading alternatives and select the best one. Clearly document the reasons for this selection.

4. Complete Interface Design:

Now that you have a selected concept, complete its design details to the required level, according to the principles discussed in the Section Principles of Sub-system Interface Design.

5. Update Involved Sub-systems Requirements and Design:

It is quite common that interface design results in the need to update some of the requirements or parts of the design of the involved sub-systems. These updates may include:

• Creating new derived requirements, which result from the characteristics of defined interfaces.

• Refining existing requirements according to the characteristics of the defined interfaces.

• Moving existing Derivation links to new interface requirements, which better describe the requirements fulfillment hierarchy.

When necessary, update the requirements and design of the involved sub-systems.

This step, although described here sequentially, can also be performed iteratively, integrated with other steps during the interface design.

Top-level Architecture of UNEX System

We will start with a preliminary top-level architecture diagram, containing the UNEX sub-systems and our current knowledge of the various sub-systems interfaces:

This is a preliminary interfaces diagram. We will update the diagram to include the interfaces IDs, and add it to section “4.3.1 Interface identification and diagrams” (UNEXssdd-20) later.

In our prior work, we have created the following interfaces sub-sections, putting the relevant interface requirements into them:

• “4.3.2 Transportation Cart – Storage Container Interfaces” (UNEXssdd-138)

• “4.3.3 Robot – Charger Interfaces” (UNEXssdd-148)

• “4.3.4 Robot – Mission Station Interfaces” (UNEXssdd-150)

We have not referred to other interfaces yet.

Since our goal is to demonstrate a development process using ReqView rather than to design the complete system, we will demonstrate the design of a single interface between the Robot and the Charger sub-systems in section “4.3.3 Robot – Charger Interfaces” (UNEXssdd-148).

Design Robot – Charger Sub-system Interfaces

Let us follow the steps outlined in the Section Sub-system Interface Design Steps for the interface between the Robot and the Charger.

1. Scan Interface Requirements and Identify Alternatives:

All known Robot-Charger interface requirements are currently placed under section “4.3.3 Robot – Charger Interfaces” (UNEXssdd-148). These requirements are:

• “The robot batteries can be loaded or charged while the robot is in water.” (UNEXssdd-79).

• “There will be an interface so that the charging control circuitry in the Robot will be able to report the battery charge status to the battery charger.” (UNEXssdd-154).

• “The robot charger will be able to charge the robot batteries to their full capacity in 5 hours maximum and the interface should facilitate this charging capability.” (UNEXssdd-84).

• “If possible, charging will be implemented as wireless charging.” (UNEXssdd-86).

Let us identify relevant design alternatives. From the requirements, we can conclude that the Robot’s sealing and simplicity of operation are the leading considerations (i.e., relatively short charging time, preference of wireless charging to assure the pressure sealing of the hull, and ability to charge while the Robot is in the water).

For the Robot's batteries, we have the following options:

• Non-rechargeable batteries, replaced through a hull opening.
• Rechargeable batteries, replaced through a hull opening.
• Rechargeable batteries, wired charging.
• Rechargeable batteries, wireless charging.

The first two options require battery replacement through a hull opening. The Robot will require quite large batteries, weighing several kg, to support the thrusters and the large number of sensors during a 5-hour mission. This will require a considerable opening, complicating our ability to assure the pressure sealing of the hull. Replaceable batteries also place considerable and contradicting constraints on the mechanical design: normally, the batteries should be placed in the lowest possible position, since stability dictates that the center of mass of the Robot will be lower than the center of buoyancy. We would also like to be able to place the batteries in a way that minimizes constraints on other sub-systems – for example dividing them between sub-systems, or using them as a part of other sub-systems. This cannot be done with field-replaceable batteries, where the accessibility through the opening dictates packaging and positioning.

Therefore, we rule out the first two options. Our leading solution will be using rechargeable batteries, and charging them either using a charging cable or wirelessly.

Now, we can create the required subsections in the SRDD, move the interface requirements into the proper subsection and document the design alternatives:

1. Create the following subsections of “4.3.3 Robot – Charger Interfaces” (UNEXssdd-148):

   • “4.3.3.1 Robot – Charger Interfaces Requirements” (UNEXssdd-185)
   • “4.3.3.2 Robot – Charger Interfaces Design Considerations” (UNEXssdd-186)
   • “4.3.3.3 Robot – Charger Interfaces Design” (UNEXssdd-187)

2. Select all Robot – Charger interfaces requirements (UNEXssdd-79, UNEXssdd-154, UNEXssdd-84 and UNEXssdd-86), press CtrlX, select the new parent section UNEXssdd-185, press CtrlV, and select Paste as Child.

3. Create a new object UNEXssdd-188 under sub-section “4.3.3.2 Robot – Charger Interfaces Design Considerations” (UNEXssdd-186) and document the design alternatives in its text description.

2. Obtain Required Design Data:

In order to select the appropriate charging method and further decompose the design, we need one key parameter - the charging power:

• For wired charging, the required power is needed in order to determine which available charging protocols are relevant (like QC 3.0).

• For wireless charging, the value is critical, since wireless charging is limited in power.

However, the Robot’s required total power is not yet known. This is a common phenomenon. The typical way to handle such situations is to estimate the value, usually by consulting with experts, and ensuring that the design includes appropriate margins.

For this tutorial, we consulted AI models as our “experts”. The question asked was:

“Please provide an estimate for the electric power bank capacity (Watthours) for an underwater exploration vehicle for a 5-hour mission. The vehicle has a round shape of 60 cm diameter, capable of exploring up to 5 km and depth of 500 meters, using eight thrusters for 5DoF motion (a ballast system will control Heave) at speeds of 1-2 km/hour and water speed of 1-2 meters/second. The vehicle has 10 measuring instruments like video cameras, DVL, acidity meter, etc., and computers to control the whole operation including recording of video and all sensors throughout the mission”.

The answers from three AI “experts” are as follows:

• Claude.ai (2 iterations): 1.6-2 kWh (recommend 2.2 kWh)
• ChatGPT (2 iterations): 1.3-1.6 kWh
• Gemini (3 iterations): 1.8-2.2 kWh

Getting different estimates from different experts is common, even with real human experts.

Let us assume a required power capacity of 2-2.5 kWh, and make sure that the interface will be able to grow in capacity if needed.

To record this information, create a new object UNEXssdd-189 after the object UNEXssdd-188 and document the information in its text description.

3. Evaluate Interface Design Alternatives:

Now that we have the required power capacity of the Robot’s batteries, we can evaluate the feasibility and complexity of the two charging techniques: wireless and wired. The requirement to charge a 2-2.5 kWh battery in five hours maximum means that the charging interface should support a charging rate of 400-500W.

Let us evaluate the two possible charging methods:

• Wireless Charging:

  • The hull diameter of the Robot is 60 cm. The surface of the hull serves as a mounting point for the thrusters and for most of the environmental sensors. This leaves about 8-10 cm as the maximum possible diameter of a wireless charging antenna.

  • According to our expert (AI “expert” Gemini), standard inductive coupling (like the Qi standard) where the transmitter and receiver are nearly touching, has a standard limit of about 15 to 25W (Qi 2.0/2.2). Using special techniques like high-quality Litz wire and specialized ferrites, 100 to 200W can be handled.

  • When using wireless charging, there is an efficiency factor involved: about 85–90% at a distance of 0.5–1.0 cm.

  The conclusion is that using wireless charging and conforming to the required charging time is impossible when using standard techniques. Even when using the best special techniques and doubling the antenna area, the required power cannot be achieved.

• Wired Charging:

  • Charging power of 500W using a charging voltage of 24 Volts translates to a current of 21 Amps. These are very convenient numbers: 24 Volts is very good from safety perspectives, especially in a wet environment, and 21 Amp current requires 12-14 AWG wires, which are not too thick.

  • Industry standard connectors are available, both for Dry-Mate and the more complex Wet-Mate connection system. Dry-Mate connectors are waterproof when connected, but need to be dry when making the connection/disconnection. Wet-Mate connectors can be connected when immersed in water, but are significantly bigger, heavier and more complex.

  • The required charging power rules out the use of industry standard chargers using charging protocols like QC 3.0 or PD 2.0, which are limited to 250W. A proprietary charger will need to be implemented.

  Overall, implementing wired charging is a robust, safe, and expandable solution. If more power is needed, either current can be increased (resulting in thicker conductors) or the charging voltage can be doubled, still staying relatively low.

Using wireless charging for the UX1 Robot cannot provide a robust solution, nor an expandable one. Therefore, we decide to implement wired charging.

To capture this design decision, create a new object UNEXssdd-190 with general information about the analysis, a new object UNEXssdd-191 describing the wireless charging option and a new object UNEXssdd-192 describing the wired charging option.

Note that we prefer to place the analysis of each possible charging method in its own ReqView object to ease future reference. However, this is not mandatory, and you can write the whole analysis in the same ReqView object.

4. Complete the Interface Design:

We can now summarize the interface design:

1. Create the following new objects after the object UNEXssdd-192 and place the following text inside it:

   • “The Robot will use wired charging.” (UNEXssdd-194)

   • “The charging voltage at the Robot side will be TBD – 24V or close to it. The Robot design will determine the final value. Rationale: The lowest voltage that allows charging while maintaining relatively low current. 22.2 V may be even more convenient, since it corresponds to a 6-cell Li-Po/Li-ion configuration commonly referred to as 6S, while requiring only 10% current increase.” (UNEXssdd-195)

   • “Charging current will be up to 22.5 Amps (500W @ 22.2V, Robot side). This will allow the use of 10 AWG cable.” (UNEXssdd-196)

   • “To compensate for the voltage drop over the cable, the charging control circuitry in the Robot will report the exact voltage achieved on the Robot side, so that the charger will be able to adjust the charging voltage accordingly.” (UNEXssdd-197)

   • “The interface type used for reporting the battery charge status from the charging control circuitry in the Robot to the Charger will be TBD – to be selected from CAN-bus, RS-422 or 100 Mbps Ethernet. The Robot design will decide on the interface type and the protocol. This will allow the Robot design team flexibility based on other system considerations and design decisions.” (UNEXssdd-198)

   • “The charging cable will include at least two 10 AWG wires for power and 2 pairs of twisted shielded signal wires for implementing the communication protocol between the Charger and the Robot’s charging control unit. Rationale: this can support CAN bus, RS-422 or 100 Mbps Ethernet, so the decision on the actual protocol to be used can be deferred. There are commercially available suitable cables, for example LAPP ÖLFLEX SERVO FD 7TCE 4G10AWG+(2X18AWG)+(2X16AWG).” (UNEXssdd-199)

   • “The connector type used on the Robot side is TBD. The connector type will be decided by the Robot design. There are commercially available suitable connectors, for example the Glenair SeaKing 700 Series (PEEK version).” (UNEXssdd-200)

   • “The connector used on the Charger side is TBD. Preferably, the charger will use the same connector type as the one used on the Robot side. The Charger design will decide on the connector type.” (UNEXssdd-201)

2. Select all objects created in Step 1 and set their attributes using the inline editor in the corresponding column in the table view:

   • Set the attribute Type to ”Requirement”.
   • Set the attribute Requirement Type to “Design Decision” and “Interface Requirement”.
   • Set the Sub-systems attribute to “Robot” and “Charger”.

3. Select requirements UNEXssdd-195, UNEXssdd-198, UNEXssdd-200, and UNEXssdd-201 and set their attribute TBD/TBR to “TBD” using the inline editor.

4. Create an Implementation link from UNEXssdd-194 to UNEXssdd-86 because this design decision actually implements the interface requirement UNEXssdd-86. Since wireless charging was optional, a decision not to implement it also fulfills the requirement.

   Had UNEXssdd-86 specified wireless charging as mandatory, we would need to obtain the stakeholders’ approval for dropping the requirement.

5. Create a Derivation link from UNEXssdd-194 to UNEXssdd-79, from UNEXssdd-196 to UNEXssdd-84, from UNEXssdd-198 to UNEXssdd-154, and from UNEXssdd-199 to UNEXssdd-198.

5. Update Involved Sub-systems Requirements and Design:

Since we have not done this during the interface design, now is the time to examine whether we need to update some of the requirements or parts of the design of the Charger or the Robot.

Our interface design includes a charging cable. The Robot requires a certain voltage at the Robot side in order to successfully implement the charge (UNEXssdd-195). The charging uses relatively high current (up to 22.5 Amps), and the voltage drop on the cable may be non-negligible. The common solution for such cases is to monitor the actual charging voltage obtained on the Robot side and to adjust the Charging voltage that the Charger produces accordingly. Another possible solution, not selected here, is to use much higher wire gauge, such that the voltage drop will be negligible.

In order to implement this solution, we need to add and update some requirements:

1. Update requirements UNEXssdd-154, UNEXssdd-155, and UNEXssdd-156 to include the actual charging voltage received in the charge status reported to the Charger by the charging control circuitry in the Robot.

   Change the text description of UNEXssdd-154 to “There will be an interface so that the charging control circuitry in the Robot will be able to report the battery charging voltage and the battery charge status to the battery charger.” (add the underlined text).

   Make similar changes to the text description of UNEXssdd-155 and UNEXssdd-156. Check any requirements derived from them throughout the traceability chain and update these, if necessary, as well.

2. Create a Derivation link from UNEXssdd-197 to UNEXssdd-154, since UNEXssdd-197 is derived from UNEXssdd-154 (specifies part of UNEXssdd-154 required implementation).

3. Add a new functional requirement to the Charger, requiring it to adjust the charging voltage according to the charging voltage reported by the robot, so that the required charging voltage (by the requirement UNEXssdd-195) will be maintained.

   Create new section “4.1.3.2 Additional Charger Requirements” (UNEXssdd-202) after section “4.1.3.1 Charger Top-Level Requirements” (UNEXssdd-147).

   In this new section, create a new object UNEXssdd-203 with text description “The charger will adjust the charging voltage according to the charging voltage reported by the Robot, so that the required voltage on the robot side will be maintained.”.

4. For the new object UNEXssdd-203:

   • Set the attribute Type to “Requirement”.
   • Set the attribute Requirement Type to “Functional Requirement”.
   • Set the attribute Sub-Systems to “Charger”.

5. Create a Derivation link from the new object UNEXssdd-203 to the requirement UNEXssdd-195.

Completeness and Consistency Checks

Once we reach a point where the system design seems complete, there is one critical step remaining before it truly is: completeness and consistency checks. During the lengthy design process, particularly for large-scale systems, omissions and errors are unavoidable. Leaving them uncorrected increases the risk of project failure and leads to significant schedule delays and cost overruns.

Some of the most common completeness and consistency checks include the detection of the following problems:

1. Unallocated Requirements: Requirements are not allocated to any sub-systems.

2. Requirements Allocated to Extra Sub-systems: Requirements are wrongly allocated to one or more sub-systems, in addition to the sub-system(s) they should be allocated to.

3. Requirements Allocated to Wrong Sub-systems: Requirements are not allocated to the sub-systems that should implement them but to other sub-systems.

4. Unhandled Requirements: Requirements are not implemented at the end of the requirements derivation chain.

5. Untraceable Requirements: Requirements cannot be traced back to a parent requirement, a design decision, or a stakeholder/system need.

6. Sub-systems With No Requirements: Sub-systems exist in the design but have no requirements allocated to them. This indicates either a design error or missing requirements.

7. Requirements Without Proper Verification: Requirements have no associated verification method, or have a verification method inconsistent with its parents. This makes it impossible to confirm that they are sufficiently met.

8. Requirements With Inconsistent Traceability: Requirements whose traceability links contain errors, such as circular dependencies or reversed Derivation / Implementation links.

9. Duplicate Requirements: Requirements appear more than once, possibly worded differently, leading to redundant or conflicting implementations.

10. Conflicting Requirements: Requirements contradict each other, either within the same sub-system or across sub-systems.

11. Interface Mismatches: Sub-systems define their interfaces differently than the sub-systems they connect to (e.g., different data formats, protocols, or units).

The traditional way of carrying out these checks was a manual, human review of all requirements and design. While human check is imperative and is the only kind of check that may discover deep, system-knowledge domain errors, it is also prone to the same factors that caused most of the errors in the first place: human errors.

This is exactly the place where ReqView capabilities provide valuable help. With the use of filters, attributes, template columns and reports, you can easily detect whether such omissions or inconsistencies exist, complete the omissions and fix the inconsistencies. In the next subsections, we will demonstrate how you can carry out these completeness and consistency checks with the help of ReqView.

Please keep in mind that since the purpose of our tutorial is to demonstrate the usage of ReqView in a real-life, non-trivial size project and not to fully develop the project, our design is far from being at the point of “seems to be complete”. This means that the completeness and consistency checks will detect a lot of incomplete work, much more than in a typical project where the design is really at this phase. As before, we will concentrate on demonstrating the techniques on parts of the project – implementing them on the other parts is left for the interested user.

1. Unallocated Requirements:

Check that the design document does not contain requirements that are not allocated to any sub-system, since these will not be implemented. If we followed our process, described in Allocate UNEX System Requirements to Sub-systems thoroughly, there should be no such requirements.

This check is straightforward. Apply the following simple filter to the UNEXssdd:  Type: Requirement NOT Sub-systems is set. Note that the second is true when no value is assigned to the attribute Sub-systems.

The result of this filter is a list of all unallocated requirements. If the list is not empty, you should allocate every requirement in the list to the appropriate sub-system(s) and fully decompose it, since it was not decomposed during the system design process.

In our UNEXssdd, the result is an empty list. All requirements are allocated as they should be.

2. Requirements Allocated to Extra Sub-systems:

Check for requirements that are wrongly allocated to one or more sub-systems, in addition to the sub-system(s) they should be allocated to. This is a common consistency error, occurring when the user derives a requirement by copying it together with all its attributes, and forgets to adjust the sub-system attribute of the newly derived requirement.

In order to carry out this check, we will use ReqView filtering capability together with the document structure. Each “4.1.x” sub-section, starting at 4.1.2, needs to contain all requirements of the specific sub-system described by that subsection, e.g., “4.1.2 The UNEX Underwater Exploration Vehicle (or Robot)” (UNEXssdd-57) contains all the requirements assigned to the Robot sub-system. The rationale is that this sub-section is used as the basis for further decomposition, design and development – possibly by a separate team – of the said sub-system, and therefore has to be complete and self-contained regarding that sub-system. Thus, all the requirements should, as a general rule that usually should not be broken, be assigned only to the current sub-system, which is the Robot in our example.

Similarly, we need to check the interfaces subsections. Each “4.3.x” sub-section, starting at 4.3.2, needs to contain all requirements of the specific interface described by that subsection, and each requirement should be allocated to all sub-systems that need to adhere to this interface, e.g., all requirements contained in subsection “4.3.3 Robot - Charger Interfaces” (UNEXssdd-148) should be allocated both to the Robot and to the Charger sub-systems.

Let us demonstrate the process on the Charger sub-system described in section “4.1.3 The Robot Charger” (UNEXssdd-58):

1. Apply the following filter to the UNEXssdd document:  Type: Requirement Section: 4.1.3.

   The ReqView table view displays the list of all requirements from the section “4.1.3 The Robot Charger” (UNEXssdd-58) including all its subsections. In our case, these are requirements UNEXssdd-83, UNEXssdd-85, UNEXssdd-152, UNEXssdd-156, UNEXssdd-158, UNEXssdd-160, and UNEXssdd-203. Your screen will look like:

   

   Out of these requirements, UNEXssdd-83, UNEXssdd-85 and UNEXssdd-203 are allocated only to the “Charger”, which should be the case with all requirements. UNEXssdd-152, UNEXssdd-156, UNEXssdd-158 and UNEXssdd-160, however, are allocated to the “Robot” as well as to the “Charger”, so we have to check this double allocation.

2. To examine these requirements in the full document context, open a second ReqView window:

   • Select View→New Window from the main menu to open the second window.
   • In the second window, select Document→Filter from the main menu (or press CtrlAltF) to deactivate the filter.

3. Examine the requirement UNEXssdd-152:

   To go to the requirement, select Document→Goto” from the main menu (or press CtrlG), enter “152”, and hit Enter.

   We see that the requirement UNEXssdd-152 was derived from the requirement UNEXssdd-79 so the next step is examining requirement UNEXssdd-79. We derived this from the upper-level system requirement UNEXsss-103. We rightfully assigned requirement UNEXssdd-79 to the Robot and to the Charger sub-systems, since it affects both.

   Then, during the decomposition process, we derived two requirements from UNEXssdd-79: one for the Robot subsystem (UNEXssdd-151), and one for the Charger sub-system (UNEXssdd-152). However, we left the Sub-systems attribute of both derived requirements unchanged, copied from UNEXssdd-79, so both remain assigned to the Robot and to the Charger sub-systems. Yet, UNEXssdd-151 should be assigned solely to the Robot sub-system and UNEXssdd-152 solely to the Charger sub-system.

   To fix this problem:

   • Go to UNEXssdd-152, and change its Sub-systems attribute to “Charger” only, since it is a Charger only requirement.

   • Go to UNEXssdd-151, and change its Sub-systems attribute to “Robot” only, since it is a Robot only requirement. You can do this when you process the Robot sub-system in section “4.1.2 The UNEX Underwater Exploration Vehicle (or Robot)” (UNEXssdd-57) but it is better practice to correct errors as soon as discovered and not deferring it to a later time.

4. Examine the requirement UNEXssdd-156:

   The redundant allocation to the Robot sub-system is a result of the same cause – forgetting to update the Sub-systems attribute of requirements UNEXssdd-155 (to Robot only) and UNEXssdd-156 (to Charger only) when we derived them from UNEXssdd-154.

   Correct the assignment by changing the Sub-systems attribute of UNEXssdd-155 to “Robot” only and UNEXssdd-156 to “Charger” only.

5. Examine the requirements UNEXssdd-158 and UNEXssdd-160:

   The cause of the redundant allocation to the Robot sub-system of requirements UNEXssdd-158 and UNEXssdd-160 is also the same.

   Correct the assignment by changing the Sub-systems attribute of UNEXssdd-157 and UNEXssdd-159 to “Robot” only, and by changing the Sub-systems attribute of UNEXssdd-158 and UNEXssdd-160 to “Charger” only.

After the last corrections, all requirements on the filtered ReqView window show Charger as the solely assigned sub-system for the whole section “4.1.3 The Robot Charger” (UNEXssdd-58). Our check of the Charger sub-system is now complete.

Repeating this process for the Mission Station sub-system described in section “4.1.4 The Mission and Robot Control Station” (UNEXssdd-59) reveals that we did not update the Sub-systems attribute while deriving requirements common to Robot and the Mission Station as well.

Fix the following derived requirements for the Mission Station and the Robot. The parent (upper-level) deriving requirements displayed in the third column are brought here to understand context, and need no fix:

Checking sections “4.1.5 The Transportation Cart” (UNEXssdd-60), “4.1.6 The Storage Container” (UNEXssdd-61) and “4.1.2 The UNEX Underwater Exploration Vehicle (or Robot)” (UNEXssdd-57) shows that no other requirements need correction. The same holds true when checking all “4.3.x” sub-sections.

Note that you can check the sections in any order. Usually, you should check them by the document order, starting with “4.1.2” and going onward, just to make sure that you do not forget any section. In the tutorial, we chose to start with section “4.1.3 The Robot Charger” instead of starting with section “4.1.2 The UNEX Underwater Exploration Vehicle (or Robot)” for a purely pedagogic reason, since section “4.1.2” contains many requirements, and we wanted our demonstration to start with a smaller number of requirements.

3. Requirements Allocated to Wrong Sub-systems:

Requirements allocated to the wrong sub-systems may be overlooked during implementation. In the SSDD, these errors take one of three forms:

The first two cases happen when the Sub-systems attribute does not match the SSDD section containing the requirement. ReqView provides great help in spotting and correcting these errors.

To check for such requirements, we will use the same filtering capability together with the document structure as in the previous section. This time, we will check that the “Sub-Systems” attribute of each requirement in section “4.1.x” (starting at 4.1.2) and in section “4.3.x” (starting at 4.3.2) does not contain allocation to any irrelevant sub-system(s).

Since this check is very close to Check 2. Requirements Allocated to Extra Sub-systems described in the previous Section, both checks can be combined. First setup the filter and do the Check 2. Then, before moving to the next sub-system, scan the Sub-systems attribute for all filtered requirements and ensure that no requirement contains allocation to irrelevant sub-system(s).

If you detect that a requirement contains allocation to irrelevant sub-system(s), you need to inspect the requirement, and resolve the problem by either updating the value of the Sub-systems attribute (Case I), or moving the requirement to the correct document section (Case II).

Inspecting our UNEXssdd does not reveal any requirement that seems to be allocated to the wrong sub-system that falls under the first two cases.

In Case III, the requirement allocation is a design error, masked by a Sub-systems attribute and document section that are consistent with each other, but both are wrong. This kind of error can only be discovered by a reviewing system engineer, since this requires the examination of the requirement description and matching it against the allocated sub-system(s). ReqView helps here by its filtering ability, helping to see the wood for the trees, but detection needs to be done by an expert.

In order to detect such cases, we need to inspect the correctness of the requirement allocation subsection by subsection, one sub-system or interface group at a time.

Let us inspect the Robot-Charger interface requirements, appearing in subsection "4.3.3 Robot - Charger Interfaces" (UNEXssdd-148). First, apply the following filter to the UNEXssdd document:  Type: Requirement Section: 4.3.3.

Then, inspect the following two derived requirements assigned to the Robot and the Charger:

• “The charging cable will include at least two 10 AWG wires for power and 2 pairs of twisted shielded signal wires for implementing the communication protocol between the Charger and the Robot’s charging control unit.” (UNEXssdd-199)

• “The connector used on the Charger side is TBD. Preferably, the charger will use the same connector type as the one used on the Robot side. The Charger design will decide on the connector type.” (UNEXssdd-201)

Both requirements reside in the right document section, are marked as interface requirements, and are assigned to both sides of the interface. “At face value”, everything looks right.

However, the requirement UNEXssdd-199 describes the charging cable and is not a Robot interface requirement because the Robot is only interested in what it gets through the charging connector.

Similarly, the requirement UNEXssdd-201 describes the connector on the Charger side and is not a Robot interface requirement because this connector has nothing to do with the Robot.

We have identified a classic example of requirements that are allocated to the wrong sub-system. The cable is not allocated correctly – it is an entity, not an interface. The connectors at both of its sides are interfaces. In general, this issue has two possible solutions:

• Make the entity a separate sub-system.

• Include the entity as part of another sub-system.

In this case, there is no point in adding the cable as an additional sub-system. We decide to include the cable as part of the Charger sub-system. To implement this solution:

1. Move requirements UNEXssdd-199, UNEXssdd-201 to subsection “4.1.3.2 Additional Charger Requirements” (UNEXssdd-202).

2. For all these requirements, remove “Robot” from the values of the “Sub-systems” attribute, leaving them allocated solely to the Charger sub-system.

4. Unhandled Requirements:

Verifying that requirements have been fully decomposed and derived as necessary is the system engineer's responsibility. However, once correctly decomposed, ReqView provides valuable help in verifying that every requirement is implemented, and spotting the ones that are not. This is done by identifying requirements that do not derive any further requirements (i.e., are “leaf” requirements suitable for implementation and not needing further decomposition) and yet do not have an incoming Implementation link.

To detect unhandled requirements, apply the following filter to the UNEXssdd document:  Type: Requirement NOT Derives NOT Is implemented by

The result will display all unimplemented requirements. Recall that we marked implementation only for the Transportation Cart and the Storage Container sub-systems, so there will be quite a number of unimplemented requirements in our UNEXssdd right now, reminding us that the design is far from complete.

You can easily further break the list into sub-systems, filtering the requirements not yet implemented by a given sub-system. Just add a condition matching only requirements allocated to the sub-system. For instance, adding the condition  Sub-systems: Charger filters just the unhandled requirements allocated to the Charger as shown in the following screen:

Filtering requirements allocated to either the Transportation Cart or the Storage Container sub-systems reveals an empty list, as it should, since we assigned all their requirements to the Transportation Cart and the Storage Container physical deliverables, respectively.

5. Untraceable Requirements:

Requirements that cannot be traced back to a parent system requirement or a design decision, or are not marked as a design decision themselves, raise the question of why they exist. They are either wrong or are actually design decisions that we forgot to mark.

Such requirements need inspection and decision:

• If a requirement is actually a design decision, just add the value “Design Decision” to its Requirement Type attribute.

• If it is a requirement, link it to the parent requirement from which it was derived.

• If it is neither a design decision nor a requirement remove the Requirement from the Type attribute, or delete the object entirely, as appropriate.

To detect all requirements that are not linked to a parent and are not a design decision, apply the following filter to the UNEXssdd document:  Type: Requirement NOT Is derived from NOT Requirement Type: Design Decision

The filter reveals that there are no untraceable requirements.

6. Sub-systems With No Requirements:

Sub-systems that do not have any requirements allocated to them indicate missing requirements or a design error. Therefore we need to verify that all sub-systems in the design have requirements allocated to them.

When there is a relatively small number of sub-systems, the straightforward, semi-manual check is the easiest approach:

1. Verify that the Sub-systems attribute contains all sub-systems as enumeration values. To check this, select Document→Customize Attributes from the main menu. In the Document Attributes dialog, expand the definition of the Sub-systems attribute and check that all your sub-systems are defined as enumeration values.

2. For each sub-system, apply the following filter to the UNEXssdd document:  Type: Requirement Sub-systems: <sub-system>

   The filter displays all requirements allocated to this sub-system.

   Check that the list is not empty. Empty list means that no requirements are allocated to the current sub-system under examination, which signals a problem.

If you have a large number of sub-systems, semi-manual check can be tedious. In this case, the check can be automated by generating a custom report, using the ReqView Custom Template Export capability. While this is quite an advanced topic and requires some learning curve, it provides enormous flexibility, and AI can help in making it accessible like never before. Creating ReqView Custom Template Export reports may be presented in a future Tutorial chapter.

7. Requirements Without Proper Verification:

Verifying that each requirement is sufficiently met is crucial for successful project implementation. In order to meet this challenge, the system engineer needs to specify the verification method(s) required to be used in verifying each requirement. In the UNEX project, we specify the required verification methods using the multi-value enumeration attribute Verification Method.

There are two checks that need to be made regarding the verification of each requirement at this stage:

• Ensure that each requirement has at least one verification method assigned to it.

• Check whether derived requirements have been assigned at least all the verification methods used by their parent.

  While not always obligatory, the most common pattern is that every derived requirement needs to be verified using at least all verification methods required for its parents. Every exception needs inspection and approval (and, sometimes, changing the parent’s verification method as well).

To check that each requirement has at least one verification method assigned, just apply the following filter to the UNEXssdd document:  Type: Requirement NOT Verification Method is set

Your screen will look like:

We see that 27 requirements are currently missing a Verification Method value even though derived requirements were typically created by copying the parent requirement including its attributes.

There are several possible reasons for these cases:

• We did not set the Verification Method attribute even for the parent requirement (e.g., requirements UNEXssdd-90, UNEXssdd-69, UNEXssdd-172).

• We re-wrote the requirement without copying it, and did not set the Verification Method attribute while doing so.

• We derived the requirement from a design decision and we did not set the Verification Method attribute while doing so.

The exact reason is unimportant. You should fill all missing values. In the case of missing Verification Methods in upper-level documents containing the deriving requirement (e.g., UNEXsss), you should consult with the appropriate stakeholder, correct the upper-level document as well, and approve the correction.

Checking whether derived requirements have been assigned at least all the verification methods used by their parent is a bit more complicated, since it requires the traversing of the whole up-level derivation tree, verifying that all verification methods required by its parents are assigned to the derived requirement. This cannot be done by a simple filter, but it can be done by generating a custom report, using the ReqView Custom Template Export capability.

As mentioned before, this is a quite advanced topic and requires some learning curve. It provides enormous flexibility, and AI makes it very accessible. We may demonstrate creating ReqView custom reports in a future Chapter of this Tutorial.

To illustrate this approach for this task, we created the checkVerificationMethods.htm custom report using AI in about 20 minutes. To use the custom report, take the following steps:

1. Select File→Export→Custom Template to open the Export Using Custom Template dialog.

2. In the Table View section, select “Primary” from the dropdown list. In the Layout section, select the downloaded file checkVerificationMethods.htm.

3. Click OK.

4. Select the location (directory) for the report on your file system. The report will be named as the document name, UNEXssdd.htm in our example.

The report includes the following items for each requirement missing a parent requirement verification method:

• The requirement that is missing a parent’s verification method
• The parent requirement stating this verification method
• The verification method that is missing

For our UNEXssdd document, the report looks like:

Using this report, you have now a solid basis to make the required inspection and, if necessary, corrections. Please note that in this particular example, all these requirements have no verification methods assigned to them, and, as such, also showed up in the first check. There is some overlap between these two checks, but they are not identical. Both are required.

In the case where all requirements fulfill the testing requirements of the parent requirements, you will get a message notifying you so.

8. Requirements With Inconsistent Traceability:

Traceability link errors can prevent proper verification of the requirements tree, cause incomplete "what-if" change analysis, or provide false assurance that every requirement was implemented.

Examples of such errors include:

• Inverted Derivation Links: Derivation links that lead from upstream system requirements to downstream sub-system requirements or from design decisions to requirements have wrong direction.

  To fix these links, right-click a link, and select Reverse Link Direction from the context menu.

• Circular Dependencies: Derivation links with wrong direction can form a cycle (e.g., A derives from B, and B derives from A).

  To fix these links, right-click a link with wrong direction. and select Delete Link from the context menu.

• Inverted Implementation Links: Implementation links leading from requirements to the artifact implementing them (instead of vice-versa).

  To fix these links, right-click a link, and select Reverse Link Direction from the context menu.

You can use ReqView filters, template columns, custom reports (using the ReqView Custom Template Export capability) or a mix of these to detect most of these errors.

9. Checks Relying on Human Judgment:

As we demonstrated in the previous subsections, ReqView can provide broad and effective help in spotting many classes of completeness and consistency errors that can occur during requirements decomposition and system design. However, there are additional classes of errors whose detection relies almost entirely on human judgment. No tool can determine whether two requirements are semantically equivalent, whether they contradict each other, or whether an interface definition is consistent across sub-systems. These checks require an experienced system engineer who knows the system well.

Among these classes are:

• Duplicate Requirements: Requirements that appear more than once, possibly worded differently, leading to redundant or conflicting implementations.
• Conflicting Requirements: Requirements that contradict each other, either within the same sub-system or across sub-systems.
• Interface Mismatches: Where one sub-system defines an interface differently than the sub-system it connects to (e.g., different data formats, protocols, or units).

ReqView helps with these classes through its filtering capabilities, like those presented throughout this section, allowing the system engineer to focus on a selected relevant scope at a time, but the heavy lifting is human.

Finalize System/Subsystem Design Document

There are a few empty SSDD sections that we need to complete:

1. Complete section “1. Scope”

2. Complete section “2. Referenced documents”

3. Fill empty document sections

4. Delete unused document objects

5. Add all required appendices

Let us walk through these tasks.

1. Complete Section “1. Scope”:

Describe the scope of our system in section “1. Scope” (UNEXssdd-1):

• In sub-section “1.1 Identification” (UNEXssdd-2), identify the system to which the document applies.

• In sub-section “1.2 System overview” (UNEXssdd-4), state the purpose of the system to which the document applies.

• In sub-section “1.3 Document overview” (UNEXssdd-6), summarize the purpose and contents of the System/Subsystem Design document.

To get immediate help about the required contents of each sub-section, use the Instructions pane. To open the Instructions pane, select View→Right Panes→Instructions Pane (or press CtrlAltI).

For our UNEX project, open the UNEXssdd document and update description of the document objects UNEXssdd-3, UNEXssdd-5, and UNEXssdd-7.

2. Complete Section “2. Referenced documents”:

In section “2. Referenced documents”, reference all upper-level documents addressed by the SSDD. These can be the Stakeholder Requirements Specification documents, the System/Subsystem Requirements Specification documents, design documents, test plans, quality plans, or standards the system must adhere to.

You can also reference documents not required for the project development, such as prior designs and/or experience, preliminary research, or feasibility test results. We advise dividing the mandatory and other documents into two separate sub-sections. For each listed document reference, include the document title, number, revision, and date of publication.

For our UNEXssdd document:

1. Create sub-section “2.1 Mandatory referenced documents” (UNEXssdd-204) and add two document references:

   • “UNEXsss - UNEX System/Subsystem Specification. Revision: Git tag V1_0_SSS_version_for_SRR, Date: 2025-02-07 13:08.” (UNEXssdd-206)
   • “UNEXcreq - UNEX Customer Requirements Document. Revision: Git tag ch5_s4_check_consistency, Date: Oct 03, 2024” (UNEXssdd-207)

2. Create sub-section “2.2 Other referenced documents” (UNEXssdd-205) and leave it empty.

3. Fill Empty Document Sections:

Because we created the SSDD from a general-purpose SSDD-DID template based on the MIL-STD-498 standard, there may be some sections that contain an empty document object without any requirement or other descriptive text. That happens when the system, at least at the current abstraction level, contains no content related to the sub-section topic. While more common at the requirements specification phase, this might also happen during the design phase.

The best practice and an explicit MIL-STD-498 requirement is not to delete any empty document subsection. The rationale behind leaving all document subsections in place is to clarify what topics are not (yet) covered by the document, making it easier to assess, for example during a review, whether the omission is legitimate or the missing section should be completed.

You should walk through the document and place a short explanatory statement, such as “This sub-section was left blank intentionally” for all such empty subsections. The text might be a bit different depending on the topic of the section.

In our UNEXssdd document, update text description of three empty objects:

• UNEXssdd-9 under section “2.2 Other referenced documents”,
• UNEXssdd-27 under section “6 Notes”, and
• UNEXssdd-29 under section “7. Appendixes”

4. Delete Unused Document Objects:

There may also be unused objects located in non-empty sections, which were part of the document template, but we did not fill them because we created other objects instead. You may delete these objects.

Other unused objects are repeatable section headers, for which we created sibling project-specific section headers, for example, the objects “4.3.5 4.3.x (Project‑unique identifier of interface)” (UNEXssdd-22) and its empty child object UNEXssdd-23. You should permanently delete these surplus objects:

1. Press and hold Ctrl and select both objects UNEXssdd-22 and UNEXssdd-23.
2. Select Edit→Delete Objects from the main menu (or press CtrlDel).
3. Select Edit→Purge Objects→Purge Selected from the main menu (or press CtrlShiftDel).

5. Add Required Notes and Appendices:

You can add any necessary notes under section “6. Notes” (UNEXssdd-26) and/or appendixes under section “7. Appendixes” (UNEXssdd-28). We do not need to add any appendix in the document UNEXssdd.

You can clone the current project database to explore using the filters from the GitLab repository ReqView > Starter Guide > UNEXsys ch7_finalize_ssdd or download the project folder ch7_finalize_ssdd.zip.

Create Baseline of System/Subsystem Design Document

The SSDD is complete now. There is one more mandatory step before the System Design Review (SDR): freezing the current system design by creating a baseline of the System/Subsystem Design Document.

This step is essential because the SSDD is a live document, and changes in its contents are inevitable. Some changes can result from the SDR, others from new requirements coming during development, or even changes in stakeholder requirements (which happens often, despite being strongly discouraged).

We will create a baseline of the SSDD by tagging the current document revision in the Version Control System (VCS). The VCS tag serves as the version number of the SSDD, so you should use a clear and descriptive tag name like “SSDD_V1_0_for_SDR”. Having a clear tag for each document version will enable us to compare changes between the document versions. Note that the scope of Git tags is the whole repository, therefore it marks the specified baseline for all documents in the UNEXsys project.

With ReqView, you can easily create a baseline for the current status of the UNEXsys project using the Git History dialog. Select File→Git→History to open the dialog, right-click the last commit, select Create Tag from the context menu, and enter your desired, self-documenting tag name. For more detailed instructions, see the Section Create Baseline of System Specification Document in Chapter 6.

Publish System/Subsystem Design Document

Typically, the SDR requires distributing the SSDD (and, optionally, other required project documents as well) in a printable/viewable format (like PDF or DOCX) to all participants, regardless of their ReqView access.

To support this, as well as other needs, you can export ReqView documents in various predefined file formats:

• MS Word DOCX
• MS Excel XLSX
• HTML
• PDF
• CSV

You can also create a custom export template to customize the export of a ReqView document in these file formats or to generate files in another structured text format that suits your specific needs for data layout and visual style (such as XML or JSON, or MS Word DOCX using a custom defined document format).

The various ways to export and publish ReqView documents are thoroughly described in the Section Publish System Specification Document in Chapter 6, and will not be repeated here.