Requirements engineering: turning need into a design contract.

Why requirements work carries more weight than any other phase.

Requirements engineering exists because the largest single source of software project failure, measured across half a century of empirical studies, is not bad code or missed deadlines but a system that does not match what its users need. The leverage available at the requirements stage is therefore economic, not procedural: time spent here saves orders of magnitude later.

The economic case

The classic curve comes from Barry Boehm's Software Engineering Economics (Prentice-Hall, 1981), which used data from TRW Inc. and IBM to plot the cost of fixing a defect against the phase in which the defect is detected. Boehm found the cost grows roughly exponentially with the lag between the introduction of the defect and its discovery. A defect introduced during requirements that is caught and fixed during requirements costs unit value; the same defect caught during coding costs 5 to 10 times more; caught during system test, 10 to 25 times more; caught after release, 50 to 200 times more. Subsequent industrial replications across very different organisations (IBM, NASA, Hewlett-Packard, GTE; summarised in Boehm and Basili, "Software Defect Reduction Top 10 List", IEEE Computer, 34(1), 2001) confirm the shape of the curve, with the post-release multiplier most often falling in the 50-to-100 range.

Two consequences follow. First, defects whose root cause is in requirements dominate the cost-and-schedule overruns of large projects (Standish Group CHAOS reports, 1994 to present, and the McConnell Code Complete survey). Second, even modest investment in requirements quality at the start (more elicitation interviews, a structured specification template, a peer review) pays back many times over by the end of the project. This is the empirical foundation for treating requirements engineering as a distinct sub-discipline, with its own standards (IEEE 830 in 1998, superseded by ISO/IEC/IEEE 29148 in 2011 and revised in 2018) and its own dedicated literature.

Why this is the project's identity stage

A second, less obvious point follows from the economics: the requirements stage is also where the project's identity is decided. The Twitter 140-character limit was a requirement, not an implementation accident. The iPhone's "no-stylus" rule was a requirement that ruled out a whole class of hardware solutions before Jonathan Ive's industrial-design team ever opened a CAD file. WhatsApp's end-to-end encryption guarantee was a requirement, not a feature added later. None of these defining properties were decided by writing code; each was decided by someone writing a sentence about what the system would or would not do. For the COMP433 project, the same logic applies on a smaller scale: the requirements document is the artefact in which your team decides what the system is, not just what it does.

How this companion is organised

The first half covers what requirements are and how they are written: the definition (section 2), the three abstraction layers (section 3), the functional/non-functional/domain taxonomy (sections 4 and 5), and the five-activity RE process (section 6). The second half covers how the work becomes an artefact: notation choices (section 7), the structured specification template (section 8), the requirements document structure (section 9), validation (section 10), and per-requirement effort estimation with a working calculator (section 11). Section 12 then collects what is concretely due at the Phase 2 deadline. Section 13 lists the marking pitfalls; section 14 lists the references. The running example throughout follows the course lecture deck: the Mentcare patient information system for mental health care (called MHC-PMS in older editions of Sommerville; the same system).

A requirement is a statement the system must satisfy.

Requirements range from one-line wishes ("the system shall be easy to use") to formal mathematical specifications. Both ends of that range are still called requirements. The discipline is in knowing which end you are at and why.

Sommerville's definition (Software Engineering, 10th ed., 2015) is the operational one: a requirement is "a description of a service that the system must provide, or a constraint on the system." The two clauses matter independently. A service is something the system does. A constraint is a property the system has. Most documents contain both, often mixed together.

Beyond the bare definition, a practitioner-facing observation matters: requirements serve two functions in one artefact, which explains why they are written in both abstract and detailed forms:

• As the basis for a bid. Before a contract is signed, the customer needs requirements they can understand, share, and compare across competing proposals. These are abstract by necessity. They will be interpreted differently by different bidders, and that is fine because the bidding process is also about which interpretation the customer prefers.
• As the basis for the contract itself. Once a supplier is chosen, the requirements stop being open to interpretation. They become a list of testable obligations against which the system will be accepted or rejected. The same word in the same document carries both meanings at different stages.

This dual role is the reason the abstraction layer of a requirement matters as much as its content. A statement that is perfect at the bidding stage may be useless at the acceptance stage, and vice versa.

User requirements, system requirements, software specification.

The canonical three-layer model (Sommerville, 10th ed.) distinguishes user requirements, system requirements, and software specification. Each layer has a different audience and uses different language. A document that fails to distinguish them tends to be wrong for everyone reading it.

Worked pair: a user requirement and its system refinement

