## General comments
### I've already written lots of this
Please take the time to read my advice elsewhere on this site. I didn't write it for fun.
### Tie your work to the mark scheme
Consider structuring your work explicitly around the mark scheme requirements to give yourself a structure with which you can hold yourself accountable to the mark scheme.
To get the top of band 4, you need to meet all the band 4 descriptors. I strongly suggest you write with the mark scheme next to you to keep you focused on meeting the band 4 criteria.
### Use headings
Please use headings and subheadings to make it easy to navigate your work. Walls of text are intimidating.
Consider using headings rooted in the mark scheme language, e.g., 'Stakeholder identification and description,' 'How my stakeholders will use my solution,' and 'Why my solution is appropriate for my stakeholders.'
### Justify based on the project, not the NEA
Don't justify things based on the structure and timescale of the NEA. 'The NEA requires it' is not a suitable justification. Justification should be intrinsic to the project you are working on.
### Referencing
Make sure to include the date you accessed a website if you cite it. See [[Academic honesty]].
## Computational methods
There is a big difference between talking about applying computational methods to the process of completing your NEA compared to the features of the 'problem' you are solving. The mark scheme only rewards the latter.
The fact that you can use abstraction and decomposition as project management tools is irrelevant. What the mark scheme wants is for you to describe the features of the thing you are making that are well-suited to computational approaches.
%%
This is not good:
I can use abstraction to help me plan my project as it allows me to focus on only the things that are important. By using abstraction, I can decide the important things to work on at any given point in time to make sure that I am using my time effectively towards completing my project. I can use abstraction to make sure I don't waste time on features that I don't need, and I can use abstraction to make sure I only write about things in my report that are important.
This is much better:
My game is necessarily an abstracted version of reality—rather than representing every single detail of the real world, my solution only needs to represent the most important details. This is exemplified through my planned character system where every character is abstractly represented as a bundle of stats (health, stamina, etc.) and a 2D image. Details purposefully abstracted out of this representation include realistic simulation of the character's circulatory and respiratory systems which are abstracted to the stamina stat. While realistic simulation of these systems could be useful in some games, they are not relevant in my game as I am creating a top-down farming sim where crop growth is the main point. I will therefore need to include more details for my crop system (e.g., water levels, nitrogen levels) as these details *are* important for my project. Abstraction is necessary for my project as, without it, my game would end up being an entire living organism simulator—which is not the point.
%%
Remember that there are many computational methods covered in the A-level specification. The point of the NEA is to demonstrate mastery of A-level content, not just excellent understanding of GCSE material. A-level computational methods include:
- thinking abstractly;
- thinking ahead;
- thinking procedurally;
- thinking logically;
- thinking concurrently;
- use of divide and conquer;
- backtracking;
- data mining;
- heuristics;
- performance modelling;
- pipelining; and
- visualisation to solve problems.
NB that thinking concurrently is related to parallel processing, i.e., multiple instructions being executed at the same time on a multi-core CPU. Thinking concurrently and parallel processing have nothing to do with the illusion of simultaneous execution provided by fast execution on a single core. Be careful talking about thinking concurrently unless you are actually planning to write a multi-threaded program (which you probably are not).
## Stakeholders
Be wary of misrepresenting your stakeholders. It does not benefit you to lie.
Remember that band 4 requires discussion of how your solution is appropriate to your stakeholders' needs.
## Existing solution research
Remember that the point of your research is evidence to justify 'suitable approaches' for your work. It is not just to show off how much you know about whatever products you picked. The most overlooked part of this section is going beyond commentary on the products you researched to discuss the impact of your research on your project.
## Essential features
Consider numbering them so you can relate them to your success criteria.
The list of essential features is a big picture list of everything that your product should have. I would expect it to be comprehensive.
It can be helpful to have a list of essential features and then a second list of non-essential features. These can directly inform your success criteria.
The lists of essential features were frequently short. Presenting them in a table can be helpful.
| Essential feature \# | Description | Explanation |
| -------------------- | ----------- | ------------------------ |
| 1 | blah blah | [[explain\|explanation]] |
## Limitations
"I don't have time" or "I don't know how" are not appropriate justifications of limitations.
Limitations are features that you have intentionally decided against including. Why did you intentionally decide not to include them?
## Requirements
Requirements should be [[specify|specified]] and [[justify|justified]].
## Success criteria
Frequently, the lists of success criteria were shockingly short and not justified. Remember that your success criteria will be what you use to assess your work in your final evaluation.
Everything you do during design and development should be aimed towards meeting your success criteria. If your success criteria are scant, how are you going to justify your choices during development?
Consider numbering them so you can easily reference them throughout development. One effective way to present your success criteria is in a table.
| Criterion \# | Essential feature \# | Description | Justification |
| ------------ | -------------------- | ----------- | -------------------------- |
| 1 | 1 | blah blah | [[justify\|justification]] |