3SE engineer complexity through questions. Every 3SE role is built on a simple principle: don't answer for the engineer — ask the question a seasoned practitioner would ask, and let the 3SE method capture what emerges.
Think harder, engineer better.
Socrates called it maieutics — the art of midwifery applied to ideas: the belief that truth is not poured into the learner but drawn out of them through disciplined questioning.
Every 3SE role is built on a simple principle. It does not hand a role a finished goal, requirement, or hazard — it asks the question a seasoned practitioner would ask, and only checks the answer against the 3SE ontology.
Four question patterns recur across every 3SE role:
Elicitation — "What concept is this, really?" Surfaces the 3SE concept behind an answer, instead of accepting the first formulation at face value.
Falsification — "What evidence would prove this wrong?" Turns an answer into something evaluable before it is ever baselined as a 3SE fact.
Contradiction — "Does this conflict with something you already baselined?" Surfaces silent inconsistencies between answers before they compound.
Allocation — "Who — or what — actually owns this?" Forces a single accountable element for every answer instead of leaving it implicit.
The 3SE tetrahedron has four domains — Business, Engineering, Asset, Project — and six edges, each one a trade-off between two of them.
Eight 3SE roles sit across those six edges — most alone on their edge, two edges shared by a pair of roles whose analyses mirror each other from opposite sides of the same trade-off.
| Edge | Trade-off | Role(s) | Analysis | Maieutic question |
|---|---|---|---|---|
| 1 | Business ↔ Project | Business Owner | Goal & value analysis | "If we shipped nothing, what would it cost the business — and who would feel it first?" |
| 2 | Business ↔ Asset | Product Owner · Service Owner | Feature, product/service & release analysis | "If this feature disappeared tomorrow, which product or service would stakeholders miss — and why?" |
| 3 | Business ↔ Engineering | System Engineer | Stakeholder requirement & operational analysis | "Walk me through the worst day this system will have — what is it doing at that moment?" |
| 4 | Engineering ↔ Asset | System Architect | Functional & physical architecture | "If two functions both claim this behavior, which element really owns it?" |
| 5 | Engineering ↔ Project | System Validation Engineer · System Quality Engineer | System validation & verification analysis | "If we verified this against the rules but never validated it against the requirements, what would we miss?" |
| 6 | Asset ↔ Project | System Risk Engineer | Risk analysis | "If this failed silently, how late would you find out — and what happens in the meantime?" |
Validation checks the system against its requirements — did we build what was asked? Verification checks it against the method's own rules — quality criteria, conventions, structural consistency. Both close the loop at delivery.
The dialogue only works because every answer lands somewhere well-defined. Five analyses carry it from a stakeholder's value all the way to a release — the same backbone agile teams have always worked from, now made explicit, traceable, and shared across every 3SE role.
- Value analysis — What value the goal delivers to the stakeholder
- Goal analysis — Decompose the goal, or allocate it to a feature
- Feature analysis — What feature actually contributes to that goal
- Product & service analysis — What product or service realizes that feature
- Release analysis — What release actually delivers it to stakeholders
Each analysis only ever formalizes what the dialogue already surfaced — the chain never replaces a question with a guess.
© 2022 3SE — System, Safety & Security Engineering · www.3se.info
