Improvements

Suggested Improvements

The final section of your Internal Assessment (IA) computational solution is Criterion E, which asks you to reflect critically on your completed project and suggest meaningful improvements. This is not simply a list of features you did not have time to implement - it is a structured, analytical evaluation of your solution's current limitations and a thoughtful discussion of how those limitations could realistically be addressed.

Criterion E is worth up to 4 marks at both SL and HL, making it a significant contributor to your overall IA score. Examiners are looking for evidence that you can evaluate your own work objectively, identify genuine weaknesses, and propose improvements that are technically grounded and relevant to your client's needs.

What Makes a Strong Suggested Improvement?

A strong improvement is specific, justified, and connected to evidence from your testing or client feedback. Vague statements such as "I would make the interface look nicer" or "I would add more features" do not demonstrate analytical thinking. Instead, each improvement should follow a clear pattern: identify the limitation, explain why it is a limitation, and describe precisely how you would address it.

Each suggestion should also be feasible - that is, it should be something that could realistically be implemented with reasonable time and resources. Proposing to rebuild your solution using artificial intelligence or distributed cloud computing, without any technical justification, will not impress an examiner. Your improvements must reflect genuine understanding of the technologies involved.

Categories of Improvement

It helps to organise your improvements into categories, ensuring you cover a range of perspectives rather than focusing solely on one aspect of the solution. Consider the following areas when planning your response:

  • Functionality: Features that were planned but not implemented, or features that could enhance the solution's usefulness for the client (e.g. adding a search function to a database application, or enabling data export to a spreadsheet format).
  • Efficiency: Improvements to how the solution processes data or uses system resources (e.g. optimising a sorting routine that is currently slow with large datasets, or reducing redundant file reads).

How Many Improvements Should You Include?

The IB mark scheme does not specify an exact number, but most high-scoring responses include three to five well-developed suggestions. It is far better to discuss three improvements in depth - explaining the limitation, its impact on the client, and a specific technical solution - than to list ten improvements with only a single sentence each. Quality and depth are rewarded over quantity.

Linking to Your Client and Success Criteria

Where possible, connect your suggested improvements back to your original success criteria (from Criterion A) and your client's stated needs. If a success criterion was only partially met, your improvement should directly address that gap. This demonstrates coherence across your IA and shows the examiner that your evaluation is grounded in the real-world context of your project, rather than being generic reflection.

Deep Dive: Writing an Effective Improvement

Consider the following structure when writing each improvement. This approach ensures you cover all the elements an examiner is looking for and avoids superficial responses.

Example of a weak improvement:

"I would improve the user interface to make it look better and add more features that the user might want."

This is vague, does not identify a specific limitation, offers no technical detail, and is not linked to the client's needs. It would receive minimal or no credit.

Example of a strong improvement:

"During testing, the client noted that the stock lookup function becomes noticeably slow when the inventory file contains more than 500 records, as the current implementation performs a linear search through every record. A significant improvement would be to replace this with a binary search algorithm, which would reduce the average search time from O(n) to O(log n). This would require the inventory data to be stored in a sorted order by product code, which is already consistent with how the client organises their stock. Implementing this change would directly address success criterion 3, which required that searches complete within two seconds for files of up to 1,000 records."

This should some form of 'design considerations' such as: an updated pseudocode algorithm, changes to the database, screen layout, etc.

This response identifies a specific limitation, explains its cause, proposes a technically sound solution, and links it to the success criteria.

Recommended structure for each improvement:

  1. State the limitation: What does the current solution not do well, or what is missing?
  2. Justify why it is a limitation: How does it affect the user experience? Refer to testing evidence or (client) feedback where possible.
  3. Propose a specific solution: Describe precisely what you would change or add, including any relevant technical details. Importantly, you should include 'Design considerations'. This means you should include elements such as changes to: 1. Screen designs, 2. Database structure, 3. Algorithms. These do not need to be as detailed as Criterion C, but they should be highly thoughtful - after all, these marks are not a giveaway.
  4. Connect to the broader context: Link back to success criteria, (client) needs, or the original problem statement.

 Key Takeaways

  • Criterion E requires analytical reflection, not simply a wishlist of extra features - every improvement must be justified.
  • Each improvement should identify a specific limitation, explain its impact, and propose a technically grounded solution.
  • Organise improvements across different categories: functionality, efficiency, usability, robustness, and maintainability.
  • 2 to 3 well-developed improvements will score higher than a long list of vague or superficial suggestions.
  • Always link improvements back to your original success criteria and (client) needs to demonstrate coherence across your IA.
  • Evidence from testing and (client) feedback strengthens the justification for each proposed improvement.