A requirement is something the brief states and a marker can check. A preference is a choice the software or you make that the brief does not mention. You decide which is which before you start, because requirements get done first and checked last.
This lesson follows locating features in your software: once you can find any feature, you must choose which ones matter.
How do you tell them apart?
Ask three questions of every item.
- Is it written in the brief? If yes, it is a requirement.
- Does it have a specific value, name or place? Exact filenames, orientation, text size and header wording are all requirements.
- Could a marker check it from your files? If yes, treat it as a requirement even when the wording is short.
Everything else is a preference. Default theme, toolbar layout, window arrangement and colour scheme are preferences unless the brief names them.
Worked example
Invented brief for Sunrise Youth Club (fictional):
“Create a one-page newsletter. Use landscape orientation. Put the text
Newsletter 5in the header and your candidate number in the footer on the right. Body text must be 12 point. Save asnewsletter_5.pdf.”
A student lists everything they plan to do:
| Item | Requirement or preference? | Reason |
|---|---|---|
| Landscape orientation | Requirement | Stated |
Header text Newsletter 5 | Requirement | Exact wording given |
| Candidate number, footer right | Requirement | Place given |
| Body text 12 point | Requirement | Value given |
Filename newsletter_5.pdf | Requirement | Exact name and type |
| Blue colour theme | Preference | Not in brief |
| Dark mode on the program | Preference | Not in brief |
| Rounded corners on shapes | Preference | Not in brief |
That is 5 requirements and 3 preferences, 8 items in total. The 5 requirements go first in the checklist.
The mistake to watch for
A common slip is to treat a preference as the main job and run out of time for a requirement.
Mistaken approach: the student spends most of the session choosing a colour theme and arranging toolbars. The footer with the candidate number is never added.
The software made the preferences visible and easy to change, which made them feel important.
The correction is to write the requirements into the checklist first and tick them off before touching anything optional. Preferences come last, and only if they keep the work clear and consistent.
Check yourself
1. Brief: “Use a table with a header row in bold.” Is bold header a requirement or preference? Is the table border style?
Show answer
The bold header row is a requirement, because the brief states it. The border style is a preference, because the brief does not mention it.
2. Your software’s default page is portrait. The brief says landscape. What should you do?
Show answer
Change the page to landscape. The brief is a requirement; the default is only the program’s starting choice.
3. A brief lists 6 stated items. You also add 2 style choices of your own. How many requirements and how many preferences?
Show answer
6 requirements and 2 preferences, 8 items in total.
Where this leads next
After deciding what the brief demands, you must prove you delivered it. That is reopening exported files to verify content. The ICT practical task and evidence checker shows software-neutral acceptance criteria you can compare against your own list.
Students who handle the software well but lose marks to missed instructions can see online one-to-one ICT tuition, where a teacher goes through your work against the brief line by line.