Efficiency, ease of use, appropriateness
Efficiency, ease of use and appropriateness are the three criteria for judging a solution, each needing its own reason (what is good/poor AND why). Efficiency: faster, fewer errors, or lower cost/effort than before, against a resource (time, money, effort). Ease of use: how easily the actual users, not the developer, operate it. Appropriateness: suited to this task and these people? A solution can be efficient and easy to use yet still inappropriate.
Compare against the original requirements
Comparing with the original requirements is a structured check, not a general opinion. Go back to the requirements from the analysis stage (topic 7.1), then take them one at a time, marking whether the solution meets, partly meets, or fails each; where one is missed, say specifically what is missing. A solution can feel efficient and easy to use and still fail this check — a "ten users at once" requirement met by a single-user system is a clear failure.
Limitation, improvement, user responses
Three DISTINCT ideas, kept separate. A limitation is what the solution cannot do, or does poorly, now. An improvement is a specific change fixing a named limitation — "make it better" or "add more features" scores nothing. Evaluating users' responses to testing means interpreting the feedback of real users who tried it, NOT re-checking whether test data (topic 7.3) gave the expected output. A solution can pass every test and still draw negative feedback.
Drawn from real examiner reports.
One-sided, not balanced
"Evaluate" requires positives AND negatives, each backed by a reason — listing only what is good (or only what is bad) is not an evaluation, however much you write. The same applies to "advantage/disadvantage" and "discuss/compare": make a genuine comparison, and do not split the answer into two disconnected columns that stop the two sides being weighed against each other.
Vague judgements score nothing
"The system is good" or "it is easier to use" earns no marks without saying specifically what makes it good — easier than what, for whom, and why. Replace a bare assertion with concrete evidence: not "it is more efficient" but "staff now process an order in under a minute instead of five, because the computer looks up stock levels automatically".
Improvement with no named limitation
State the limitation first, then the matching improvement. An answer that jumps to "add a feature to do X" without first saying what is missing leaves the examiner to guess which weakness is being fixed. A vague improvement — "make it faster", "add more features" — scores nothing; it must name and fix a specific limitation.
User feedback ≠ test-data results
Answering "evaluate users' responses to testing" by re-describing whether the test data produced the expected output confuses two kinds of evidence: that pass/fail check is topic 7.3's. Users' responses are about how real users experienced the solution — what they found hard, confusing or missing — which can be negative even where every test case passed.
General opinion, not requirement check
When comparing the solution with its task requirements, judging it as generally "good" or "efficient" misses the point; each stated requirement must be marked met, partly met, or not met. Strong ease of use does not compensate for a missed requirement: a fast, friendly single-user system still fails a requirement specifying multiple simultaneous users.
Appropriateness needs the scenario
"Appropriate" or "not appropriate" on its own scores nothing — the judgement must link to the specific users, task or constraints described. The same solution can be appropriate in one context and poorly appropriate in another: a cloud-based system suits an office with reliable internet but is inappropriate where the connection frequently drops.
Structure an evaluate answer in four parts
Keep the four elements separate: (1) judge efficiency, ease of use, appropriateness (a reason each); (2) compare with the original requirements; (3) name a limitation, then a matching improvement; (4) interpret what user responses to testing show that a pass/fail test cannot.
Evidence each point, then a balanced verdict
Back every judgement with concrete evidence — a number, a named user group, or a named task. Finish with a short sentence weighing the positives against the negatives: an "evaluate" question is marked on the balance of the judgement, not the volume of description.
Do not mark a requirement met without proof
Only record a requirement as met where the scenario gives evidence it was actually tested or confirmed. If the stem does not say a requirement was tested and worked, you cannot mark it met — state that it is unconfirmed rather than assuming success.
Percentage change uses the original figure
When quoting a percentage efficiency gain, base it on the original figure, not the new one: (new - original) / original, then multiply by 100. E.g. 40 min falling to 25 is (25 - 40) / 40 = -0.375, a 37.5% decrease. Dividing by the new figure is the common error.
Full notes, flashcards, Q&A and the topic quiz for every premium subject.
Premium plans are US$8.99/month or US$49.99/year — first month free.
Studying with a parent's blessing? Show them this.