By convention used throughout the course, every user requirement (UR) is numbered and refined into one or more system requirements (SR) with the same root. The notation is straightforward: UR4.0 refines into SR4.1, SR4.2, and so on. The shared root carries the traceability: any change to UR4.0 propagates to every SR4.x, and any test result against SR4.x rolls up to UR4.0. Below is the canonical example for account registration.

Notice the relationship. UR4.0 is a single sentence that the head of the clinic can read and confirm. SR4.1 through SR4.7 are seven sentences that the developer can build to and the tester can write acceptance tests against. They say the same thing at different levels of abstraction.

The numbering is not decorative. It is the foundation of traceability: every SR carries the prefix of the UR it refines, so a question about why a particular system requirement exists has an answer ("it implements UR4.0"), and a question about what testing covers a user requirement has an answer ("the tests for SR4.1 through SR4.7"). Section 10 and the discussion of traceability matrices return to this.

Functional, non-functional, and domain requirements.

Sommerville's classification separates requirements into three mutually exclusive categories: functional, non-functional, and domain. The third one is often skipped in lighter treatments and is exactly where the most subtle errors come from.

Functional requirements

Statements of the services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. They are usually written with the system as subject and "shall" as the modal verb. Example, from the Mentcare system:

Non-functional requirements

Constraints on the services or functions offered by the system. They describe how well, how fast, under what load, for whom, with what guarantees. They are not optional polish: if NFRs are not met, the system can be useless even when every functional requirement passes.

A worked NFR example for the Mentcare system:

Notice the verifiability: "available" is not abstract here, it has a measurable threshold (downtime under five seconds per day during stated hours). Section 5 returns to NFR families and metrics.

Domain requirements

Requirements that come from the application domain of the system and that reflect characteristics of that domain. Two examples from the course's lecture material:

• A train control system has to take into account the braking characteristics in different weather conditions.
• The Mentcare system has to enforce all confidentiality rules in accordance with national medical domain practices.

Domain requirements have two characteristic problems, both consequences of the fact that the domain is not the developer's home discipline:

• Understandability. Requirements are expressed in the language of the application domain, which is often not understood by the software engineers developing the system. A developer reading "braking shall account for adhesion coefficient at the rail-wheel interface" needs a translator before they can build to it.
• Implicitness. Domain specialists understand the area so well that they do not think to make the requirement explicit. A pharmacist will not say "the dose field shall reject negative values" because to them negative doses are unthinkable, but the system will accept them unless the requirement is written down.

Domain requirements often generate additional functional and non-functional requirements when they are unpacked. They also have the highest unit cost of being missed, because a missed domain requirement usually surfaces during operation, not testing.

Three NFR families, each with a measurable metric.

Sommerville's NFR classification sorts non-functional requirements into three families by where the constraint comes from. The families have different stakeholders, different acceptance criteria, and different test procedures.

Product, organisational, external

From wish to verifiable NFR

An NFR is almost always wrong on its first draft. The natural English form is a wish, and a wish cannot be tested. The conversion to a testable form is made explicit by distinguishing a goal (a general intention) from a verifiable non-functional requirement (a statement with a measurable threshold).

The goal is still useful: it tells the developers what the team is trying to achieve. The verifiable requirement tells the tester what to measure. Both belong in the document; they do not replace each other.

NFR metrics, by property

Below is the standard metric table for the most common NFR types. The entries are not exhaustive, but the pattern they set is: every NFR can be reduced to one or more measurable properties.

A useful editorial test: if an NFR cannot be tied to a row of this table or its extension, it is still a goal.

The five activities of requirements engineering.

Sommerville's RE process model has five activities. They are not strictly sequential; the process is iterative, conventionally drawn as a spiral that re-enters each activity as new information arrives. The list below is the canonical decomposition.

The five activities feed each other continuously. Elicitation in week 8 often invalidates a requirement specified in week 3; validation often surfaces an unstated stakeholder need; management often forces a re-prioritisation. The process is finished not when the activities stop but when the document is stable enough to commit to.

Five ways to write a system requirement.

Sommerville's table of notation choices is the standard taxonomy used in the course. Each row trades off readability against precision differently; most documents use more than one row.

The problems with relying on natural language alone are well-documented (Meyer 1985; Sommerville 2015, ch.4):

• Lack of clarity. Precision is difficult without making the document hard to read.
• Requirements confusion. Functional and non-functional requirements tend to be mixed up.
• Requirements amalgamation. Several different requirements may be expressed together in one sentence.

