Describe the solution

What you'll learn

• How to explain and justify the structure of a proposed software solution.
• How to describe the solution using algorithms that fit together as a complete design.
• How to include sensible usability features for the intended users.
• How to identify key variables, data structures, classes and validation before coding.

The purpose of “describe the solution”

In the Programming Project, you are not just expected to build a program. You need to show that you can design it carefully before development starts.

This section is about explaining what your solution will be like, how its parts will work, and why your choices are suitable for the problem.

A strong design is not a vague list of features. It should connect back to the problem you analysed earlier. If your analysis says the user needs to search, sort, save data, log in, or generate reports, your design should show exactly how those needs will be met.

Starting point: requirements and success criteria

Before describing the solution, you need two things from the earlier analysis stage:

• Requirements: what the system must do.
• Success criteria: measurable statements used to judge whether the solution works.

For example, a requirement might be “the system must allow a teacher to record student quiz scores”. A success criterion might be “the system stores each quiz score with the student name, date and topic, and allows the teacher to view scores by student”.

Your design should be traceable. That means someone should be able to look at a requirement and find the matching part of your design.

A simple traceability approach

A useful sentence pattern is:

To meet requirement X, the solution will use Y, because Z.

For example:

To meet the requirement to view scores by student, the solution will include a search algorithm that filters stored quiz records by student ID, because names may not be unique and IDs give a reliable lookup value.

Explaining and justifying the structure

A good structure makes the solution easier to build, test, maintain and explain. In A-Level terms, you are showing decomposition.

For a procedural solution, you might structure the program as menus and subroutines, such as:

• displayMenu()
• addScore()
• searchScores()
• calculateAverage()
• saveScores()

For an object-oriented solution, you might structure the program using classes, such as:

• Student
• QuizScore
• ScoreManager
• UserInterface

Neither approach is automatically better. The better choice is the one you can justify for your problem.

What to include when describing structure

You should explain:

• the main sections or modules of the program
• how users move between screens or menus
• how data moves through the system
• which parts handle input, processing, output and storage
• how the parts work together as one complete solution

Describing the parts using algorithms

In this section, you should not just say “the program will search the data”. You should describe the algorithm that performs the search. This can be done using OCR-style pseudocode, flowcharts, structured English, or diagrams, but pseudocode is often the clearest.

An algorithm description should make clear:

• the inputs it receives
• the processing it performs
• the outputs it produces
• any selection, iteration or validation used
• how it links to other algorithms or modules

OCR-style pseudocode example

Here is a small design-level algorithm for adding a quiz score. It is not full production code, but it is precise enough to show the intended logic.

procedure addScore(byRef scores[], byVal studentID, byVal topic, byVal score)
    if studentID.length == 0 then
        print("Student ID required")
    elseif score < 0 OR score > 100 then
        print("Score must be between 0 and 100")
    else
        scores.append(studentID + "," + topic + "," + score)
        print("Score added")
    endif
endprocedure

This shows validation, storage and feedback. In a real design, you would also explain where scores[] comes from and how it is saved.

Describing usability features

Usability is not decoration. It affects whether the solution actually solves the user’s problem.

For OCR H446, useful usability features might include:

• clear menus or navigation
• consistent button names and screen layout
• meaningful error messages
• input prompts that show the expected format
• confirmation messages after saving, deleting or submitting
• prevention of invalid actions where possible
• accessibility features, such as readable text and keyboard-friendly navigation
• help text or instructions for unfamiliar tasks

The key is to justify features for the actual user. A system for a teacher entering marks during a busy lesson needs speed and clarity. A system for younger pupils may need simpler wording and more guidance.

Identifying variables and data structures

A design should identify important variables, especially those linked to input, processing and output. You do not need to list every temporary counter, but you should identify the key data items.

Examples might include:

• studentID
• studentName
• topic
• score
• searchID
• averageScore

You should also choose suitable data types. For example, a score out of 100 might be an integer, while a student name would be a string.

Common choices include:

• a 1D array for a simple list of values
• a 2D array for rows and columns of related values
• a file for persistent storage
• a class with attributes for object-oriented designs

For larger or more complex projects, classes are often clearer than parallel arrays, because each object can keep related data together.

For example, a Student class might store studentID, name and yearGroup. A QuizScore class might store studentID, topic, score and date.

Justifying data choices

Good justifications refer to the operations the program must perform.

For example:

• Use studentID rather than studentName as the key field because two students may have the same name.
• Use an array of score records because the program needs to iterate through multiple scores when searching and calculating averages.
• Use a class for Booking because each booking has several related attributes, such as date, time, court and customer name.

Identifying validation

Validation does not prove the data is true. It only reduces the chance of invalid data entering the system.

Useful validation checks include:

• presence check: data has been entered
• range check: number is within allowed limits
• type check: data is the expected type
• length check: data has an allowed number of characters
• format check: data matches a required pattern
• lookup check: data exists in an allowed list

Pulling it all together

A strong “describe the solution” section usually includes:

• an overview of the whole system
• a breakdown into modules, screens, subroutines or classes
• algorithms for the main processes
• an explanation of how the algorithms connect
• usability features linked to the target users
• key variables, data structures and classes
• validation rules for important inputs
• justifications linked to requirements and success criteria