Requirements Gathering

Where this helps: understanding a problem properly before you build anything. In the IB Computer Science Internal Assessment this is Criterion A (consultation with a client and success criteria). The skill applies to any software project.

Table of Contents

  1. Why This Page Exists
  2. Start With the Client, Not the Code
  3. Two Kinds of Requirement
    1. Functional requirements
    2. Non-functional requirements
  4. From a Vague Wish to a Testable Requirement
  5. Success Criteria
  6. Is It Worth Building? Feasibility
  7. Worked Example: A Music Teacher’s Payment Tracker
  8. Quick Check
  9. Classify the Requirement
  10. Practice Exercises
    1. Core
    2. Extension
    3. Challenge
  11. Connections

Why This Page Exists

The most expensive mistake in software is not a bug. It is building the wrong thing well. A program can be elegant, fast, and correct, and still be useless because it solved a problem nobody actually had.

Requirements gathering is the work that prevents that: finding out what the people who will use the software genuinely need, writing it down clearly enough to build and to test, and deciding, before you start, whether the project is worth doing at all. It is the least glamorous part of a project and the one that most often decides whether it succeeds.

Start With the Client, Not the Code

A client (or stakeholder) is the person who has the problem your software will solve. They might be a real customer, a teacher, a business, or a member of your family. The single most important habit in this whole topic is: ask them, do not assume.

You are not the user. What seems obvious to you may not match how the client actually works, and the features you find exciting may not be the ones they need. Good requirements come from listening, and there are a few standard ways to listen.

Technique What it is Good for
Interview A conversation with the client about their problem and how they work now Depth: understanding the why behind a request
Questionnaire A set of written questions sent to many people Breadth: patterns across a group of users
Observation Watching the client do the task the software will support Catching steps people forget to mention
Studying the current system Looking at how the job is done now (on paper, in a spreadsheet, in another app) Finding what to keep and what to fix

A good interview asks open questions (“walk me through how you do this now”) rather than closed ones (“do you want a login screen?”). The client understands their problem; your job is to draw it out, not to hand them your solution and ask them to approve it.

The best single question to ask a client is some version of “what happens today when this goes wrong?” Their answer usually reveals the requirement that matters most, the one they would never have thought to ask for directly.

Two Kinds of Requirement

Once you understand the problem, you write down requirements: clear statements of what the software must do or be. They come in two kinds, and telling them apart is a genuinely useful skill.

Functional requirements

A functional requirement is something the system must do: a feature or a behaviour. It describes an action and its result.

  • “The system must let a teacher record that a student has paid for a lesson.”
  • “The system must show a list of all unpaid lessons for a chosen month.”
  • “The system must calculate the total owed by each student.”

The test for a functional requirement: could you demonstrate it working? Each one is a thing the program does.

Non-functional requirements

A non-functional requirement is a quality or constraint the system must have: not what it does, but how well it does it, or the rules it must respect.

  • “The system must respond to a search in under two seconds.” (performance)
  • “The system must keep student payment records private.” (security)
  • “A new user must be able to record a payment without training.” (usability)
  • “The system must run on the school’s existing laptops.” (portability)

Common categories of non-functional requirement are performance, security, usability, reliability, and portability. They are easy to forget because clients rarely ask for them out loud, but they are often what decides whether people actually use the finished software.

The classic confusion: “the system must be secure” is not, on its own, a good requirement. It is a non-functional goal with no way to test it. Turn it into something checkable: “payment records must only be visible after logging in with a password.” A requirement you cannot test is a wish, not a requirement.

From a Vague Wish to a Testable Requirement

Clients speak in wishes. Your job is to turn each wish into a requirement precise enough to build and to test. A useful checklist is that a good requirement is specific, measurable, and testable.

The client says The requirement you write
“It should be quick.” “Any search returns results in under 2 seconds.”
“I want to see who owes money.” “The system displays each student’s name and total amount owed, sorted by amount.”
“It has to be easy.” “A teacher can record a payment in 3 clicks or fewer from the main screen.”

The pattern is always the same: replace a feeling (“quick”, “easy”) with something you could measure and tick off. That precision pays off twice, once when you build (you know what “done” means) and once when you test (you know what to check).

Success Criteria

Success criteria are the specific, measurable statements you will use at the very end to judge whether the project worked. They come directly from the requirements, and you agree them with the client before building, so nobody moves the goalposts later.

Good success criteria are testable and tied to the client’s real needs:

  • “A teacher can record a lesson payment and see it reflected in the student’s total immediately.”
  • “The monthly unpaid-lessons report can be produced in under a minute.”
  • “No payment record is visible without logging in.”

Weak success criteria are things you cannot honestly test, like “the code is well written” or “the program is user-friendly” with no way to measure it. If you cannot picture the test you would run to check a criterion, rewrite it.

