Defining Requirements
Here’s where the Systems Engineer really goes into top gear. The task is to integrate all inputs from preceding phases and discussions to define requirements and elaborate them for each system and subsystem that comprise the overall product.
Requirements are “shall” statements which describe each essential product function. Meeting each requirement is necessary to create a product that fulfills user needs and regulatory expectations.
For example, because a User Need has been identified that declares, “the user needs to receive communication from the device on their cell phone,” a System Requirement might be written stating, “the system shall be capable of communicating via Bluetooth Low Energy.” Then, in order to comply with regulations governing cybersecurity, one or more system or subsystem-level requirements might additionally be written to ensure the authenticity, integrity, and availability of system communications.
The Systems Engineer is responsible for translating and decomposing User Needs downward through each level of the product, from system to subsystem, as well as for ensuring that the technical, subsystem, and system requirements trace cleanly back upward and will actually fulfill all of the User Needs.
Top-level requirements are Product or System Requirements, which are translated directly from User Needs. If the product consists of more than one discrete system capable of functioning as a medical device without the others, it may be desirable to nest a set of System Requirements below the Product Requirements.
Next, Subsystem Requirements derive from the System Requirements. Subsystems are discrete system elements that have no function or an incomplete function when isolated from the rest of the system, but are essential for the product to function as intended. Subsystem Requirements are elaborations from System-level Requirements into each subsystem they affect, with details scoped to just those aspects of the System Requirement that that subsystem has to be responsible for. In our example above, “the system shall be capable of communicating via Bluetooth Low Energy,” the requirement might simply be repeated as several subsystem requirements with the word “system” replaced with the subsystem name, such as “the app shall be capable of communicating with the device via Bluetooth Low Energy” and “the device shall be capable of communicating with the app via Bluetooth Low Energy.” Additional requirements might then be defined, either at the subsystem or technical level, to support and clarify these.
Below Subsystem Requirements are Technical Requirements, which describe the actual details of how each Subsystem Requirement will be met. The Systems Engineer generally will not determine these – they are left up to the developers to decide. However, the Systems Engineer will review their decisions to ensure that what is being implemented technically is adequate to fulfill higher-level requirements, and to ensure that developers who own subsystems are maintaining focus on subsystem and system interfaces, as well as the product as a whole.
We should pause for a moment to observe that it isn’t always possible or practical to decompose Requirements all the way down to the Technical level. In many cases, the precise details of technical implementation do not need to be defined, and doing so can constrain development unnecessarily. Part of the System Engineer’s job is to determine the reasonable limits of Requirements decomposition.
Design Outputs
Artifacts produced by Technical Requirements planning are a bit different than the overall Requirements set, which might be tracked using various tools to aid engineers and developers. Technical Requirements artifacts that build into the Device Master Record (DMR) include Architecture documents for software and hardware, which describes the subsystem elements at a high level and how they relate to each other and to other subsystems. From these are generated a Detailed Design document for software, which describes the function of each unit of code, as well as Schematics for hardware.
These artifacts are generally produced by project engineers, but the System Engineer will use them to develop an Interface Control Document, which describes the interface architecture between subsystems and subsystem elements and defines the system’s Communication Interface Protocol.
Architecture and Detail Design documents perform three critical services:
- They provide the functional bridge between Requirements and Implementation (discussed in our next post);
- They provide traceability from Design Inputs (Planning, Risk and Security Management, Human Factors, Requirements) to Design Outputs (Implementation and Integration);
- They enable the completion of a Test Plan, which describes the test types and methods that will be performed in order to systematically verify (“did we make the thing right?”) and validate (“did we make the right thing?”) the final design.
Determining requirements and developing design is deeply collaborative. Considerable expertise is required to determine the elements of each subsystem, which entails the kind of focused attention, AKA “tunnel vision,” which might create trouble down the road. By freeing subsystem developers from having to continuously keep every aspect of the project at the forefront of their thinking, the Systems Engineer facilitates elegant, highly-focused design of each piece of the puzzle. His or her job is to make sure the pieces will fit together, which in turn allows each development team to create the best possible piece for the project.