The standard fix is to keep natural language for user requirements (so the customer can read them), then switch to structured natural language for system requirements (so the developer can build to them).

The structured specification template, in nine fields.

The structured-natural-language template used in the course is adapted from Cockburn's use case format (Cockburn, 2001). Every system requirement that is non-trivial gets one of these. The template's value is in the discipline it forces: a field that is blank is a question still open.

The fields, in order, are: Title, Purpose, Description, Actors, Trigger, Pre-condition, Workflow, Alternative Workflow, Post-condition. The course's canonical worked example is the insulin pump's dose computation routine:

The fields are not optional. A spec with no actors does not say who triggers it; a spec with no pre-condition is unsafe; a spec with no post-condition cannot be tested. The "alternative workflow" field captures the most common source of bugs in production systems: the path that runs when the normal one does not work.

For a more readable but equivalent version, the template can be flattened into a paragraph: "The CompDose requirement, triggered every 10 minutes by SystemTimer when the insulin reservoir is sufficient, reads the current sugar level, compares it against the previous two readings, computes a single dose between 5 and 15 mg, and either delivers it or raises an alert; in either case the reading buffer is updated." The structured form is preferred for the document; the paragraph form is useful for review meetings.

Tabular specifications are useful when a requirement's behaviour is condition-driven, for example a decision table giving the dose for each combination of trend and rate. The course slides include the tabular form for CompDose; we omit it here for brevity.

The requirements document has a standard structure.

A requirements document is the agreed statement of the system requirements. It is an artefact that has to serve customers, developers, testers, regulators, and the project's own future. The structure used in the course follows Sommerville's nine-section template, anchored in the IEEE 830 (1998) recommended practice and its successor ISO/IEC/IEEE 29148 (2018).

What a requirements document must do

Before the structure, the obligations. A requirements document must:

• Specify external system behaviour. What the system does, as visible from outside.
• Specify implementation constraints. What the implementation must (or must not) do, regardless of how it does it.
• Be easy to change. Real projects revise requirements continuously; a document that cannot be revised becomes obsolete.
• Serve as a reference tool for maintenance. Years after the project ships, the maintenance team will read this document to understand why the system behaves the way it does.
• Record forethought about the life cycle of the system. What changes are anticipated, what is fixed, what is open.
• Characterise responses to unexpected events. The system's behaviour at the edges, not just on the happy path.

The IEEE / ISO structure, expanded

The high-level skeleton (IEEE Std 830-1998, now superseded by ISO/IEC/IEEE 29148:2018) is short:

• Introduction
• General description
• Specific requirements
• Appendices
• Index

This is a generic skeleton that has to be instantiated for a specific system. The COMP433 instantiation, drawn from Sommerville's chapter 4 and the IEEE 830 outline, expands it into nine sections:

Readers of the requirements document

The document is read by four kinds of audience, each looking for different things:

Writing rules

Four writing rules apply to every requirement, regardless of which section it is in. They are restated in every modern RE textbook (Sommerville; Robertson and Robertson, Mastering the Requirements Process, 3rd ed.; Wiegers and Beatty, Software Requirements, 3rd ed.):

1. Invent a standard format and use it for every requirement. Consistency reduces the cognitive load of reading the document; readers learn the format once and then focus on content.
2. Use language consistently. Use shall for mandatory requirements; use should for desirable but auxiliary requirements. Never mix the two without intent.
3. Use text highlighting to identify the key parts of each requirement. Bold, italic, or a dedicated typographic style for the subject and the obligation.
4. Include a rationale. Every non-trivial requirement should explain why it is there. Six months later, a reader will be glad of the explanation; six years later, the maintenance team will be glad of it.

And one negative rule: avoid computer jargon. The customer is the document's primary audience for the User requirements section; jargon there is a barrier, not precision.

Three techniques, seven things to check.

Requirements validation asks whether the specified requirements define the system the customer actually wants. It is distinct from verification, which asks whether the system meets the specified requirements; validation is the upstream activity that decides whether the specification is right in the first place.

The three validation techniques

The seven validation checks

Whichever validation technique is used, the same questions are asked of each requirement:

Traceability matrices

A traceability matrix is a tabular tool that records, for each requirement, where it comes from and where it goes. The minimal version is a two-column list: requirement ID and source. A richer version is a grid that maps every requirement to every test case, every design element, and every regulation it implements.

The value of traceability matrices is measured in change. When a requirement is revised, the matrix tells you which tests need updating, which design elements may be affected, and which downstream documents need a corresponding edit. Without the matrix, the same question takes hours of manual cross-referencing.

