Frequently in my work as a systems engineer I’m faced with producing several artifacts for a project, typically a system architecture, model(s), requirements, safety analysis and risk analysis (management plan).

The challenge is many of these are treated as serial activities, items to be completed but not necessarily tied together.  To produce an architecture and requirements that reflect all of the known/identified issues we should be working on all of these activities concurrently or at the least have a first cut at the safety and risk analysis before starting the requirements.  From a project planning stand-point how these are shown on a schedule are driven by the size of the team and the project schedule.  “What do we need to complete a phase/gate review”  is how the schedule ends up being built versus what do we need to proceed with the systems design and architecture.

RISK ANALYSIS
The safety (FHA/PSSA) and the risk analysis are important elements to the development of good (i.e. clear, unambiguous and verifiable) requirements.  Including issues identified during these analyses will insure we develop mitigations for safety/risk issues, eliminate rework and for the case of avionics help identify the appropriate Design Assurance Level (DAL) that the project will be certified to.  This activity on any project can ensure that the correct level of Verification and Validation (V&V) is planned.

While we may all agree with the importance of following these steps, we also know that schedule demands and need to get a product to market as soon as possible can lead to push back.  The challenge then, whether leading a project team or serving as a team member, is completing the early risk work before starting with solicitation of requirements.   Management needs to understand the importance of these tasks and the impact they can have if not completed at the proper stage on a project.

As an example we’ll at risks for a medical device and how we would address these as part of the design process.  Let’s pick an AED (automated external  defibrillator), a device commonly found in public places such as theaters, schools and airports.  One risk is the device does not operate when applied to a patient, the result of a failed battery.  This results in delayed/no delivery of therapy and can result in patient death.  Obviously a high risk that must be mitigated. We would write requirements that the device perform a self-test every 24 hours and if the battery has failed a unit fail light is set. This would also require that the operation/user instructions for the device require facilities where the units are installed do a check that the fail light is not on and the unit is available for use.

An AED is meant to be used by anyone in an emergency situation, so the instructions need to be clear to any user. While the AED will provide verbal directions, as part of risk mitigation for the case where the person does not understand the commands, either hard of hearing or they do not understand the language used by the device, visual prompts such as the figure below are provided.

To successfully complete the requirements for any project we need to identify the risk up front, consider how to address (mitigate) them in the design, or whether they can be addressed by documentation such as the users manual or the aural messages to the user.

Bio:

Paul J. Kostek is a Principal of Air Direct Solutions, a systems engineering/project management consulting firm. He works with companies in defining system architecture, system requirements, interface definition, verification planning, risk management and software development standards. Paul received his BS from the University of Massachusetts, Dartmouth.   Paul works in a range of industries including: aerospace, defense, medical device and e-commerce.

Paul is a long-time volunteer with several professional engineering societies including IEEE, AIAA, SAE, INCOSE and PMI.  He also writes for the CERM Risk Insights emagazine.