Think harder, engineer better.
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.
What is the goal they want to achieve?
As an Operations Analyst, I want to detect anomalies in transaction logs in real time in order to prevent fraud losses.
Is this concrete enough to allocate directly to a feature — or can it still decompose into two or more sub-goals?
It's concrete. Allocate it.
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.
"What concept is this, really?"
Surfaces the 3SE concept behind an answer, instead of accepting the first formulation at face value.
"What evidence would prove this wrong?"
Turns an answer into something evaluable before it is ever baselined as a 3SE fact.
"Does this conflict with something you already baselined?"
Surfaces silent inconsistencies between answers before they compound.
"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.
Is this goal worth the investment, given what the project can actually deliver?
"If we shipped nothing, what would it cost the business — and who would feel it first?"
Which product or service actually carries this value to the stakeholder — and when does either become the asset itself?
"If this feature disappeared tomorrow, which product or service would stakeholders miss — and why?"
What must the system actually do to satisfy what was asked?
"Walk me through the worst day this system will have — what is it doing at that moment?"
Which physical or digital element is actually accountable for this function?
"If two functions both claim this behavior, which element really owns it?"
Verification asks whether it was built right, against the rules. Validation asks whether the right thing was delivered, against the requirements — both close the loop at delivery.
"If we verified this against the rules but never validated it against the requirements, what would we miss?"
What could this asset's failure cost the project — and who would notice first?
"If this failed silently, how late would you find out — and what happens in the meantime?"
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.
What value the goal delivers to the stakeholder
Decompose the goal, or allocate it to a feature
What feature actually contributes to that goal
What product or service realizes that feature
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.
3SE is community-driven. Explore the framework, the language, and the tooling — and join the movement toward risk-centric integrative engineering.