Requirements Engineering II: Specifying and Managing

What makes a requirement good?

The international standard for requirements (ISO/IEC/IEEE 29148) lists characteristics of a good individual requirement:

Ambiguity: the most common defect

Natural language is ambiguous. Watch for:

• Weak words: fast, easy, user-friendly, appropriate, adequate, flexible, efficient, as much as possible, support, etc., and/or, normally, if possible.
• Vague quantities: "many users", "large files", "recent posts".
• Hidden actors (passive voice): "The post shall be deleted." — by whom? the author, a TA, the system after 30 days?
• Pronouns: "When the TA answers the student, he gets a notification." — who is he?
• Undefined terms: "course" (subject or section?), "active user" (logged in today? this semester?). Keep a glossary.
• Mixed modal verbs: many specifications use shall for mandatory requirements, should for desirable ones, may for optional ones. Mixing them randomly makes priority unclear.

EARS: five templates that remove most ambiguity

The Easy Approach to Requirements Syntax (EARS) was developed at Rolls-Royce (Alistair Mavin and colleagues, 2009) for jet-engine control software. It uses a few fixed sentence patterns:

Patterns can be combined: "While exam mode is active, when a student asks Buddy about a tagged graded exercise, the system shall give hints only." The fixed structure forces the writer to state the trigger, the state and the response — the three things most often forgotten.

Quality requirements need a metric, a target and a condition