Estimating effort, requirement by requirement.

Once the requirements are specified, the natural next question is: what will this cost, and how long will it take? COMP433 uses a simplified, per-requirement estimation method specified in the course lecture notes. The method is bottom-up, transparent, and easy to revise. Below: the method, its context among other estimation techniques, and an interactive calculator that runs it on whatever requirements list you enter.

The simplified per-UR method

The method's data model is small. For each user requirement, the estimator records two numbers:

1. The estimated number of developers who can work concurrently on the requirement without stepping on each other's work.
2. The estimated average effort per developer, in person-weeks.

From these, two derived quantities are computed:

• Total effort for the requirement = developers × effort per developer (in person-weeks).
• Total effort for the project = sum of the per-requirement totals.

Project-level numbers then follow:

• Average effort per requirement across the list (used as a sanity check).
• Schedule time with a 30% buffer for holidays, integration, and slack: total effort × 1.30.
• Cost = schedule time × average weekly salary.
• Quoted price range: minimum price = cost × 1.10 (10% margin); maximum price = cost × 1.30 (30% margin).

The method is not a black box. Every input is one the estimator chose, and every output is a direct arithmetic consequence of the inputs. That transparency is the method's value: a stakeholder who questions a number can be shown which input drives it, and an estimator who learns the project is slipping can revise one row of the table to absorb the new information.

Interactive calculator

The calculator below ships with the worked example from the course lecture notes pre-filled. Edit any cell to recompute. Add or remove rows for your own requirements. Change the weekly salary, schedule buffer, or margin range to reflect your context.

The example data above matches the worked example in the course lecture notes (slide 105). Reset returns to it. The four parameters underneath the table (buffer, salary, margins) are the dials a real estimator would adjust to match their context; defaults follow the course example.

How this method compares to others

The per-UR method is one entry in a long literature on software effort estimation. The most widely cited alternatives are listed below, with the kind of project each is best suited to. The course's simplified method is the appropriate choice for Phase 1 of the COMP433 project; the others are listed so the reader knows what else exists and when to reach for them.

Two observations from the literature, both well-supported by industrial data and worth carrying into any estimation exercise:

• No method is reliably accurate in absolute terms. Industrial surveys (e.g., Jorgensen and Shepperd, "A Systematic Review of Software Development Cost Estimation Studies", IEEE Trans. Software Engineering, 2007) report typical errors of plus or minus 30 to 50 percent across all major methods. The right question is not "which method is most accurate" but "which method's errors do I understand and can I revise as I learn more".
• The estimate that is revised survives. Methods that produce a single number which is then defended for the life of the project fail more often than methods that produce a number which is openly revised every time the team learns something new. The transparency of the per-UR method is its main advantage here: a per-row number is easy to revise.

What is concretely due at the Phase 2 deadline.

The first eleven sections lay out the discipline. This one lists exactly what your team submits at the Phase 2 deadline. Treat the checklist as the assessment grid: each row is evaluated independently, and a missing row is the most common cause of weak submissions.

The five artefacts

A practical pre-submission checklist

Before you submit, the team runs through the following list together. Each item should be answerable with "yes, page N" or "yes, section N". Any "no" is rework before the deadline, not after.

1. Does the document have the nine-section structure from section 9 (Preface, Introduction, Glossary, User Requirements Definition, System Architecture, System Requirements Specification, System Models, System Evolution, Appendices)?
2. Is every UR uniquely numbered and addressed to a named actor or stakeholder goal?
3. For each UR that is more than one line of behaviour, are there explicit SR refinements with a shared identifier prefix?
4. Does every NFR have a number and a unit? If you cannot test it, it is not yet a requirement.
5. Are the non-trivial SRs written up in the nine-field structured spec template, including the Alternative Workflow field?
6. Does the effort estimate cover all URs, with the cost and price-range roll-up?
7. Has at least one team member (not the author) read each section against the seven validation checks in section 10 (valid, consistent, complete, realistic, verifiable, comprehensible, traceable)?
8. Has the requirements document been version-stamped and signed off by the team for submission?

Eight failure modes seen too often in practice.

Drawn from Sommerville, Wiegers, Robertson and Robertson, and recurring review findings on real requirements documents. Each one is a recurring source of defects discovered too late.

Sources cited above, and where to go next.

The course textbook is identified at the head of the list; the rest are works directly referenced in the body and standard practitioner references.

Course material

Requirements engineering, practitioner

Standards

Effort estimation