A-Level Computer Science / Unit 12: Software Design, Testing and Evolution

12.1.1 From Requirements to a Maintained Program

🔒 Lesson slides are available to signed-in users. Sign in

12.1.1 From Requirements to a Maintained Program

Software development involves much more than writing code. Before programming begins, developers need to understand the problem and plan a suitable solution. After the code has been produced, it must be tested and may continue to change while people use it.

This section follows a program from its first set of requirements to a maintained working system. The different ways in which these stages can be organised are explored in the following subsections.

By the end of this section, you should be able to:

  • Explain why software projects use a development life cycle.
  • Describe analysis, design, coding, testing and maintenance.
  • Identify typical work and evidence produced during each stage.
  • Explain how requirements guide design, coding and testing.
  • Explain why maintenance can lead to another development cycle.

Why Use a Development Life Cycle?

A developer may be able to create a very small program informally. A larger system, however, normally involves more requirements, more data, more code and possibly several people working on different parts of the solution.

A development life cycle divides this work into recognisable stages. This helps the team decide what should happen next, what evidence should be produced and whether the project still meets its original purpose.

Program development life cycle: a structured way of taking software from an identified need through planning, construction, checking and later modification.
Reason for using a life cycle Why it matters
Shared understanding Developers, users and other stakeholders can refer to agreed requirements rather than relying on different assumptions.
Planned work Important decisions about data and algorithms are considered before large amounts of code are written.
Progress checks The outputs from each stage provide evidence that the project is ready to move forward.
Quality control The completed program can be checked against the needs identified at the start of the project.
Controlled change Later faults and new requirements can be investigated before modifications are made.
Common mistake: A development life cycle is not another name for programming. Coding is only one stage within the wider process.

Starting with Requirements

A project begins with a need or problem. The development team must clarify what the proposed software is expected to achieve before deciding how it will be built.

The findings are recorded in a requirements specification. This gives the project a reference point against which designs and completed features can later be checked.

Requirements specification: a documented description of what the proposed system is expected to do and the important conditions it must satisfy.

Example requirements

Consider a proposed booking system for a community makerspace. Its requirements might include the following:

Area Example requirement
Users Registered members must be able to view available equipment.
Processing The system must prevent two bookings for the same machine and time slot.
Rules Restricted equipment may only be reserved by trained members.
Output Staff must be able to produce a list of bookings for a selected day.
Environment The booking interface must work on the tablets used at reception.
Exam tip: Analysis should identify what the system needs to achieve. It should not describe the finished program code.

The Five Core Stages

The syllabus identifies five central stages. Development models organise these stages in different ways, but the purpose of each stage remains broadly consistent.

Stage Central question Typical work Possible evidence or output
Analysis What problem needs to be solved? Investigate the current situation, consult users and clarify the required behaviour. Requirements specification
Design How will the proposed solution work? Plan the algorithms, data, modules, interfaces and other parts of the solution. Pseudocode, diagrams, identifier information and data-structure plans
Coding How will the design be implemented? Translate the design into source code using an appropriate programming language. Source code and executable versions
Testing Does the program behave as required? Run carefully selected tests, compare results with expectations and correct faults. Test results, fault records and corrected code
Maintenance What needs to change after the software enters use? Investigate reported faults, changing conditions and requested improvements. Revised software and change records
Exam tip: When describing a stage, include both its purpose and an appropriate activity. A list containing only the five names is not a full explanation.

Analysis and Design Are Different

Analysis: understand the need

During analysis, the team investigates the problem rather than deciding the detailed solution immediately. Existing procedures may be studied and intended users may be asked what information they need.

Unclear requirements should be resolved at this point. For example, the statement “members should be able to book equipment” is incomplete until questions such as these have been answered:

  • How far in advance may a booking be made?
  • How long may a booking last?
  • Which machines require previous training?
  • Who may cancel or change a booking?

Design: plan the solution

Design begins once the required behaviour is sufficiently clear. The developer now decides how data will be represented and how the algorithms will carry out the required processing.

For the makerspace system, design decisions could include:

  • what data must be stored for each member and each booking;
  • how an available time slot will be identified;
  • which modules will check training status and booking conflicts;
  • how confirmation and error messages will be presented;
  • how booking information will be saved between sessions.
Common mistake: Analysis defines the problem and requirements. Design describes the planned solution. They are related but are not interchangeable.

Coding and Testing

Coding or implementation

During coding, the planned algorithms and data structures are expressed in a programming language. This stage is also commonly called implementation.

Source code: the programming-language instructions written by the developer to implement the design.

Coding should follow the agreed design. Developers may still discover practical problems, but significant changes should be considered carefully because they may affect other modules and requirements.

Testing

Testing checks the program's behaviour against the expected results. It is not enough for the program to start or complete without crashing. It must produce suitable results for the relevant inputs and conditions.