Note for IB CS learners: in the Internal Assessment, success criteria written in Criterion A are what you evaluate against in Criterion E. Vague criteria at the start make a weak evaluation at the end unavoidable, so it is worth getting them measurable early.

Is It Worth Building? Feasibility

Not every good idea should become a project. Feasibility is the honest check, done early, of whether a project can realistically succeed. Deciding not to build something, or to build a smaller version, is a valid and mature outcome.

A common framework for feasibility is TELOS, five angles to pressure-test an idea:

Letter Aspect The question it asks
T Technical Do we have the skills and technology to actually build this?
E Economic Is it worth the cost, time, and effort compared to the benefit?
L Legal Are we allowed to do this? (data protection, copyright, licensing)
O Operational Once built, will it fit how people actually work, and can it be maintained?
S Schedule Can it be finished in the time available?

A project can be technically possible but fail on schedule, or perfectly legal but not worth the cost. TELOS forces you to look at all five before committing, instead of discovering the fatal problem halfway through.

For a school project, Technical and Schedule usually bite hardest. Be honest about what you can build in the time you have. A smaller solution that is finished and evaluated beats an ambitious one that is half-working.

Worked Example: A Music Teacher’s Payment Tracker

Scenario. Ms Okafor teaches violin to about forty students across three schools. She currently tracks who has paid for lessons in a paper notebook, and she keeps losing track of who owes what. She asks you to build something to help.

Consultation. You interview her rather than guessing. You learn that she does not want a full accounting system; she wants to answer one question fast: who owes me money, and how much? She works from her phone between lessons, so it has to be usable on a small screen.

Functional requirements (a sample):

  • Record a student, the school they attend, and the lesson fee.
  • Mark a lesson as paid or unpaid on a given date.
  • Show, for any month, a list of students with unpaid lessons and the total each owes.

Non-functional requirements:

  • Usable on a phone screen, one-handed, between lessons (usability).
  • Payment data is private and not visible to students (security).
  • Works without an internet connection in a school with poor signal (reliability).

A success criterion: “Ms Okafor can see a correct list of everyone who owes money for the current month in under 30 seconds.”

Feasibility (TELOS, briefly): Technically simple (a small data store and a few screens). Economically fine (her time saved is worth it). Legally, it holds personal data, so it must be kept private. Operationally, it must match her phone-first workflow or she will go back to the notebook. On schedule, it is small enough to finish. The verdict: worth building, kept deliberately small.

Notice that the interview changed the project. Left to guess, you might have built a large accounting tool. Listening revealed that the real requirement was speed of answering one question, and that shaped everything else.

Quick Check

Q1. "The system must return search results in under two seconds." What kind of requirement is this?

Q2. Which of these is a functional requirement?

Q3. What is the most reliable way to find out what a client actually needs?

Q4. A team worries: "Even if we build this, no one at the school will be able to maintain it afterwards." In a TELOS feasibility check, which aspect is this?

Q5. Which of these is the strongest success criterion?

Q6. What is the purpose of a feasibility check?

Classify the Requirement

For each requirement, write whether it is functional or non-functional.

Fill in the blanks with functional or non-functional.

// The system lets a user reset a forgotten password
// Type: 

// The system works on phones, tablets, and laptops
// Type: 

// The system emails a receipt after each payment
// Type: 

// Only logged-in staff can see payment records
// Type: 

// The system sorts students by the amount they owe
// Type:

On the last one, “sorts students by amount owed” is a feature the system performs, so it is functional. If it read “the sorted list must appear in under one second”, that timing part would be non-functional. The same feature can carry both kinds of requirement.

Practice Exercises

Note for IB CS learners: these mirror the thinking behind Internal Assessment Criterion A. Command terms and a suggested mark weight are shown so you can practise to standard. At least one asks for a full prose response.

Core

  1. Distinguish (4 marks) – Explain the difference between a functional and a non-functional requirement, giving one original example of each for a library book-borrowing app.

  2. Identify (4 marks) – For a simple canteen pre-order app, write two functional and two non-functional requirements.

  3. Improve (4 marks) – Rewrite these vague wishes as specific, testable requirements: (a) “it should be fast”, (b) “it should be easy to use”.

Extension

  1. Apply (6 marks) – Choose a small problem someone you know actually has. Write three interview questions you would ask them, and explain what each question is trying to find out.

  2. Explain (6 marks) – Explain, using the TELOS framework, three different reasons a technically buildable project might still be judged not worth doing.

Challenge

  1. Discuss (8 marks) – A student says: “I will just start coding and work out the requirements as I go.” Discuss the risks of this approach and the value of gathering requirements first. Reach a reasoned conclusion. (Write in prose.)

Connections

© EduCS.me — A resource hub for Computer Science education

This site uses Just the Docs, a documentation theme for Jekyll.