A non-functional requirement becomes verifiable when it states what is measured, the required level, and under which conditions (Tom Gilb's "Planguage" calls these scale, meter and target):

Where requirements live: SRS documents and backlogs

A Software Requirements Specification (SRS) is a structured document. A typical outline (based on IEEE 830 / ISO 29148):

1. Introduction — purpose, scope, definitions (glossary), references.
2. Overall description — product perspective, user classes, operating environment, constraints, assumptions and dependencies.
3. Specific requirements — functional requirements (often grouped by feature), external interfaces, quality requirements, data requirements.
4. Appendices — models, analysis, traceability.

Plan-driven projects (Chapter 2) use an SRS as a contract and a baseline for testing. Agile teams keep most requirements as stories with acceptance criteria in the Product Backlog, plus a small set of stable documents: the glossary, the quality requirements, the constraints, and the policies (for StudyBuddy: privacy, academic integrity). Both approaches need the same qualities — only the container differs.

Prioritization: you cannot build everything

MoSCoW sorts requirements for a given release:

• Must have — without it the release is useless, illegal or unsafe. (Login with WKU account; privacy rules.)
• Should have — important, but the release still works without it. (Search.)
• Could have — nice if time allows. (Emoji reactions.)
• Won't have (this time) — agreed to be out of scope for now. (Video calls.)

A common rule of thumb: Musts should use no more than about 60% of the available effort, so there is room for surprises. The "Won't" list is valuable: it records decisions and prevents the same discussion every week.

Another simple technique is the value/effort grid: high value + low effort = quick wins (do first); high value + high effort = big bets (plan carefully); low value + low effort = fill-ins; low value + high effort = avoid.

Traceability: follow every requirement from source to test

Traceability links each requirement backward to its source (who asked, which law or document) and forward to design, code and tests. A traceability matrix is the simplest form:

Traceability answers three practical questions:

1. Coverage: which requirements have no test? (R3 above — a serious gap.)
2. Orphans: which tests or code belong to no requirement? (Possibly unnecessary work — or a missing requirement.)
3. Impact analysis: if R2 changes from 3 reports to 5, which design parts, code and tests must change?

Safety standards (for medical, automotive and aviation software) require full traceability; for StudyBuddy a light version — IDs in stories, test names that mention the requirement ID — is enough.

Managing change

Requirements will change. Change is not the problem; uncontrolled change is:

• Baseline: an agreed, versioned set of requirements (e.g., "Release 1 scope, 30 Sep").
• Change request: any change to the baseline is written down: what, why, who asks.
• Impact analysis: use traceability to estimate the effect on design, code, tests, schedule, cost, security and privacy.
• Decision: the Product Owner (or a change board in plan-driven projects) accepts, rejects or postpones it — often trading it against something else of similar size.

Scope creep is the slow growth of scope through small, unrecorded additions ("just one more small thing"). Each one looks cheap; together they make the project late.

Validating requirements

Validation checks that the written requirements describe what stakeholders really need — before anything is built:

• Reviews and inspections: stakeholders and developers read the requirements with a checklist (the qualities table above). Cheap and very effective.
• Prototypes: show a mock-up and watch users try it — the fastest way to find the "yes, but…".
• Writing acceptance tests early: if a tester cannot write a test for a requirement, the requirement is not verifiable. Writing tests before coding exposes ambiguity.
• Walkthroughs of scenarios: step through "a day in the life" of a persona and check that every step is supported.

Requirements for AI features: accuracy is a requirement

AI components are probabilistic: they will sometimes be wrong. Their requirements must say how often wrong is acceptable, which kind of wrong is worse, and what happens then.

Take a component that decides whether a student's question is about a graded exercise (so Buddy must only give hints). Compare its decisions with the truth on a test set:

• Precision = TP ÷ (TP + FP): of the questions flagged as graded, how many really were?
• Recall = TP ÷ (TP + FN): of the really graded questions, how many did we catch?
• F1 = 2 × precision × recall ÷ (precision + recall): one number balancing both.
• Accuracy = (TP + TN) ÷ total — misleading when one class is rare.

Which error is worse? A false negative here means Buddy gives a full solution to graded homework (an integrity violation); a false positive means a student gets hints instead of a full explanation for an ungraded exercise (annoying but harmless). So the requirement should demand high recall: "On the instructor-labelled test set of 200 questions, recall for 'graded' shall be at least 0.95 and precision at least 0.80."

A complete AI-feature specification also covers:

• Data requirements: which data the model may use (only the course's uploaded materials), how it is labelled, how often the test set is refreshed.
• Human oversight: instructors can review flagged conversations; students can report a bad answer.
• Transparency: answers are labelled as AI-generated.
• Fallback: what the system does when the model is unavailable or unsure.
• Monitoring: the metrics are re-measured every month, because model updates and new course material change behaviour.

The AI angle: specifications are now prompts

When a team uses coding agents, the specification is increasingly the input to the agent. This has two consequences:

1. Ambiguity becomes bugs immediately. A human developer asks "3 reports from different students, or any 3 reports?". An agent usually guesses — silently — and writes consistent-looking code for its guess. Precise requirements and acceptance criteria are the best protection.
2. AI is a good ambiguity detector. Asking an assistant "List every question a developer would need to ask to implement this requirement" or "Give three different interpretations of this sentence" is an effective review technique — as long as a human decides the answers with the stakeholders.

Two risks to control: AI tools may "complete" missing details with plausible assumptions (always ask them to list assumptions explicitly), and they may produce long, impressive SRS documents full of unsourced requirements. Keep the rule from Chapter 3: every requirement has a source.

Key takeaways

• Good requirements are necessary, unambiguous, complete, consistent, feasible, verifiable, traceable and singular.
• Hunt ambiguity: weak words, vague quantities, passive voice, pronouns, undefined terms; keep a glossary.
• EARS templates (ubiquitous, When, While, If…then, Where) force triggers, states and responses to be explicit.
• Quality requirements need a metric, a target and a condition; prefer percentiles to averages.
• An SRS and a backlog are two containers for the same qualities; acceptance criteria are specifications.
• Prioritize with MoSCoW (and a real "Won't" list) or value/effort.
• Traceability gives coverage, orphan detection and impact analysis; changes go through a baseline, a change request and an impact analysis.
• Validate early: reviews, prototypes, acceptance tests written before code.
• AI features need accuracy requirements (precision, recall, which error is worse), data, oversight, transparency, fallback and monitoring.
• With coding agents, the spec is the prompt: ambiguity turns into silent assumptions — so specify precisely and make assumptions explicit.