Research the problem — OCR A-Level Computer Science

Researching the problem is the first stage of the project lifecycle in the OCR A-Level Computer Science NEA (Non-Exam Assessment). It involves identifying a real-world problem that can be solved with a computational solution, gathering requirements from stakeholders, and defining the scope of the project. This stage is critical because a poorly researched problem leads to an ill-defined solution, wasting time and effort later. You must demonstrate that you have a genuine end-user (not yourself) and that the problem is complex enough to warrant a computer-based solution.

During this phase, you will conduct interviews, questionnaires, or observations to understand the current system's limitations and the user's needs. You'll produce a problem definition, a list of measurable objectives (success criteria), and evidence of stakeholder communication. This sets the foundation for the entire project: design, development, testing, and evaluation. Examiners look for clear justification of why the problem is suitable and how your solution will improve the situation. Without thorough research, your project risks being too simple or irrelevant.

• →Stakeholder identification: You must have a real end-user (e.g., a teacher, small business owner) who will use your solution. Avoid using yourself or a family member as the sole stakeholder.
• →Requirements gathering: Use methods like interviews, questionnaires, or observation to collect both functional and non-functional requirements. Record evidence (e.g., signed consent forms, interview transcripts).
• →Problem definition: Write a clear, concise statement of the problem, including the current system's drawbacks and the desired outcomes. This should be agreed with the stakeholder.
• →Success criteria: Define measurable objectives that your solution must achieve (e.g., 'Reduce data entry time by 50%'). These will later be used for testing and evaluation.
• →Feasibility study: Consider technical, economic, legal, and time constraints. Justify why a computer-based solution is appropriate and achievable.

• Researching the problem and existing solutions to similar problems.
• Identifying and justifying suitable approaches based on research.
• Describing the essential features of the proposed computational solution with justifications.
• Explaining the limitations of the proposed solution with justifications.

• 💡Ensure the research is in-depth and directly informs the design of the solution.
• 💡Use clear justifications for every major decision made during the research phase.
• 💡Ensure the problem chosen is non-trivial and allows for a substantial coded element.
• 💡Focus on the command words in the assessment criteria to drive the depth of the evidence provided.
• 💡Tip 1: Provide concrete evidence of stakeholder interaction. Include signed meeting notes, interview transcripts, or questionnaire responses in your appendix. This proves the problem is real and you've gathered genuine requirements.
• 💡Tip 2: Make your success criteria SMART (Specific, Measurable, Achievable, Relevant, Time-bound). For example, 'The system must process 100 records in under 2 seconds' is better than 'The system should be fast'.
• 💡Tip 3: Justify why the problem is suitable for an A-Level project. Explain the computational thinking involved (e.g., decomposition, pattern recognition) and why a manual solution is inadequate.

• Failing to justify the chosen approach based on the research conducted.
• Providing a superficial description of the solution features without explaining why they were chosen.
• Neglecting to identify or explain the limitations of the proposed solution.
• Choosing a problem that is too trivial to allow for the demonstration of required skills.
• Misconception: The problem can be something simple like 'a to-do list app'. Correction: The problem must be complex enough to demonstrate a range of skills (e.g., database, algorithms, user interface). A to-do list is too trivial for A-Level.
• Misconception: You can invent a problem without consulting a real user. Correction: The NEA requires evidence of stakeholder communication. Without a real end-user, you lose marks for authenticity and requirements gathering.
• Misconception: Research is just a formality before coding. Correction: The research stage directly influences your design. Skipping it leads to vague objectives and a solution that doesn't meet user needs.