How do you turn a vague problem into a precise statement of what a program must do?
The analysis stage: identifying the purpose, scope, boundaries and functional requirements of a problem to produce a requirements specification.
An SQA Higher Computing Science answer on the analysis stage of software development, covering the purpose, scope, boundaries and functional requirements that make up a clear software specification.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
Jump to a section
What this key area is asking
The SQA wants you to understand the analysis stage: how a developer turns a loose problem description into a precise, agreed statement of what the software must do. You should be able to identify the purpose, scope, boundaries and functional requirements from a brief and explain why each matters.
Why analysis comes first
If you do not know exactly what a program must do, you cannot design or test it. Analysis produces a requirements specification: the agreed, written statement of what the software will deliver. Every later stage depends on it, and the evaluation at the end judges the software against it.
Purpose
The purpose is a short, clear statement of what the software is for, usually a single sentence. For a school library system the purpose might be: "to record the books a library owns and track which books each pupil has borrowed." The purpose frames everything else and stops the project drifting.
Scope
For the library system, the scope might include issuing and returning books, searching the catalogue and reporting overdue loans, but exclude online payment of fines and a public website. Writing the exclusions down protects both sides.
Boundaries
The boundaries define the limits of the system: where its responsibility ends and a person, a manual process or another system takes over. For the library, the boundary might be that the software records that a book has been borrowed, but the physical handing-over of the book is done by a librarian, and replacement orders are placed in a separate supplier system. Boundaries make clear what is and is not the software's job.
Functional requirements
Good functional requirements are precise enough to design from and to test against. For the library system: "the user can enter a pupil's name and a book's barcode to record a loan"; "the system can list all books that are more than 14 days overdue"; "the user can search for a book by title or author." Each names what goes in, what happens and what comes out.
Examples in context
A poor analysis is one of the most expensive mistakes in software. Real projects have failed because the developer built exactly what was asked but the requirements were wrong - for example a hospital booking system that did not account for cancellations because no one wrote that requirement down. This is why analysts spend time with clients, produce written specifications, and have the client sign them off before any code is written. In agile projects the requirements are captured as short user stories ("As a librarian I want to ...") and refined each iteration, but the principle is the same: agree precisely what is needed.
Try this
Q1. State what a functional requirement describes. [1 mark]
- Cue. A specific, testable thing the program must do (an input, process or output).
Q2. Explain why stating what is out of scope is useful. [2 marks]
- Cue. It prevents scope creep and disputes by recording features the client agreed are not included.
Q3. Why is the requirements specification important at the evaluation stage? [1 mark]
- Cue. The finished software is judged (tested and evaluated) against it to check it is fit for purpose.
Exam-style practice questions
Practice questions written in the style of SQA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
SQA Higher (style)4 marksA sports club wants a program to record members and the fees they have paid. From this brief, identify the purpose of the program and state two functional requirements.Show worked answer →
The purpose is a single sentence saying what the program is for: to record the club's members and track which fees each member has paid.
Two functional requirements (specific things the program must do):
- Allow a new member's details (name, contact details, membership type) to be entered and stored.
- Record a fee payment against a member and report which members still owe fees.
Acceptable alternatives include searching for a member, editing a member's details, or producing a list of unpaid fees. Each must be a precise, testable statement of behaviour, not a vague aim.
Markers reward a clear single-sentence purpose and two specific, testable functional requirements (not restatements of the purpose).
SQA Higher (style)3 marksExplain the difference between the scope and the boundaries of a software project, and give one reason why agreeing them with the client matters.Show worked answer →
The scope sets out what the software will and will not do: the features that are included. For example, a library system's scope might include lending and returning books but exclude online payment.
The boundaries are the limits of the system: where its responsibility ends and something else (another system, a person, or manual work) takes over. For example, the boundary might be that the system records a loan but the physical handing-over of the book is done by staff.
Agreeing scope and boundaries with the client matters because it prevents disputes later: both sides know exactly what is being delivered, so the client cannot reasonably demand extra features that were never agreed, and the developer knows when the job is complete.
Markers reward distinguishing scope (what is included/excluded) from boundaries (the limits of the system) and a valid reason such as avoiding disagreement or scope creep.
Related dot points
- The iterative software development process (analysis, design, implementation, testing, documentation and evaluation) and the difference between the traditional waterfall approach and agile methodologies.
An SQA Higher Computing Science answer on the software development process, covering the seven iterative stages from analysis to maintenance, and the difference between the traditional waterfall model and agile methodologies.
- Design notations used to describe a solution: structure diagrams, flowcharts and pseudocode, and the design of the user interface (wireframes).
An SQA Higher Computing Science answer on design notations, covering structure diagrams, flowcharts and pseudocode for program logic, and wireframes for user-interface design.
- Testing with normal, extreme and exceptional test data; syntax, execution and logic errors; debugging techniques; and evaluating software for fitness for purpose, efficiency, robustness and readability.
An SQA Higher Computing Science answer on testing and evaluation, covering normal, extreme and exceptional test data, the three error types, debugging techniques, and evaluating software for fitness for purpose, efficiency, robustness and readability.
- Computational constructs: assignment and arithmetic, selection with logical operators, fixed and conditional iteration, pre-defined functions, and sub-programs with parameter passing (by value and by reference) and variable scope.
An SQA Higher Computing Science answer on computational constructs, covering assignment and arithmetic, selection with logical operators, fixed and conditional loops, pre-defined functions, sub-programs, parameter passing by value and by reference, and local and global scope.
- Standard algorithms: input validation, running total within a loop, traversing a 1-D array, linear search, counting occurrences, and finding the minimum or maximum.
An SQA Higher Computing Science answer on the standard algorithms, covering input validation, running totals, traversing a 1-D array, linear search, counting occurrences, and finding the minimum or maximum value.