Requirement Analysis
Computer ScienceΒ· Unit 12: Software Development, Topic 2Β· 15 min read
1. Core Types of Requirementsβ β ββββ± 4 min
Requirement Analysis
The process of eliciting, analysing, documenting and validating stakeholder needs for a new or modified software system
Example:
Gathering input from school staff to build a new attendance tracking system
All requirements are split into two core categories that CIE exams regularly ask you to classify:
Functional requirements: Describe what the system must do β specific features, actions, inputs, outputs and processes.
Non-functional requirements: Describe how the system must perform β constraints on speed, security, usability, reliability, cost and compatibility.
Classify each of the following as functional or non-functional for a new online banking app: (a) The app must allow users to transfer money between accounts, (b) The app must encrypt all user data at rest per industry regulations.
- 1
First, recall the difference between the two types of requirements:
- 2
Functional = what the system does, non-functional = constraints on how it works
- 3
(a) Transferring money is a specific action the app performs β this is a
- 4
(b) Encrypting data is a security constraint the app must meet β this is a
- 5
Final answer: (a) Functional, (b) Non-functional
Exam tip:
Always link your classification to the definition in your exam answer to get full marks, even if the classification seems obvious.
2. Stakeholder Identificationβ β ββββ± 3 min
Requirements can only be gathered correctly if all relevant stakeholders are identified first. Missing stakeholders leads to incomplete requirements that cause project failure.
Stakeholder
Any individual, group or organisation that has an interest in the development, use or outcome of the software system
Example:
End users, business managers, IT support teams, regulators, clients
A hospital is building a new patient record system. Name two stakeholders and one unique requirement each will have.
- 1
- Identify different groups affected by the system beyond just end users:
- 2
- First stakeholder: Doctor (end user). Requirement (functional): The system must allow doctors to access a patient's 5-year medical history in 2 clicks.
- 3
- Second stakeholder: Hospital compliance team (indirect stakeholder). Requirement (non-functional): The system must store all patient records for 10 years to meet legal regulations.
Exam tip:
Don't forget indirect stakeholders (like regulators or IT support) in your answers β examiners often test if you remember these.
3. Fact-Finding Methodsβ β β βββ± 5 min
Fact-finding is the process of gathering requirements from stakeholders. CIE frequently asks you to recommend and justify a method for a given scenario.
Method | Best For | Key Disadvantage |
|---|---|---|
Interviews | Small groups, detailed requirements | Time-consuming for large samples |
Questionnaires | Large groups, general requirements | Cannot probe unclear answers |
Observation | Understanding existing work processes | Intrusive, may change worker behaviour |
Document analysis | Reviewing existing system records | Documentation may be outdated |
A developer is building a new checkout system for a large supermarket chain with 400 checkout staff. Recommend a suitable fact-finding method to gather requirements from staff, justifying your choice.
- 1
- Context: We need to gather input from a large number of staff efficiently.
- 2
- Recommended method: Questionnaires
- 3
- Justification: Questionnaires can be distributed to all 400 staff quickly and at low cost, gathering input from a large representative sample. Interviewing every staff member would take too much time and resources.
- 4
- Limitation note: If the developer needed detailed insight into how staff use the current checkout process, they would combine questionnaires with observation of a small sample of staff.
Exam tip:
Always justify your choice by linking it to the specific scenario in the question, don't just list generic pros and cons.
4. Documentation and Validationβ β β βββ± 3 min
After gathering requirements, they must be documented clearly and validated to confirm they are complete, consistent, testable and achievable. Vague requirements are the leading cause of project scope creep.
Rewrite the vague requirement 'The app must be user-friendly' to make it testable.
- 1
- Add a specific, measurable criterion that can be verified during testing.
- 2
- An acceptable testable requirement is: 90% of first-time users can complete a purchase within 3 minutes of opening the app for the first time.
5. Common Pitfalls
Wrong move:
Classifying performance/constraint requirements as functional
Why:
Confuses what the system does with how it must perform
Correct move:
Always classify speed, security, usability and compliance constraints as non-functional requirements
Wrong move:
Only listing end users and clients as stakeholders
Why:
Ignores indirect stakeholders like regulators, IT support and maintenance teams
Correct move:
List all groups affected by the system, including those that don't use it directly
Wrong move:
Recommending interviews for hundreds of stakeholders
Why:
Interviews are too slow and resource-intensive for large groups
Correct move:
Recommend questionnaires for gathering requirements from large samples of stakeholders
Wrong move:
Accepting vague, untestable requirements in documentation
Why:
Vague requirements cannot be validated, leading to systems that don't meet stakeholder needs
Correct move:
Rewrite all requirements to include specific, measurable criteria
Wrong move:
Treating requirement analysis as a one-off step at the start of the project
Why:
Requirements often change as the project progresses and stakeholders clarify their needs
Correct move:
Validate requirements after elicitation and reconfirm changes throughout the project lifecycle
6. Quick Reference Cheatsheet
Concept | Key Definition | Example |
|---|---|---|
Functional Requirement | What the system must do | Process a customer payment |
Non-functional Requirement | How the system must perform | Process payment in <1 second |
Stakeholder | Any party with an interest in the system | End user, regulator, manager |
Questionnaires | Fact-finding for large groups | Gather input from 400 checkout staff |
Interviews | Fact-finding for small groups | Gather detailed requirements from the CEO |
Testable Requirement | Specific, measurable outcome | 90% of users complete checkout in <3 minutes |
When this came up on past exams
AI-estimated based on syllabus patterns β cross-check with official past papers for accuracy. Use only as revision-focus signals.
- 2022 Β· 12
Fact-finding method comparison
- 2023 Β· 11
Functional vs non-functional classification
- 2024 Β· 13
Stakeholder requirement identification
Going deeper
What's Next
Requirement analysis is the foundation of all successful software development projects, and it feeds directly into every subsequent stage of the software development lifecycle. Once requirements are fully elicited and validated, you will move on to create technical designs and models that translate stakeholder needs into a buildable blueprint for the system. Mastering requirement analysis concepts is also critical for topics like project management, system testing and system evaluation that appear later in your CIE 9618 syllabus. This topic is regularly tested in both paper 1 and the pre-release case study component, so building a strong understanding here will earn you consistent marks in the final exam.