How can you use risk analysis to improve system requirements?

Risk analysis is the systematic process to comprehend the nature and characteristics of risk, such as sources, events, consequences, likelihood, scenarios. Risk is the possibility of future events with negative deviations in relation to an objective. Risk analysis can be considered one of the aspects in a risk management framework which may include risk identification, assessment, control, communication.

Risk analysis in systems engineering involves evaluating potential problems that could disrupt a system's development or performance. I'd advise using it to refine system requirements. It helps identify and mitigate risks early, ensuring requirements are robust and feasible. By anticipating issues, requirements can be tailored to avoid or minimize impacts, leading to a more reliable and efficient system.

Análise de riscos deveria ser atividade obrigatória desde a análise de missão, ocorre que muitas vezes essa atividade é negligênciada ou quando é realizada, se faz de forma superficial. Aos tomadores de decisão ( gerentes, coordenadores e aos patrocinadores de projetos), fica o alerta...

In my experience, system requirements and risk analysis often do not elaborate or communicate use cases. They are written or evaluated by experts in their fields (EE, ME, SW, SE) but then installed or implemented by someone who is seeing the system/assembly for the first time. It takes quite a bit of experience to ignore your own expertise and see things through someone else's perspective. Once you can achieve this, the requirements and risk analysis are greatly improved. (recently proven by a system installation that had both +48V power and an RS485 communication bus on the same interface, a lot of magic smoke was released before they figured it out)

Let’s get more quantitative now that we have new, exciting forms of AI that actually enjoys crawling around in our datasets! Risk is threat plus vulnerability. Getting quantifiable vulnerability data is one of my mission goals for 2030.

Stufe 1: Man kann durchaus einen einfacheren Ansatz über die gewünschten Funktionalitäten machen. Auch ohne Design. Diese erste Hara führt zu den ersten Systemrequirements. Damit kann man ins System Design gehen und ein paar Varianten kreieren. Stufe 2: Über jede Variante dann noch mal die Hara vervollständigen und das jeweilige Set of Requirements bilden. Für die Varianten eine erste Kostenschätzung machen und beginnend bei der günstigsten auf Machbarkeit gegen die Systemrequirements prüfen. Stufe3: Da Firmen gern bestehende Lieferanten oder Prozesse nutzen ist es sogar möglich das eventuelle Wettbewerbsdesign abzuschätzen. Hara oder eben G&R sind das Powertool des System Designs und lebt von den genannten und ungenannten Requirements

The first requirement does not amplify much on the full range of items to address: boundaries, assumptions, constraints, and criteria. In particular, the threats or challenges to the system (either competitors or adversaries) needs to be understood and evaluated with respect to the requirements. In the space in which adversary activities must be considered (commercial, cyber, or defense), the importance of characterizing these is important from both a risk perspective and a requirement (to withstand the threats) perspective.

One of the advantages of performing an early risk analysis during the system’s conception stage is to have the oportunity to mitigate the identified risks by promoting changes in the set of requirements. This is an example of a good interaction between the requirement definition processes and the risk management process.

many steps of the well known V-Model are mixed here. Step1: item definition /system definition step2: Hazard analysis and risk assessment: description of typical driving/operating scenarios and specification of the severity (S), exposure (E), controllability (C) acc. to ISO 26262 (S, F, P acc. to ICE61508). Allocation of the SIL level based on S, E, C over risk graph. step3: Calculation of FTTI and safe state The results of HARA are the safety requirements at system/vehicle level. Safety requirement has four attributes: Definition, SIL/ASIL value, FTTI and safe state. _________________________________________________ -Technical requirements (TSR) from system safety requirement and system architecture -HW/SW requirements from TSR -----

Além de todos os comentários pertinentes, já feitos aqui neste artigo, a classificação dos riscos deve ser feita respeitando sua natureza e usando ferramentas aderentes à mesma natureza.

The most important risk, which in fact is present for any system, is defining a requirement without being able to unequivocally understand its content.If this risk is understood then the requirements can be of higher quality. When starting the requirement definition, each requirement shall be dicomposed into its simplest form and complying with a SMART (Specific, Measurable, Achievable, Realistic and Timely) definition. This will allow to produce better requirements, to reduce the risks derived from an incorrect definition and to perform a deeper risk analysis in a more simple and accurate manner.

The identified risks can be related to any system’s life cycle stage (e.g. production, utilization, retirement) or any system’s life cycle process (e.g. integration, verification, maintenance). Since the execution of these processes are conditioned by what was written as requirements, improving these requirements as a response to the identified risks is one of the easiest, cheapest and most effective ways to deal with them as long as it is done early during the system’s life cycle.

