So, your company has decided to move ahead with the product! That means it’s time to map out the project schedule and resources and define how, exactly, this product will move from IP to reality.
Planning
For the Systems Engineer, work done during the Concept & Feasibility phase flows directly into the Planning phase. During planning, the project team is pulling together the User Needs – describing the product’s Intended Use in a series of Use Cases, developing a Risk Profile, and identifying “Reasonably Foreseeable” Misuse. The team is employing the results of that research and documentation to evaluate business considerations, including the cost to design, development, manufacture, and market the product, as well as potential impacts that the outcome could have on the business model, including liability and security concerns.
As all of this research is taking place, the Systems Engineer remains present and engaged. He or she must be aware of all inputs in order to do two things: (1) assist Project Manager(s) with resource planning, scheduling, and so on; and (2) ensure applicable Standards and Regulatory Requirements are identified and accounted for in the Project Plan. This is critically important. Compliance should not and often cannot be tacked on to the product as an afterthought. If an applicable regulatory requirement is identified later in the development process (or, worst of all, just prior to or even during submission), shifting the project to accommodate can blow budget and schedule, leave your team scrambling and stakeholders hanging. Securing the oversight of an expert Systems Engineer can help keep that from happening.
Risk Management, Security, and Human Factors
During this phase, which heavily overlaps the Design phase, work begins on a number of documents that will guide product development and build into the submissions package sent to regulators. These include:
- Preliminary Hazard Analysis (PHA), a top-down quality artifact that lays out all the possible ways that the product could expose the user to various risks, ranks those risks according to severity and probability, and describes a Requirement or Process which mitigates each hazard to an acceptably low level.
- Failure Mode Effects Analysis (FMEA), a bottom-up quality artifact that lists out product subcomponents, identifies the ways in which each could fail and the effects each failure could have on the user, ranks those failure modes according to severity and probability, and describes a Requirement or Process which mitigates the severity and probability of each failure mode.
- Risk Management Plan, a quality artifact that lays out all of the risk management activities that will and controls that will be implemented during product development – everything from processes to requirements implementation to risk-specific testing.
- Security Plan, a cybersecurity artifact built upon a thorough Vulnerability Assessment of the system design. While the Vulnerability Assessment analyzed the system to identify all known attack surfaces and methods to which each component and interface is vulnerable and ranks them according to complexity, impact type, and severity, the Security Plan describes each vulnerability and traces it to a mitigating Design Requirement.
Note that although work can (and often must) begin on these artifacts concurrent with design documents, it will generally not be possible to complete them until the project matures. Consider these living documents, drafted in lockstep with Design Phase documents (discussed in our next post), updated whenever Requirements are refined or changed, whenever new risk or security controls are implemented, and whenever processes are iterated or tools upgraded.
Although the Systems Engineer does not necessarily need to be the official owner of these documents, he or she is intimately involved in their creation, maintenance, and most likely will be the final technical signatory for each.
