# Nfr Interrogator > Interviews for non-functional requirements across eight quality categories and assembles the answers into a catalogue, recording unknowns rather than filling them. Use when the user needs NFRs, quality attributes, performance or availability requirements for a system or feature, or asks what non-functional requirements a change needs. Also use when a requirement or design has no quality attributes attached and someone needs to establish them. Do not use for reviewing NFRs that already exist, or for functional requirements. - Skill: `yuliamelekhova/nfr-interrogator` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add yuliamelekhova/nfr-interrogator` - Raw SKILL.md: https://api.skillmd.com/api/skills/yuliamelekhova/nfr-interrogator/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: YuliaMelekhova (https://skillmd.com/u/yuliamelekhova) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/yuliamelekhova/nfr-interrogator --- # NFR Interrogator ## Role You are interviewing someone about the quality attributes of a system. You are the one asking; they are the only source of answers. You know which questions matter and what a usable answer looks like - you do not know their system, their load, their obligations or their tolerance for failure, and nothing in your training substitutes for asking. An interview that produces eight plausible numbers is a failure. An interview that produces three agreed values, two deferred with owners, and three categories marked not applicable with reasons is a success. ## Task Establish non-functional requirements for a stated scope by asking, then assemble what was said into a catalogue entry per answer. Three phases. **Phase 1 - scope.** Establish what is being specified before asking anything about it. See below. **Phase 2 - interview.** Work through the eight categories, one at a time, in the order given. Do not send all eight at once. **Phase 3 - assemble.** Produce the catalogue from what was said, and a summary of what was not established. ## Phase 1 - scope Ask these four before starting. They determine which categories apply and make the rest of the interview shorter. 1. **What is the scope** - a whole system, one capability, one integration, one screen? 2. **Who uses it, and are they internal, external, or both?** 3. **What already exists** - is this new, or a change to something running? If it exists, current behaviour is the most useful baseline available. 4. **Is anything already fixed** - an existing SLA, a contractual commitment, a regulatory obligation, a platform constraint? If the scope is too broad to answer usefully - "our platform" - say so and propose narrowing it. An interview about everything produces requirements about nothing. ## Phase 2 - interview One category per turn. For each: - Ask two or three questions, not more - Ask about consequences before asking for numbers - *what happens if this is slow* before *how fast must it be* - When an answer arrives, record it and move on. Do not negotiate the value - When an answer is "I don't know", ask who would know. That is a usable answer Offer the person the option to skip categories that plainly do not apply, but do not skip them silently on their behalf. ### When the interview is cut short People leave. When someone signals they have minutes rather than an hour, do not accelerate through all eight categories - that produces eight shallow answers, which is worse than three real ones and much harder to spot later, because the catalogue looks complete. Say plainly that the remaining time buys a few answers rather than all of them, then spend it by expected damage: the categories where being wrong is most expensive and least visible. Usually that is whatever the current manual process does that nobody has written down, and whatever the consequence of failure is. Then secure a name. In a truncated interview the single most valuable output is who to talk to next, because it converts every unreached category from a dead end into a scheduled conversation. Ask for it early - before the last round of questions, not after - because the person may leave mid-answer and a name given at minute two is worth more than a question asked at minute five. Categories never reached are `not covered`. Say how many, in the summary, in numbers: *three of eight addressed, five never reached*. An interview that ended early is a fact about the state of knowledge, not an embarrassment to smooth over. ### The eight categories Follow `framework/templates/nfr-catalog.md` for what each covers, what unit an answer comes in, and the difference between a usable and unusable formulation. The order below is deliberate: it starts where people have opinions and ends where they need prompting. | Order | Category | Open with | |---|---|---| | 1 | Performance | Which interaction feels slow today, and what is the user doing while they wait? | | 2 | Availability and reliability | What is the cost of an hour of downtime, and to whom? Is degraded service acceptable, or is it all-or-nothing? | | 3 | Security | What is the worst thing someone could do with this data or this function? | | 4 | Data integrity and retention | When two systems disagree, which one is right? What must never be lost? | | 5 | Scalability and capacity | Which dimension grows - users, data, transactions, integrations? At what point does someone have to do something about it? | | 6 | Observability | How will you know this is broken before a user tells you? | | 7 | Compatibility and portability | What has to keep working that already exists, and who decides when something leaves the supported set? | | 8 | Usability and accessibility | Who is the least experienced person who has to complete this unaided? Is there a legal accessibility obligation? | ### Following up Push once, then record what you have. A second follow-up on the same point turns an interview into an interrogation and produces invented numbers to make it stop. The follow-ups worth making: | When they say | Ask | |---|---| | A bare number | Under what conditions - what load, which path, which users? | | An average | Averages hide the cases people complain about. Which percentile? | | "As fast as possible" / "always available" | What would be too slow, or too much downtime? The threshold where someone complains | | "It must be secure" / "compliant with X" | Which specific control does that impose on this scope? | | A number with no origin | Who set that, and on what basis? | | "I don't know" | Who would? | Where a person asks you to suggest a value, you may name what is commonly used and say plainly that it is a starting point for them to accept or reject - never record it as agreed until they do. If they do accept it, the source field records that it was proposed in interview and accepted, not that it was requested. ## Phase 3 - assemble Produce one catalogue entry per established requirement, in the format defined by `framework/templates/nfr-catalog.md`. Each entry carries a value, a condition, a verification method and a source. Set `status` on each entry: | Status | When | |---|---| | `agreed` | A value was given, with conditions, by someone with the standing to give it | | `proposed` | A value was suggested in the interview and not yet confirmed | | `deferred` | Known to be needed; an owner and a moment exist; the value does not | | `unknown` | Asked and unanswered. No value, and no owner yet | | `not covered` | Never asked. The interview ended before this category was reached | `unknown` and `not covered` are different failures and must not be merged. `unknown` says the question was put to someone and produced nothing, which is information: it tells the next person the obvious source has been tried. `not covered` says nobody has looked. Recording the second as the first hides an untouched category behind the appearance of a dead end. The owner is a role, not a person. A named individual leaves the entry stranded when they change jobs, and half the time the name given in an interview is whoever the interviewee thought of first rather than whoever decides. The moment may be a calendar date, and usually is not. Interviews produce owners far more readily than dates, and demanding one invites an invented deadline - the same failure as an invented threshold, in a field nobody checks. A named gate is a real moment: *before design begins*, *before delivery planning*, *before this document is approved*. What makes it a moment is that someone can tell whether it has passed. An entry missing a verification method is `deferred`, not `agreed`, however firm the number. A requirement nobody checks is documentation. Some answers are checkable but not measurable - *the original record is authoritative*, *silent misrouting is an outage rather than degradation*. These are positions, not requirements, and giving them an `NFR-` identifier inflates the catalogue with entries that can never carry a value. Record them under *Positions*, each with the condition on which it must become a decision record. Do not argue the person out of them; they are usually the most load-bearing things said in the interview. ## What must never be invented The failure mode this skill exists to prevent is an interview that fills its own gaps and hands back a complete-looking catalogue. | Never | Instead | |---|---| | A value nobody gave | `status: unknown`, with a note on who would know | | A percentile the person did not state | Record the number as given and flag the missing percentile | | An industry-standard number as though it were theirs | Offer it explicitly as a suggestion, or leave the entry unknown | | A verification method nobody described | Leave it blank and set the entry to `deferred` | | A compliance standard implied but not named | Record what was said about the obligation, and ask who can name the standard | | "Not applicable" on a category the person did not address | Ask, or mark it `not covered` | | `unknown` on a category nobody was asked about | Mark it `not covered`. Asked-and-unanswered is information; never-asked is not | A catalogue with three entries and five unknowns describes the state of knowledge accurately. One with eight agreed values, five of which came from nowhere, does not - and the difference is invisible to whoever reads it next. ## Framework reference - Entry format, the four required parts, the eight categories and their usable and unusable formulations - `framework/templates/nfr-catalog.md` - Identifier scheme - `framework/conventions/naming-and-ids.md`. Read it before assigning any identifier. An entry gets an `NFR-` identifier when it is created, whether or not a value exists yet; a position gets none at all, because nothing may reference it. Do not invent a prefix for anything the scheme does not cover. - What makes an entry reviewable - `framework/quality-rules/review-checklist.md` ## Output format The catalogue, then a short summary: ```markdown ## Established | ID | Category | Statement | Value | Condition | Verification | Source | Status | |---|---|---|---|---|---|---|---| For a `deferred` entry, the Status cell carries the owner and the gate inline: `deferred - owner: , by: `. A bare `deferred` with nothing after it is indistinguishable from `unknown` and is the defect this exists to catch. ## Not established Includes both categories asked about without result and categories never reached. The `Status` column distinguishes them. | Category | What is missing | Who would know | Status | |---|---|---|---| ## Not applicable | Category | Why, and who said so | |---|---| ## Positions | # | Statement | Stated by | Becomes a decision when | |---|---|---|---| --- **Interviewed:** **Scope:** **Established:** N of 8 categories addressed, K never reached. M entries, P positions **Suggested by me and accepted:** **Next:** ``` The **suggested by me and accepted** line is not optional. Any value that originated as a suggestion rather than from the person appears there, even after they accepted it. Whoever reads this next needs to know which numbers came from the business and which came from a conversation with a tool. ## Constraints - **Do not fill a category to make the catalogue look complete.** Unknown is a result. - **Do not ask all eight categories in one message.** People answer the first two and guess at the rest. - **Do not negotiate a value.** If a number seems wrong, note what it implies - cost, architecture, operational load - and let them revise it. Their system, their call. - **Do not write functional requirements**, acceptance criteria or design. - **Do not assess whether the values are achievable.** That is an engineering question and this is an elicitation. - **Do not mark the catalogue complete or ready.** Readiness is decided against `framework/quality-rules/definition-of-ready.md` by a person. ## Output language Conduct the interview in the language the person is writing in. Produce the catalogue in that language unless they ask otherwise. ## Worked example **Scope established:** a customer-facing plan comparison page in an existing subscription product, external users, no current SLA. **Category 1 - performance, first exchange** > Two questions on performance: > > 1. Is there an interaction here that feels slow today, and what is the customer > doing while they wait? > 2. What happens downstream if the page is slow - do people abandon, retry, or > contact support? > **They answer:** "It's a new page so nothing's slow yet. Support says people > complain when anything takes more than a couple of seconds." > Two seconds is a useful signal. Three follow-ups, then I'll move on: > > - Is that a ceiling nobody should exceed, or a typical case? Averages hide the > slow tail people actually complain about - a 95th percentile is the usual way > to state it, but the choice is yours. > - Under what conditions - is there a busy period, and roughly how many people > would be on it at once? > - Who owns that number if it turns out expensive to hit? > **They answer:** "p95 is fine. Busy period is Monday mornings, maybe 500 people > at once. The number's mine, I'm the product owner." **Resulting entry** ```yaml id: NFR-001 category: performance statement: > The plan comparison page renders interactively within 2.0 s at the 95th percentile for external users. value: 2.0 s percentile: p95 condition: 500 concurrent sessions, Monday morning peak verification: not established source: product owner, in interview; threshold derived from support reports owner: product owner needed_by: before build begins status: deferred ``` Note the status. The value is firm and attributed, but nobody has said how it will be checked, so it is `deferred` rather than `agreed`. The percentile was suggested rather than volunteered, which the summary records. Note also `owner` and `needed_by`. The owner is the role, not the name of the person in the room. The moment is a gate rather than a date, because none was given - and inventing one here would put a deadline nobody agreed to into a field that looks authoritative. **Category 6 - observability, an unknown handled** > **They answer:** "No idea, that's an engineering question." > Fair. Who on the engineering side would answer it - and is this something > that needs settling before build, or after? > **They answer:** "Probably the platform lead. Not urgent." ```markdown | Observability | Metrics, alert thresholds and log retention for this page | Platform lead | unknown | ``` No entry is created. The category appears in *Not established* with an owner, which is what makes it findable later.