Spot risks, strengthen requirements: Uncover blind spots: Analyze potential threats (tech, budget, user) to avoid costly surprises. Prioritize wisely: Use risk matrices to rank critical requirements that mitigate high-impact issues. Refine & robustify: Adapt or add requirements based on risk analysis, building resilience. Validate assumptions: Challenge and test requirements against identified risks for greater accuracy. Plan for contingencies: Incorporate mitigation strategies into requirements to handle inevitable challenges.

Where risk controls are identified in the risk management process, these controls must be carried through into requirements. The risk controls are of no use if they are not verified as both implemented, and critically, effective.

In systems engineering, consider: How does risk analysis improve system requirements? By identifying potential issues early, risk analysis allows for the design of requirements that are more resilient and adaptable. It encourages a deeper understanding of what could go wrong, leading to requirements that proactively address these challenges. This results in a system that's not only better equipped to handle uncertainties but also more efficient and reliable in achieving its goals.

Risk analysis for system requirements is a proactive and strategic practice that contributes to project success by enhancing planning, decision-making, resource management, and overall project resilience. The benefits extend across the entire project lifecycle, from initial planning to implementation and beyond.

It will help to prevent shortages in technical performance, late design changes, cost overruns, schedule delays and cancellation. This analysis must consider the full system life-cycle, including integration, verification, validation, transition, operation, maintenance, and disposal.

If applied in an iterative way, the risk analysis will ensure that the requirements are defined and apportioned in an optimal manner which eventually will lead to the best possible design, implementation, validation, operation and disposal of a system. Most of the systematic failures that can “find their way” into a system are due to inadequate formulated or improperly elicited requirements and the “cure” for these failures is a good solid iterative risk analysis.

It's like a safety net. By foreseeing potential issues, risk analysis helps tailor requirements to be more robust, avoiding future setbacks. It aids in prioritizing resources effectively, ensuring the system's resilience and adaptability. This foresight not only saves time and cost but also enhances the overall quality and reliability of the system. It's a crucial step in crafting a successful, sustainable system.

Risk Analysis for system requirements is complex and time consuming, but its major benefit is identifying risks at an early stage of the project and coming up with a plan and steps to mitigate those risks. In addition, going through the process of Risk Analysis in such an early stage it can help the project's team to clarify the requirements and have a better understanding of what they need to implement in order to meet those requirements.

An effective way to integrate risk analysis with requirements management is to use the risk level (the combination of likelyhood and impact) as one the requirements’ attributes. On the other way around, the risk register should indicate the requirements that are affected by each risk and also exhibit the changes/additions/exclusions of requirements that have to be implemented as risk responses.

Systems requirements are usually defined in an earlier phase of the system life-cycle. This means that there is few knowledge available and much uncertainty. In this case it can be hard to perform a detailed risk analysis. To help to overcome this challenge it is important to perform simultaneous (concurrent) engineering, involve experts from different areas, consider the different phases, use lessons learned from previous projects, benchmarking, invest on early simulations, prototyping, and testing.

A pre-mortem is a very effective way of managing project risks, and in opposite to the post-mortem when it is analyzed failures that already happened, in a pre-mortem it is possible to circunvent those failures. In a typical pre-mortem is assumed the project has failed and every team member build reasons why it failed . Also imagining an event has ocurred helps to identify reasons for future outcomes. Another reason is that people could not feel comfortable to speak up about issues in a project kick-off. Pre-mortem also reduces the intent of go ahead no matter what that could happen by someone who over invested in the project. It is a good way to pick-up early signs of trouble in a project.

O maior desafio não é encontrar o melhor método, a melhor ferramenta, a melhor forma de registrar, comunicar e gerir os riscos. O maior desafio é mudar a cultura organizacional para aprender e aceitar essa atividade. Gestores de projetos ditos " de primeira linha" se quer sabe como identificar os riscos. Infelizmente a cultura organizacional muda quando a negligência de gerir riscos adequadamente faz vítimas fatais

It's a bit like forecasting weather; uncertainties are always present. Also, balancing comprehensiveness with efficiency is tricky. You don't want to overlook potential risks, but you also can't get bogged down in analysis paralysis. Plus, integrating risk analysis findings into system requirements demands skillful communication and collaboration across teams. Navigating these challenges is key to harnessing the full benefits of risk analysis.