Is Trike-style requirements modeling worth adopting when no written access rules exist?
answer
- price the elicitation, not the analysis
- you are authoring, not just analysing
- the rule table is the real deliverable
- scope to authorization-dense parts only
- no business owner means no adoption
basics
~20 sUsually yes, but narrowly. The cost is not the analysis; it is authoring the authorization rules the organisation never wrote — and that written rule set, not the threat list, is the main payoff. Scope it to the authorization-dense core.
solid answer
~50 sBe honest about where the cost sits. Deriving threats from a filled grid is quick; getting the grid filled means someone must decide, on the record, who may do what — work the organisation has been deferring, often for years. Take a municipal library's fine-waiver workflow where the only written rule is that a supervisor may waive above fifty dollars. Grid create, read, update and delete over waiver records and you find nobody ever said who may delete a waiver, or who may read the waiver history. Those answers are worth more than the threat list: they become authorization tests, access-review inputs and onboarding documentation. So scope it to the authorization-dense core — money movement, per-role visibility — timebox the elicitation, keep the rule table beside the code and tests, and give it a product owner. Rolling a full matrix over every asset in the system is where this method dies.
go deeper
Understand that filling the grid requires someone to decide the access rules, and that those decisions come from the business, not from whoever is drawing the table.
Be able to explain why the grid grows as actors times assets times four, and give an example of a surface where the effort clearly does not pay, such as a single-actor public page.
Show how you would scope and land it: pick the authorization-dense areas, timebox the elicitation, record unresolved cells as owned open decisions, and keep the rule table beside the code and tests.
Own the adoption call end to end — what the organisation is really buying, who owns the artifact after you, when to decline, and how you justify the elicitation cost to a business that has deferred these decisions for years.
## Reframe the cost question The instinct is to price a methodology by how long the analysis takes. For requirements-driven modeling that is the wrong line item. Turning a filled matrix into a threat list is close to mechanical. The expensive, slow, politically awkward part is **filling it** — because filling it means someone with authority must state, in writing, which actors may take which actions on which assets. In most organisations that authorization specification has never existed. The method is not asking you to analyse; it is asking you to author. That reframing decides the adoption question, because it changes what you are buying. ## What you actually get A municipal library's fine-waiver workflow makes it concrete. The one written rule is that a supervisor may waive a fine above fifty dollars. Grid create, read, update and delete against waiver records and the gaps arrive within the hour: - Nobody stated who may **delete** a waiver record — which means the audit trail for money forgiven has no stated owner. - Nobody stated who may **read** the waiver history, so a desk clerk browsing a patron's financial history is neither permitted nor forbidden. - The fifty-dollar rule turns out to be an *allowed with rules* cell whose condition — is it per waiver, per patron, per day? — nobody has decided. The threat list from those cells is worth having. But the durable deliverable is the **rule table itself**. It converts directly into authorization tests, it is the input an access review has always lacked, it answers the question a new engineer asks in week one, and it is the artifact an auditor wants when they ask how waivers are controlled. Judging the exercise purely on threat count undersells it badly. ## Where it stops paying The cost of the grid scales as actors times assets times four, and the marginal yield falls fast. Two things go wrong at scale: 1. **Uniform assets.** Where a whole class of records shares one access rule, filling per-asset cells produces near-identical rows and no new information. Model the class once. 2. **Low-authorization surfaces.** A public catalogue search page has essentially one actor and one action. The grid tells you nothing you did not already know, and the effort is better spent on a design-level pass over its infrastructure. There is also an organisational cost worth stating plainly: this method has far less adoption, tooling and shared vocabulary behind it than the mainstream category-driven approaches. You will be maintaining the artifact and teaching the notation yourself, and if the person who championed it leaves, the grid rots. That is a real argument for keeping the scope small enough that the artifact stays cheap to maintain. ## How I would actually adopt it - **Scope to the authorization-dense core.** Money movement, records with per-role visibility, anything with an insider-abuse story. Waivers yes; the catalogue search no. - **Timebox the elicitation** and treat unresolved cells as open decisions with an owner and a date, not as blockers. An eighty-percent grid with five named open questions beats a perfect grid that never ships. - **Give it a business owner.** The person who can decide who may delete a waiver is not the engineer. If nobody will own the rules, that is itself the finding, and it should be escalated as one. - **Store it next to the code and tests**, in version control, with the authorization tests referencing it. A rule table in a document repository is stale within two quarters. - **Wire it to a trigger.** Re-open the grid when a new actor appears — a new integration, a new support tier, a new automated job — rather than on a calendar. ## When to say no Decline when the system has one actor and no meaningful authorization surface; when the business genuinely will not staff the decisions, so you would produce a grid full of guesses that later gets cited as authoritative; or when the pressing risks are infrastructural rather than permission-shaped, where a rule table adds no coverage. ## What an interviewer is listening for They want to hear you price the elicitation rather than the analysis, name a deliverable beyond the threat list, scope the method instead of adopting it wholesale, and say who owns the artifact after you move on. "We will threat-model everything with a matrix" is the answer that fails; a narrow, owned, version-controlled rule table over the parts of the system where authorization is actually hard is the answer that lands.
- What deliverable would you defend to a product owner who does not care about threat lists?The written authorization rules. Frame it as the answer to questions they already get asked: who may delete a waiver, may a clerk see a patron's financial history, does the fifty-dollar limit apply per waiver or per day. It becomes the basis for access reviews, for authorization tests, and for what support staff are told they may do. The threat list is the by-product.
- How do you stop the matrix from rotting?Keep it in version control beside the code, have the authorization tests reference the cells so a rule change breaks a test, and give it a named business owner. Then trigger a revisit on events rather than dates: a new actor appears, a new integration lands, a support tier is added. A rule table that only a quarterly reminder touches is already out of date when you open it.
- When would you decline to use it at all?When the surface has essentially one actor and one action, when the dominant risks are infrastructural rather than permission-shaped, or when no one in the business will actually decide the rules. That last case matters most: a grid filled with engineering guesses gets cited later as if it were policy, which is worse than having no grid and an honest gap.
It is like being asked to inventory a warehouse that has never had a stock list: the counting is easy, and the lasting value is the list you now have, not the discrepancies you found this once.
saying these in an interview costs you the question
- Proposes a full matrix over every asset in the system
- Prices the method by analysis time and ignores elicitation cost
- Presents the grid as a one-off document with no named owner
- Judges the exercise only by how many threats it produced
- Assumes the business will write the access rules unprompted