Software requirements are specifications that describe what a system must do (functional requirements) and how well it must do it (non-functional requirements). Gathering clear requirements is the first phase of the software development life cycle — without them, developers risk building a product that fails to satisfy its users.
What is a software requirement?
A requirement is a statement of what a system must do or a quality it must have. Requirements serve as the contract between the client (who wants the software) and the development team (who build it). They are gathered through interviews, observation, surveys, and analysis of existing systems.
Why requirements matter:
Studies consistently show that most software project failures trace back to poor requirements — either they were never gathered properly, they were ambiguous, they changed during development without being tracked, or the development team misunderstood them. The cost of fixing a missed requirement grows dramatically the later it is discovered: a requirement missed at the start is far cheaper to fix than a feature built incorrectly and discovered after delivery.
What are functional requirements?
Functional requirements describe what the system must do — its specific features and behaviours.
They answer: "What must the system be able to do?"
Format: a functional requirement is typically written as "The system shall [do something]."
Examples for a school library management system:
| # | Functional requirement |
|---|---|
| F1 | The system shall allow students to search for books by title, author, and subject |
| F2 | The system shall record when a book is borrowed and by which student |
| F3 | The system shall send an automated email reminder when a loan is overdue |
| F4 | The system shall allow staff to add, edit, and remove book records |
| F5 | The system shall display the number of copies available for each title |
Functional requirements are testable: given a specific input, you can verify whether the system produces the correct output.
What are non-functional requirements?
Non-functional requirements (NFRs) describe how well the system performs its functions — the qualities and constraints it must meet.
They answer: "How must the system perform?"
Common categories of non-functional requirements:
| Category | Example |
|---|---|
| Performance | The system shall load search results within 2 seconds for up to 500 concurrent users |
| Reliability | The system shall be available 99.9% of the time during school hours |
| Usability | A student with no training shall be able to complete a book search in under one minute |
| Security | Student data shall be stored encrypted and accessible only to authorised staff |
| Maintainability | The system shall be documented so that a new administrator can take over within one day |
| Portability | The system shall run on Chrome, Firefox, and Safari without modification |
| Scalability | The system shall support up to 2,000 registered student accounts |
Non-functional requirements are often harder to test precisely but are critically important. A system that does the right things (functional) but does them too slowly, insecurely, or unreliably will still be rejected by users.
How are requirements gathered?
| Technique | How it works | Best for |
|---|---|---|
| Interviews | One-to-one or group conversations with stakeholders | Understanding current workflow, uncovering implicit needs |
| Questionnaires/surveys | Structured questions sent to many users | Gathering quantitative data, prioritising features |
| Observation | Developer watches users performing their current tasks | Spotting inefficiencies users have stopped noticing |
| Document analysis | Reviewing existing forms, manuals, and reports | Understanding current data structures and processes |
| Prototyping | Building a mock-up for users to react to | Uncovering requirements that users cannot articulate verbally |
What is a user story?
A user story is a short, informal requirement written from the perspective of an end user. The standard format is:
As a [type of user], I want [a goal], so that [a reason].
Examples:
- As a student, I want to search for books by subject, so that I can find resources for my homework quickly.
- As a librarian, I want to see all overdue loans at a glance, so that I can send reminders efficiently.
- As a parent, I want to see my child's borrowing history, so that I can encourage wider reading.
User stories are popular in agile development because they are easy for non-technical stakeholders to write and understand, and they keep the focus on user value rather than technical implementation.
What are success criteria?
Success criteria are measurable statements that define when a requirement has been satisfied. Good success criteria are SMART: Specific, Measurable, Achievable, Relevant, and Time-bound.
| Requirement | Poor success criterion | Good success criterion |
|---|---|---|
| "Fast search" | "The search should be fast" | "Search results appear in under 2 seconds on a standard school network connection" |
| "Easy to use" | "Students find it easy" | "90% of Year 7 students can perform a search within 1 minute after watching a 2-minute tutorial" |
| "Secure" | "Data is protected" | "All student data is stored AES-256 encrypted and access logs are retained for 12 months" |
Success criteria are the basis for acceptance testing — the final verification that a delivered system meets the client's requirements before sign-off.
Frequently asked questions
Why are functional and non-functional requirements distinguished?
Separating them helps developers prioritise and test appropriately. Functional requirements tell you what to build; non-functional requirements tell you how good it needs to be. Both matter — a secure but non-functional system is useless, and a highly functional but insecure one is dangerous. By labelling them separately, development teams can allocate specialists (e.g. security engineers for security NFRs) and apply different testing strategies (functional testing vs load testing vs penetration testing).
What happens if requirements change during development?
Changing requirements mid-project is one of the most common causes of software project overruns. Good development teams use change control processes: proposed changes are documented, assessed for impact (cost, time, risk), approved or rejected by stakeholders, and then incorporated into the requirements document with version tracking. Agile methods embrace controlled change through regular review cycles (sprints), while traditional waterfall methods try to freeze requirements early. Neither approach eliminates change entirely.
How do requirements relate to test plans?
Requirements and test plans are directly linked. Each testable requirement should appear in the test plan as one or more test cases. The test specifies the input, the expected output (derived from the requirement), the actual output, and whether the test passed. This traceable link between requirement and test — called requirements traceability — ensures that every requirement is verified and that no test case is written for a feature that was never required.
Is requirements gathering covered in the GCSE programming project?
Yes. Both AQA and OCR GCSE Computer Science controlled assessment (programming project or NEA) require students to analyse the problem and define requirements before coding. Mark schemes award credit for clearly stated, testable requirements, and for linking test results back to those requirements. Students who skip requirements analysis typically produce programs that solve a vague or self-invented problem rather than a well-defined client need.
Need help planning your GCSE programming project from requirements to testing? Professor Turing at aitutors.me will guide every phase of your project.