# Requirement Analysis

> Computer Science · CIE A-Level
> Source: https://www.owlsprep.com/study/cie-9618-u12-requirement-analysis/

Requirement analysis is the first critical stage of the software development lifecycle, where you identify what a new system must do and what constraints it must follow. This module covers all exam-focused concepts for CIE 9618.

**Prerequisites:** [Basic understanding of the software development lifecycle](https://www.owlsprep.com/study/cie-9618-u12-sdlc-stages/)

## Learning objectives

- Distinguish between functional and non-functional requirements
- Identify all relevant stakeholders and their requirements
- Select and justify appropriate fact-finding methods for different scenarios
- Produce valid, testable requirement documentation for software projects

## Core Types of Requirements

**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.

**Worked example:** 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.

## Stakeholder Identification

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

**Worked example:** A hospital is building a new patient record system. Name two stakeholders and one unique requirement each will have.

1. 1. Identify different groups affected by the system beyond just end users:
2. 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. 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.

## Fact-Finding Methods

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 |

**Worked example:** 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. 1. Context: We need to gather input from a large number of staff efficiently.
2. 2. Recommended method: Questionnaires
3. 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. 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.

## Documentation and Validation

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.

> **tip**
>
> All good requirements are testable: replace vague statements like 'the system should be fast' with measurable statements like 'the system loads the checkout page within 2 seconds' that can be verified during testing.

**Worked example:** Rewrite the vague requirement 'The app must be user-friendly' to make it testable.

1. 1. Add a specific, measurable criterion that can be verified during testing.
2. 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.

## Common pitfalls

- **Wrong:** Classifying performance/constraint requirements as functional
  - Why it fails: Confuses what the system does with how it must perform
  - Correct: Always classify speed, security, usability and compliance constraints as non-functional requirements
- **Wrong:** Only listing end users and clients as stakeholders
  - Why it fails: Ignores indirect stakeholders like regulators, IT support and maintenance teams
  - Correct: List all groups affected by the system, including those that don't use it directly
- **Wrong:** Recommending interviews for hundreds of stakeholders
  - Why it fails: Interviews are too slow and resource-intensive for large groups
  - Correct: Recommend questionnaires for gathering requirements from large samples of stakeholders
- **Wrong:** Accepting vague, untestable requirements in documentation
  - Why it fails: Vague requirements cannot be validated, leading to systems that don't meet stakeholder needs
  - Correct: Rewrite all requirements to include specific, measurable criteria
- **Wrong:** Treating requirement analysis as a one-off step at the start of the project
  - Why it fails: Requirements often change as the project progresses and stakeholders clarify their needs
  - Correct: Validate requirements after elicitation and reconfirm changes throughout the project lifecycle

## 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 |

## 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.

- [Software Design Methods](https://www.owlsprep.com/study/cie-9618-u12-software-design-methods/)
- [Testing](https://www.owlsprep.com/study/cie-9618-u12-testing/)
- [Debugging](https://www.owlsprep.com/study/cie-9618-u12-debugging/)

---

From [OwlsPrep](https://www.owlsprep.com) — free study guides for A-Level, IB, AP and IGCSE, written against the official syllabus. Canonical page: https://www.owlsprep.com/study/cie-9618-u12-requirement-analysis/