If a test exposes a fault, the developer investigates the cause, corrects the code and repeats appropriate tests. Detailed testing methods and test data are covered later in Unit 12.

Common mistake: Successful execution does not prove that a program meets its requirements. A logic error may still produce a believable but incorrect result.

How the Stages Connect

The stages are connected by the information and evidence they produce. An output from one stage is often needed before work in another stage can be completed confidently.

A useful way to think about this relationship is to trace one requirement through the project.

Stage Example evidence for one requirement How it supports later work
Analysis “The system must reject a booking when the selected machine is already reserved for that time.” Defines the required behaviour.
Design A planned SlotIsAvailable function checks existing reservations. Explains how the requirement will be implemented.
Coding The function and booking validation are written in source code. Creates the executable behaviour.
Testing A second user attempts to reserve an occupied slot and should be rejected. Checks whether the implemented behaviour matches the requirement.
Maintenance The organisation later changes bookings from one-hour slots to 45-minute slots. The rule, design, code and relevant tests must be reconsidered.
A problem found during a later stage may reveal that work from an earlier stage needs revision. The precise pattern of movement depends on the development model being used.

Worked Example: A Requirement Through the Life Cycle

The makerspace owns a laser cutter. Only members with a valid safety certification may reserve it.

Stage Original development decision
Analysis Staff explain that ordinary equipment is open to all members, but a valid certification is required for the laser cutter.
Design Each member record will include certification information. A validation module will check this information before a restricted booking is accepted.
Coding The developer implements the member lookup, equipment restriction and booking-validation logic.
Testing Tests include a certified member, an uncertified member and a booking for unrestricted equipment.
Maintenance Six months later, the organisation decides that certifications must expire after one year. The existing system must be changed.

The maintenance request cannot be handled safely by changing one value without further thought. The team must clarify how expiry dates are recorded, update the design, amend the code and repeat relevant tests.

Exam tip: In scenario questions, connect each action to the correct stage. Avoid vague statements such as “the developers work on the system.”

Maintenance and the Continuing Cycle

Maintenance begins after the software has entered use. Real users may uncover faults, working conditions may change, or the organisation may request improvements.

A small change may be handled by investigating, implementing and testing an update. A much larger change may show that the existing requirements and design are no longer suitable. In that situation, the project may return to analysis and begin another cycle.

Maintenance: controlled modification of software after it has entered use.

The detailed distinctions between corrective, adaptive and perfective maintenance are introduced in Section 12.3.6.

Common mistake: Software does not require maintenance because its physical parts wear out. It requires maintenance because faults, requirements and operating conditions can change.

Interactive: Life-Cycle Explorer

Use the explorer to move through the stages, trace one requirement or examine what happens when a change is requested after release.

Development path

Analysis

Clarify the problem

Investigate the need and agree what the software must achieve.

Step 1 of 5

Think about the stage

What information would the development team need before designing the solution?

Common Mistakes and Misconceptions

  • “The life cycle is just a fixed list.” The stages describe important kinds of work, but development models organise and revisit them differently.
  • “Analysis decides how the code will work.” Analysis identifies the need. Detailed solution planning belongs to design.
  • “Coding and testing are the same.” Coding implements the design; testing checks the resulting behaviour.
  • “A program that runs has passed testing.” It may execute successfully while still producing incorrect results.
  • “Maintenance is the final end point.” A maintenance request can lead back to analysis, design, coding and testing.

Practice

Core questions

  1. Explain one reason why a large software project needs a development life cycle.
  2. State the five core stages in the program development life cycle.
  3. Explain the difference between analysis and design.
  4. Give two examples of evidence that could be produced during design.
  5. Explain why a program must still be tested after it executes successfully.
  6. Describe one reason why software may need maintenance after release.

Apply your understanding

A sports centre wants an application that allows customers to reserve badminton courts. The system must prevent overlapping reservations.

  1. Write one clear requirement for this rule.
  2. Describe one design decision needed to implement the rule.
  3. Describe one suitable test of the completed feature.
  4. The centre later changes all sessions from 60 minutes to 50 minutes. Explain how this change could affect more than one life-cycle stage.
Challenge: Explain why the statement “coding is the most important stage because it produces the program” gives an incomplete view of software development.

Review

Prompt A strong response should include
Purpose of a life cycle A structured process for understanding, planning, implementing, checking and modifying software.
Analysis Investigation of the problem and clarification of requirements.
Design Planning the algorithms, data and organisation of the solution.
Coding Implementing the design as source code.
Testing Comparing actual behaviour with expected behaviour and correcting faults.
Maintenance Modifying software after it has entered use.
Why it forms a cycle Later faults or changes may require renewed analysis, design, coding and testing.
Final exam tip: Use precise verbs: investigate during analysis, plan during design, implement during coding, check during testing and modify during maintenance.