Programmed Solution to a Problem — WJEC A-Level Computer Science Revision

    The investigation phase of the Component 3 non-exam assessment requires candidates to conduct a thorough analysis of a chosen problem to identify stakehold

    Topic Synopsis

    The investigation phase of the Component 3 non-exam assessment requires candidates to conduct a thorough analysis of a chosen problem to identify stakeholder requirements and system limitations. Candidates must research existing solutions, analyze current data flows and processing, and produce a formal working specification with measurable success criteria.

    Key Concepts & Core Principles

    Exam Tips & Revision Strategies

    Common Misconceptions & Mistakes to Avoid

    Examiner Marking Points

    Programmed Solution to a Problem

    WJEC
    A-Level

    The investigation phase of the Component 3 non-exam assessment requires candidates to conduct a thorough analysis of a chosen problem to identify stakeholder requirements and system limitations. Candidates must research existing solutions, analyze current data flows and processing, and produce a formal working specification with measurable success criteria.

    0
    Objectives
    37
    Exam Tips
    37
    Pitfalls
    0
    Key Terms
    53
    Mark Points

    Subtopics in this area

    Investigation
    Discussion
    Design
    Prototype
    Post-prototype refinement of design
    Software development
    Testing
    Evaluation

    Topic Overview

    A programmed solution to a problem is the process of designing, writing, testing, and implementing a computer program to solve a specific real-world or theoretical problem. In the WJEC A-Level Computer Science specification, this topic is central to the coursework component (Non-Exam Assessment) and also appears in the written exams, where students must demonstrate an understanding of the systematic approach to problem-solving. The topic covers the full development lifecycle, from initial problem definition and requirements analysis through to design, coding, testing, and evaluation. It emphasises the importance of a structured methodology, such as the waterfall model or agile approaches, and requires students to apply computational thinking skills—decomposition, pattern recognition, abstraction, and algorithm design—to break down complex problems into manageable steps.

    Mastering this topic is crucial because it forms the backbone of practical programming and software development. Beyond the exam, the ability to create a programmed solution is a fundamental skill in computer science, enabling students to automate tasks, analyse data, and build applications. In the WJEC A-Level, students are expected to produce a substantial piece of code (often in Python, Java, or C#) that solves a problem of their choice, accompanied by a written report documenting the process. This mirrors real-world software engineering practices and prepares students for further study or careers in technology. The topic also reinforces key concepts such as data structures, algorithms, and user interface design, making it a unifying theme across the entire specification.

    Understanding how to approach a programmed solution systematically is not just about writing code; it involves critical thinking, planning, and reflection. Students learn to identify success criteria, choose appropriate algorithms, handle errors gracefully, and test thoroughly. The evaluation phase requires them to consider efficiency, usability, and maintainability—skills that are highly valued in industry. By the end of this topic, students should be able to independently manage a project from inception to completion, documenting each stage clearly and justifying their decisions.

    Key Concepts

    Core ideas you must understand for this topic

    • →The problem-solving lifecycle: analysis, design, implementation, testing, and evaluation. Each stage has specific deliverables, such as a requirements specification, algorithm designs (flowcharts or pseudocode), annotated code, test plans, and a critical evaluation.
    • →Computational thinking: decomposition (breaking the problem into smaller parts), pattern recognition (identifying similarities with known problems), abstraction (focusing on essential details), and algorithm design (creating step-by-step solutions).
    • →Validation and verification: validation checks that input data is sensible (e.g., range checks, type checks), while verification ensures the program meets its requirements (e.g., through testing against test cases). Both are essential for robust solutions.
    • →Testing strategies: black-box testing (based on specifications, ignoring internal code) and white-box testing (examining code paths). Students must create a test plan covering normal, boundary, and erroneous data, and document results.
    • →Documentation: technical documentation (for developers, including code comments and variable lists) and user documentation (for end-users, including installation guides and help screens). Both are required in the NEA report.

    What You Need to Demonstrate

    Key skills and knowledge for this topic

    • Use of a range of appropriate methods to investigate the existing system
    • Thorough investigation of the current system
    • Extensive desk-based research into existing solutions to similar problems
    • Identification and description of all stakeholders and their requirements
    • Detailed analysis of data collected for input and processing
    • Consideration and explanation of all current system outputs and limitations
    • Production of a working specification summarizing project purpose
    • Technical justification of methods to be used in the solution

    Marking Points

    Key points examiners look for in your answers

    • Use of a range of appropriate methods to investigate the existing system
    • Thorough investigation of the current system
    • Extensive desk-based research into existing solutions to similar problems
    • Identification and description of all stakeholders and their requirements
    • Detailed analysis of data collected for input and processing
    • Consideration and explanation of all current system outputs and limitations
    • Production of a working specification summarizing project purpose
    • Technical justification of methods to be used in the solution
    • Setting of objectives including measurable success criteria
    • Identification of a substantial problem with sufficient scope for A-level assessment
    • Clear description of broad project aims using appropriate technical vocabulary
    • Detailed identification and description of potential limitations of the proposed solution
    • Evidence of considering and incorporating feedback from teachers and peers to refine the project understanding
    • Breakdown of the problem into sub-problems with clear links to project objectives
    • Detailed specification of input and output layouts, reports, and forms
    • Design and documentation of data structures and access methods
    • Definition of validation routines for all data entry
    • Identification of all necessary processing routines
    • Documentation of processing routines using a structured convention such as pseudo-code
    • Clear demonstration of the interconnection between programs and data files
    • Justification of the choice of areas included in the prototype and reasons for omitting others
    • Creation of a comprehensive range of screens and outputs for the chosen areas
    • Functioning system that carries out all chosen processes using realistic data
    • Evaluation of the prototype's functioning and justification of its good features
    • Description of shortcomings and specific suggestions for improvement
    • Obtaining feedback from a competent third party
    • Describing feedback received and explaining its implications for system re-design
    • Re-structuring input and output facilities based on feedback
    • Updating files and data structures to accommodate additional data requirements
    • Describing new relationships between data and processes in the revised design
    • Documenting all processing routines using a recognised convention
    • Providing justification for any feedback suggestions that were discounted
    • Refinement of prototype based on feedback and amended design documentation
    • Production of a functional, finished system suitable for audience and purpose
    • Production of annotated listings to facilitate future maintenance
    • Effective use of programming facilities and tools
    • Well-structured, modular code with appropriate use of local and global variables
    • Use of complex user-defined routines and effective validation/exception handling
    • Documentation of variables and data structures
    • Evidence of a completed user interface
    • Evidence of developmental testing at each stage of the solution's creation
    • Evidence of problems encountered during development and the actions taken to overcome them
    • A comprehensive test plan covering all system functions
    • Use of a wide range of testing methods
    • Use of test data including typical, extreme, and invalid data
    • Annotated test runs with detailed commentaries on outcomes
    • Specific suggestions for system refinement based on testing results
    • Detailed evaluation of the effectiveness of the programming language used
    • Justification of tools and techniques employed during development
    • Comparison of the completed system with similar commercially available systems
    • Identification of successful features and specific suggestions for improving less successful areas
    • Critical description of personal strengths and weaknesses in design and prototyping
    • Description of alternative approaches that would be adopted for similar future problems

    Examiner Tips

    Expert advice for maximising your marks

    • 💡Ensure the chosen problem has sufficient scope to access the full range of marks
    • 💡Use appropriate subject-based technical vocabulary throughout the investigation report
    • 💡Clearly link the investigation findings to the proposed project objectives
    • 💡Document all investigation methods used to provide evidence for the moderator
    • 💡Ensure the working specification is precise and clearly defines the required performance
    • 💡Ensure the chosen problem is substantial enough to allow for the full range of marks across all assessment criteria
    • 💡Maintain a clear record of all discussions and feedback sessions with teachers and peers
    • 💡Use technical language consistently when describing aims and limitations
    • 💡Be prepared to justify why certain feedback was or was not incorporated into the final project plan
    • 💡Ensure all designs are documented using a recognised, consistent convention
    • 💡Explicitly link every design element back to the project objectives identified in the investigation phase
    • 💡Use clear, self-documenting identifiers in your design documentation
    • 💡Ensure the design is detailed enough that a third party could implement the system without further clarification
    • 💡Review the design against the specification to ensure all requirements are covered
    • 💡Ensure the prototype is a working subset of the final system, not just a series of static screenshots.
    • 💡Use realistic data that reflects the actual requirements of the problem to demonstrate functionality.
    • 💡Clearly document the evaluation of the prototype, as this is essential for justifying the subsequent refinement of the design.
    • 💡Discuss the prototype in technical terms with teachers and peers to gather feedback for the next stage.
    • 💡Ensure the feedback is from a 'competent third party' rather than just a peer who lacks technical understanding
    • 💡Maintain a clear audit trail between the prototype evaluation, the feedback received, and the resulting design changes
    • 💡Ensure all revised design documentation is detailed enough for a third party to implement the changes
    • 💡Use formal, recognised conventions (e.g., pseudo-code) for all revised processing routines
    • 💡Ensure the code is fully self-documenting with clear identifiers
    • 💡Use modular programming techniques to improve maintainability
    • 💡Ensure the final system is fully functional and tested against the original success criteria
    • 💡Maintain clear, annotated listings that a third party could follow
    • 💡Ensure the user interface is fit for purpose and matches the design documentation
    • 💡Ensure test data is realistic and covers all possible input scenarios, including boundary values
    • 💡Document every error found during development, even if it seems minor, and explain how it was resolved
    • 💡Use a structured test plan table that maps functions to test data and expected outcomes
    • 💡Ensure all test runs are annotated to explain what is happening and why the result is correct or incorrect
    • 💡Use the testing phase to inform the final evaluation of the system's success
    • 💡Ensure the evaluation is well-structured and clearly expressed
    • 💡Use specialist technical terms with ease and accuracy
    • 💡Ensure the review is error-free and professional in tone
    • 💡Explicitly link the evaluation of the programming language to the specific tools and techniques used in the project
    • 💡Be honest and specific about personal performance rather than providing generic statements
    • 💡In the NEA, ensure your problem is well-defined and scoped appropriately. A problem that is too simple will not allow you to demonstrate higher-level skills, while one that is too complex may be impossible to complete. Aim for a problem that requires at least one complex data structure (e.g., a dictionary, list of objects) and a non-trivial algorithm (e.g., sorting, searching, or recursion).
    • 💡When writing algorithms in exams, use clear, unambiguous pseudocode that matches the style taught in class. Avoid programming-language-specific syntax unless explicitly allowed. Show intermediate steps and consider edge cases—examiners reward thoroughness.
    • 💡For testing, always include a test plan with expected results and actual results. Use a table format and include at least one test for normal, boundary, and erroneous data. In the evaluation, discuss any discrepancies and how they were resolved.

    Common Mistakes

    Pitfalls to avoid in your exam answers

    • Failing to identify all relevant stakeholders
    • Providing superficial analysis of current system limitations
    • Setting vague objectives that lack measurable success criteria
    • Insufficient research into existing solutions to similar problems
    • Lack of technical justification for the chosen methods
    • Choosing a problem that is too trivial or lacks sufficient complexity for A-level
    • Failing to document the feedback received from peers and teachers
    • Neglecting to identify or describe the limitations of the proposed solution
    • Using vague language instead of appropriate subject-based technical vocabulary
    • Failing to justify the breakdown of the problem into sub-problems
    • Incomplete documentation of data structures or access methods
    • Lack of detail in pseudo-code, making it impossible for a third party to implement
    • Insufficient validation routines for data entry
    • Poorly defined relationships between data and processing routines
    • Failing to use realistic data for output and storage
    • Omitting the justification for why certain areas were included or excluded from the prototype
    • Neglecting to evaluate the prototype's performance or identify its shortcomings
    • Producing static mock-ups instead of a functioning system that carries out processes
    • Failing to document the feedback received from third parties
    • Neglecting to update the original design documentation to reflect changes made after prototyping
    • Failing to justify why certain feedback suggestions were not implemented
    • Using informal or non-standard conventions for documenting revised processing routines
    • Failure to refine the prototype based on feedback
    • Inadequate annotation of code listings
    • Poor modularity or over-reliance on global variables
    • Lack of validation or exception handling routines
    • System not meeting the objectives set out in the initial specification
    • Failing to include evidence of testing at each stage of development
    • Using only typical data and omitting extreme or invalid test cases
    • Lack of detailed commentary or justification for the actions taken to fix errors
    • Incomplete test plans that do not cover all system functions
    • Failure to provide annotated test runs that link back to the test plan
    • Providing a superficial description of the programming language rather than an evaluation of its effectiveness
    • Failing to make a meaningful comparison with commercial systems
    • Lack of specific, actionable suggestions for system improvement
    • Vague self-reflection that does not identify specific strengths or weaknesses in performance
    • Failure to use specialist technical vocabulary accurately
    • Misconception: 'Testing only needs to be done at the end of development.' Correction: Testing should be iterative—unit testing during implementation, integration testing as modules are combined, and system testing at the end. Early testing catches bugs sooner and reduces rework.
    • Misconception: 'Pseudocode and flowcharts are optional or can be skipped.' Correction: In the WJEC A-Level, design documentation (including algorithms) is a mandatory part of the NEA and exam questions. They demonstrate logical thinking and are often worth significant marks.
    • Misconception: 'The evaluation is just a summary of what went wrong.' Correction: Evaluation should critically assess the solution against success criteria, discuss limitations, suggest improvements, and reflect on the development process. It is not just a list of bugs.

    Frequently Asked Questions

    Common questions students ask about this topic

    Before You Start

    Prior knowledge that will help with this topic

    • •Basic programming skills in a high-level language (e.g., Python, Java, C#) including variables, selection, iteration, and arrays/lists.
    • •Understanding of data types (integer, real, char, string, Boolean) and simple input/output operations.
    • •Familiarity with flowcharts and pseudocode from GCSE or early A-Level topics.

    Likely Command Words

    How questions on this topic are typically asked

    Describe
    Identify
    Analyse
    Justify
    Explain
    Produce
    Consider
    Refine
    Specify
    Design
    Document
    Create
    Evaluate
    Make
    Obtain
    Demonstrate
    Select
    Dry-run
    Apply
    Compare
    Contrast

    Ready to test yourself?

    Practice questions tailored to this topic

    Related Topics in WJEC A-Level Computer Science

    Programming and System Development

    View Topic

    Computer Architecture, Data, Communication and Applications

    View Topic

    Computer Architecture, Data, Communication and Applications

    View Topic

    Programming and System Development

    View Topic