Your team is already
doing this work.

Most teams don't sit down one day and design a clean, structured process from scratch. It sort of… grows. Same thing goes for the analysis, or audit, of that system. A spreadsheet appears because it's quick. Then a document to explain a few things. Then maybe a diagram in powerpoint. Some decisions get written down, others don't, but everyone more or less knows what's going on, so it feels fine. And for a while, it is fine. The problems show up later, usually when something changes, or needs to change. Someone doesn't follow the procedure exactly. Or tries to make it faster to increase profits. Or asks whether a step is still necessary. And now you need to answer a simple question: is this still safe, or did we just break something without realizing it? Will that backfire?

That's where things get uncomfortable, because your understanding of the entire system is scattered and may not match the actual reality anymore. You have pieces, but not something you can rely on without spending time you don't have auditing your system. There are formal methods that have been developed by world-class researchers to prevent this kind of drift. STPA is one of them, and it's used in places where people don't get to guess. But knowing the method exists and actually being able to apply it without creating overhead are two different problems.

What actually matters when things go wrong.

So the first step is to be explicit about what actually matters if things go wrong. We're talking real adverse impact. Revenue is lost, sometimes permanently. People get hurt. Equipment is damaged or destroyed. A mission fails. A system becomes unusable.

These are the outcomes you are trying to avoid. Everything else is a means to that end. This sounds obvious, but in practice it often stays vague or implicit. Different people have slightly different interpretations of what “bad” means, and those differences don't show up until much later.

What has to be true for things to go wrong.

Once you know what you're trying to avoid, the next question becomes a bit more interesting: what has to be true for those outcomes to even become possible?

This is where things tend to get fuzzy, because these situations don't usually look dramatic. They're small inconsistencies, gaps, or assumptions that quietly stick around. Information that is incomplete but still used as if it were sufficient. Parts of the system that no longer match reality, but haven't been updated. Decisions that depend on things nobody has actually checked in a while.

None of these feel urgent on their own, which is exactly why they survive. But once they accumulate, they create a system where failure is no longer surprising, just hard to trace back and correct in time.

Where you draw the line.

At some point, describing how things can go wrong isn't enough. You need to be clear about what must always be true so that those situations don't exist in the first place. But this is where a lot of analyses stay too vague. Statements like “the system should be reliable” or “the process should be robust” sound reasonable, but they don't actually constrain anything in a way that can be checked or enforced.

What matters are constraints you can point to directly. The system reflects the current state of the design, not an outdated version. Missing information is not treated as valid input. Conflicting inputs are resolved before decisions are made.

When these are explicit, reviews become straightforward because you're checking something concrete. When they're not, you end up having discussions instead. And discussions are where time disappear, and where different interpretations creep in, which is exactly what you want to avoid.

How the system actually behaves.

Up to this point, everything is still fairly abstract. You know what you're trying to avoid, and under what conditions things start to drift, but you haven't really described how the system operates. That's what the control structure is for.

In practice, every system works the same way at a high level. Something makes decisions. Something else executes them. Information flows back, and the next decision depends on it. The problem is that this is rarely written down clearly.

What really controls what.

controller, controlled process, control action, feedback

Responsibilities are assumed. Feedback paths exist but aren't explicit. Some actions depend on information that is delayed, incomplete, or interpreted differently depending on who looks at it.

When you lay this out properly, you start seeing things that were invisible before. Decisions made without the right information. Feedback that arrives too late to matter. Parts of the system that operate on different versions of reality. This is usually the moment where the analysis stops being theoretical and starts reflecting how the system actually behaves.

Where control goes wrong.

Once the control structure is clear, you can start looking at where things go wrong in a more precise way, in terms of specific actions that shouldn't happen, or should happen but don't.

A decision is not made when it should be. A decision is made when it shouldn't be. A decision is made too early, too late, or in the wrong order. A decision is applied incorrectly.

These are not rare edge cases. They are the basic ways control breaks down, and thus, your system breaks down.

“Failure is a path, not an event.

Identifying unsafe actions is useful, but it still leaves an open question: how does this actually happen?

This is where most actual analyses either become very superficial or very complicated, depending on how people approach it. And in both cases, strategic decisions to change the processes can be muddy and unstable and hard to trace back to a specific reason.

When you look at the possible paths leading to an erroneous control action, and lay them out clearly, you start seeing patterns. Not just isolated issues, but recurring ways the system can drift into unsafe territory. This is also where context matters… The same system can behave very differently under real life: time pressure, degraded conditions, or unusual configurations.

Where you take control back.

At this point, you have enough understanding to do something useful with it. Requirements are not just statements about what the system should do. They are responses to the specific ways the system can fail.

If a control action can be made without the right information, the system must ensure that information is available or the action is blocked for clarification. If feedback arrives too late, the system must detect that and handle it differently. If assumptions can drift over time, the system must either validate them or stop relying on them.

Good requirements are tied to real scenarios. You can trace them back and explain exactly why they exist. They allow you to develop the most efficient mitigations strategies, validate their effect, and implement the change in your process.

We tell you how well you know your system.

At some point, you need to stop asking “did we fill everything in?” and start asking “if this view of our system strength is wrong, would we catch it?”

The grade is not about how well the process was followed. It reflects the strength of the analysis itself. Are hazards actually connected to losses, or just listed? Do unsafe actions lead to real scenarios, or stop halfway? Are requirements tied to specific failure paths, or written in isolation?

It makes gaps visible early, when they are still easy to fix, instead of during a review where everything becomes slower and more defensive.

This is what RequiSense Studio gives your team, and more. Much more.