Skip to main content
ScotlandComputer ScienceSyllabus dot point

What are the stages of the software development process and what happens at each one?

The iterative software development process: analysis, design, implementation, testing, documentation and evaluation, and why the process is iterative rather than strictly linear.

An SQA National 5 Computing Science answer on the software development process, covering the six stages of analysis, design, implementation, testing, documentation and evaluation, what is produced at each stage, and why the process is iterative so that developers loop back to earlier stages when problems are found.

Generated by Claude Opus 4.89 min answer

Reviewed by: AI editorial process; not yet individually human-reviewed

Have a quick question? Jump to the Q&A page

Jump to a section
  1. What this key area is asking
  2. The six stages
  3. Why the process is iterative
  4. What each stage produces
  5. How this key area is examined
  6. For the official course specification

What this key area is asking

The SQA wants you to know the stages of the software development process, describe what a developer does and produces at each stage, and explain why the process is iterative rather than a single straight line from start to finish.

The six stages

A program is not written in one go from a blank screen. The SQA describes a structured process so that the finished software actually solves the right problem and works reliably.

1. Analysis
The developer works out exactly what the program has to do before writing anything. The output is a clear description of the purpose (what the program is for), the scope and boundaries (what it will and will not do), and the functional requirements (the specific inputs, processes and outputs the program must provide). Getting analysis right matters because a misunderstanding here is expensive to fix later.
2. Design
The developer plans how the program will meet the requirements. This produces design documents such as a structure diagram or flowchart showing how the problem breaks into parts, pseudocode describing the algorithm, and a wireframe sketching the user interface. Design turns "what" into a concrete plan a programmer can follow.
3. Implementation
The developer writes the program code in a high-level language, translating the design into computational constructs (variables, selection, iteration and so on). This is the stage where the design actually becomes a running program.
4. Testing
The developer runs the program with carefully chosen test data to check it works correctly and to find errors. Testing uses normal, extreme and exceptional data and checks the program against every functional requirement from analysis.
5. Documentation
The developer produces the written material that supports the software: a user guide that explains how to install and use it, and technical documentation that records how the program works for anyone who has to maintain it later.
6. Evaluation
The developer judges the finished program. The central question is fitness for purpose (does it do everything the requirements asked for?), along with efficiency, robustness and readability of the code.

Why the process is iterative

Two everyday examples make this concrete. If testing reveals that the program crashes on certain input, the developer goes back to implementation to correct the code, then tests again. If, during design, the developer realises a requirement was never properly understood, they go back to analysis to clarify it. Looping back early is far cheaper than discovering a misunderstanding only after the whole program is written.

What each stage produces

It is easy to confuse the stages, so it helps to remember the single key output of each. Analysis produces a requirements specification. Design produces a plan (structure diagram, pseudocode, wireframe). Implementation produces program code. Testing produces a test report showing the results of the test data. Documentation produces a user guide and technical documentation. Evaluation produces a judgement of how well the software meets its purpose. If a question asks what is produced at a stage, name that output rather than restating the stage's name.

How this key area is examined

Questions ask you to name the stages in order, describe what happens at a named stage, state what a stage produces, or explain why the process is iterative. Marks are lost by giving the stage name without saying what the developer actually does or produces. Learn the six stages as a list, learn one sentence of activity for each, and learn one example of looping back, and you can answer almost any question on this key area.

For the official course specification

The SQA publishes the full National 5 Computing Science course specification, specimen question papers and coursework tasks at sqa.org.uk. Always revise from the current specification and SQA past papers, because question style and terminology are board-specific.

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 N5 style4 marksDescribe what happens during the analysis stage and the testing stage of the software development process.
Show worked answer →

Two stages, two marks each, so make two clear points about each.

Analysis: the developer works out exactly what the program must do. The output of analysis is a clear statement of the purpose, scope and boundaries of the problem and the functional requirements (the inputs, processes and outputs the finished program must provide).

Testing: the developer runs the program with carefully chosen test data to check it works and to find errors. Good answers add that testing uses normal, extreme and exceptional test data and aims to confirm the program meets its functional requirements.

Markers reward naming the right activity for each stage and saying what is produced or checked, not just listing the stage name.

SQA N5 style2 marksExplain why the software development process is described as iterative.
Show worked answer →

Two marks for two linked points.

It is iterative because developers do not complete every stage once and move on; when a problem is found at a later stage they go back to an earlier stage to fix it. For example, an error found during testing sends the developer back to implementation, or a misunderstood requirement found during design sends them back to analysis.

A strong answer states the idea (looping back to earlier stages) and gives one concrete example of looping back, which is what the marker is looking for.

Related dot points

Sources & how we know this