Unit 2: Requirements
Learning Objectives
- Distinguish between functional and non-functional requirements
- Identify stakeholders and define system boundaries clearly
- Structure informal ideas as requirement statements ready for use case modelling
Core Input
Read through each tab before moving to the key concepts below.
A requirement is a statement of what a system must do, or how well it must do it. Requirements fall into two categories:
- Functional requirements describe specific behaviours — what the system must do. They are usually expressed as: "The system shall allow users to…" Example: The system shall allow students to submit assignments as PDF files.
- Non-functional requirements (NFRs) describe qualities — how well the system must perform. They constrain the design rather than defining features. Example: The system shall respond to any user action within 2 seconds under normal load.
NFRs are often categorised by type: performance, security, usability, reliability, maintainability, and portability. They are frequently overlooked early in projects — and then very expensive to retrofit later.
Requirements come from stakeholders — anyone who has an interest in the system. Different stakeholders care about different things, and their needs must all be captured.
Stakeholders are often grouped into three tiers:
- Primary stakeholders — those who interact directly with the system. Example: students, lecturers, booking clerks.
- Secondary stakeholders — those who benefit indirectly but do not use the system themselves. Example: a department head who relies on reports generated by the system.
- Tertiary stakeholders — those who do not use or directly benefit from the system, but have an interest in how it operates. Example: data protection regulators, IT security teams.
Involving the right stakeholders early prevents costly misunderstandings. A system built without input from its actual users rarely meets their real needs.
A system boundary defines what is inside the system and what is outside it. This sounds obvious but is one of the most common sources of project failure — teams that do not agree on scope will design different systems.
Defining the boundary means deciding:
- Which functions the system will perform
- Which functions will be handled by people or external systems
- Which data the system owns and which it receives from elsewhere
A clear boundary prevents scope creep — the gradual addition of unplanned features that delays delivery and inflates cost. In UML, the system boundary is represented visually by the rectangle in a use case diagram.
Key Concepts: Types of Requirement
Expand each item to check your understanding.
A functional requirement defines a specific capability the system must provide. It describes a behaviour: an action the system can perform, a response it gives, or data it must store.
Examples:
- The system shall allow registered users to reset their password via email.
- The system shall display a booking confirmation number after a successful reservation.
- The system shall allow administrators to generate monthly usage reports.
Functional requirements are the backbone of the system's specification. They are directly testable: either the system does the thing or it does not.
A non-functional requirement (NFR) defines a quality or constraint on how the system performs its functions — not what it does, but how well it does it.
Common NFR categories:
- Performance — response time, throughput, latency
- Security — authentication, authorisation, data encryption
- Usability — learnability, accessibility, error tolerance
- Reliability — availability, fault tolerance, recovery time
- Maintainability — ease of modification, testability
- Portability — ability to run on different platforms
NFRs often have the greatest influence on system architecture — a requirement for 99.99% availability affects every design decision.
Not exactly — but they are closely related. A functional requirement describes a capability; a non-functional requirement constrains how that capability must be delivered.
For example:
- Functional: The system shall allow users to search the product catalogue.
- Non-functional: Search results shall be returned within 1 second for catalogues of up to 100,000 items.
The NFR does not add a new feature — it specifies a quality standard for an existing one. Both must be captured and both will be tested.
NFRs are harder to elicit because stakeholders tend to think in terms of features, not qualities. When asked "what should the system do?", a client will describe functions. Performance, security, and reliability have to be actively asked about.
They are also harder to specify precisely. "The system should be fast" is not a requirement — "The system shall load the homepage in under 1.5 seconds on a standard broadband connection" is. Vague NFRs cannot be designed for or tested against.
Key Concepts: Stakeholders and System Boundaries
Continue with the remaining key concepts.
Start with the obvious primary users, then ask: who else is affected by what this system does? Useful questions:
- Who provides data to the system? Who consumes it?
- Who is responsible if something goes wrong?
- Who has to approve or certify the system before it goes live?
- Whose job changes because this system exists?
Missing a stakeholder early is a common source of expensive late changes — a security team discovered only during final testing, or an accessibility requirement raised only after launch.
Stakeholders have different goals, priorities, and constraints. Conflict is normal and expected. Common examples:
- Users want simplicity; administrators want detailed audit logs (which add complexity)
- Clients want fast delivery; developers want time to build robust architecture
- Regulators require data retention; users want the right to delete their data
Resolving conflicts is a negotiation process — not a technical one. The engineer's role is to surface the conflict, present the trade-offs, and facilitate a decision. Requirements documents should record which conflicts arose and how they were resolved.
The system boundary separates what the software system is responsible for from what exists outside it. Outside the boundary are actors: people, external systems, or hardware that interact with the system.
For example, in an online library system:
- Inside: catalogue search, borrowing records, account management, overdue notifications
- Outside: the payment gateway (external system), the reader (human actor), the physical library building
What is outside the boundary is not ignored — it must be interfaced with. Defining the boundary means deciding exactly what those interfaces look like.
Scope creep is the gradual expansion of a project beyond its original agreed scope. It typically happens when requirements are vague, stakeholders add requests incrementally, or the team does not push back on new feature requests.
A clearly documented system boundary acts as a reference point. When a new request arrives, the team can ask: "Is this inside or outside our agreed scope?" If it is outside, it requires a formal change — not an informal addition.
This is not about refusing to change. It is about making changes visible, deliberate, and properly costed.
Watch
Video coming soon
Check Your Understanding
Select the best answer for each question.
Which of the following is a non-functional requirement?
Why is it important to define system boundaries early in a project?
Activities
Individual task
Using the system your group chose in Unit 1, write a requirements list of at least eight requirements. For each requirement:
- Write the requirement as a clear statement: "The system shall…"
- Classify it as functional (F) or non-functional (NF)
- If non-functional, identify its category (performance, security, usability, etc.)
Aim for a mix: at least five functional and at least three non-functional requirements.
Pair task
Compare your requirements lists with a partner.
- Are there any requirements one of you classified differently (one says F, the other NF)? Discuss and agree on the correct classification.
- Are there requirements on one list that are missing from the other? Should they be added?
- Identify one requirement that is too vague to be useful. Rewrite it together so that it is precise, testable, and unambiguous.
Group task
Imagine three different stakeholders for your system — for example, an end user, an administrator, and a regulator — who each have different priorities.
As a group:
- Identify one requirement from your list where these three stakeholders would have conflicting interests.
- State each stakeholder's position clearly.
- Decide how the conflict should be resolved — and record your reasoning.
There is no single right answer. The goal is to practise structured negotiation and to understand that requirements engineering is partly a social process.
Review
- Primary — direct users of the system
- Secondary — indirect beneficiaries (e.g. managers who rely on reports)
- Tertiary — those with a regulatory or oversight interest (e.g. data protection officers)
All three groups can generate requirements. All three can veto a design that fails their interests.
Use case diagrams (Unit 3) are a tool for capturing functional requirements visually. Each use case corresponds to something the system must do — a functional requirement. The actors in a use case diagram correspond to stakeholders. The system boundary in a use case diagram represents the scope you defined during requirements analysis.
Requirements analysis is the foundation. Without it, a use case diagram is just boxes and arrows — it has no verified connection to what anyone actually needs.
Proceed to Unit 3: Use Case Diagrams when ready.