Modifying and refining evaluation criteria

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

1. A criterion says 'The program should run fast.' How should it be refined?

A Leave it as it is, because fast is clear enough to judge.

B Reword it to be measurable: 'Search results display in under 2 seconds with 500 records.'

2. When should evaluation criteria be reviewed?

A As the solution develops, so they stay relevant to what is being built.

B Only once, before any development starts, and then never again.

3. The client adds a new feature to the app part-way through development. What should happen to the criteria?

A Keep the original criteria and ignore the new feature.

B Update the criteria to cover the new feature.

4. Which criterion is better after being reworded?

A 'At least 90% of beta testers can add a task without help.'

B 'The app should be easy to use.'

5. Why do we refine unclear evaluation criteria?

A So the solution can be judged using evidence, such as numbers or yes/no results.

B So the criteria are longer and sound more professional.

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

Left column		Right column
1Old: "The app should be fast" → New: "The report loads in under 2 seconds"		AThe refined wording is still vague. 'Quite quickly' has no measurable target such as a time limit, so it cannot be judged.
2Criterion updated after the client added a search feature: "Search returns results in under 3 seconds"		BRewording a vague criterion so it becomes specific and measurable
3A criterion that is too vague should be reworded with a measurable target		CUpdating the criteria after a change so they stay relevant to the solution
4Criteria must be reviewed as the solution develops so they stay relevant after a change in scope		DCriterion "Exports to PDF in under 5 seconds" removed after PDF export was dropped from the project
5Refined criterion: "The program should run quite quickly"		EThe criteria were not updated after the changes, so they no longer match the solution being built and are no longer relevant.
6Criteria written in week 1 and never revisited, even though the client changed the requirements in week 6		F"Easy to use" → "90% of testers finish a booking in under 3 clicks"

Definitions

refine evaluation criteria

Fill in the Blanks

Complete each line of code by filling in the missing parts.

criteria.______("Error rate is below 2%")

criteria[_] = "Search runs in under 2 s"

criteria.______("Looks nice")

__ actual_time <= target_time: print("Criterion met")

for criterion in ________: print(criterion)

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A Revised: Page loads quickly

B Reason: old wording was vague

C Measure: stopwatch on 5 trials

Question 2

A Old: The app is efficient

B Problem: no number to measure

C New: Uses a small amount of RAM

Question 3

A Change: login added in week 3

B Review: criteria miss login

C Action: add a login criterion

D New: Search returns in <= 1 s

Question 4

A criteria = {

B "load_time": "<= 2 s",

C "accuracy": ">= 98%",

D "errors": "Not many errors"

E }

Question 5

A 1. Review criteria each sprint

B 2. Find vague wording

C 3. Delete the criterion

D 4. Record the change

Answer Key

Modifying and refining evaluation criteria

Section A: Quick Questions

B — Reword it to be measurable: 'Search results display in under 2 seconds with 500 records.'

A — As the solution develops, so they stay relevant to what is being built.

B — Update the criteria to cover the new feature.

A — 'At least 90% of beta testers can add a task without help.'

A — So the solution can be judged using evidence, such as numbers or yes/no results.

Section B: Match the Pairs

Old: "The app should be fast" → New: "The report loads in under 2 seconds" → Rewording a vague criterion so it becomes specific and measurable

Criterion updated after the client added a search feature: "Search returns results in under 3 seconds" → Updating the criteria after a change so they stay relevant to the solution

A criterion that is too vague should be reworded with a measurable target → "Easy to use" → "90% of testers finish a booking in under 3 clicks"

Criteria must be reviewed as the solution develops so they stay relevant after a change in scope → Criterion "Exports to PDF in under 5 seconds" removed after PDF export was dropped from the project

Refined criterion: "The program should run quite quickly" → The refined wording is still vague. 'Quite quickly' has no measurable target such as a time limit, so it cannot be judged.

Criteria written in week 1 and never revisited, even though the client changed the requirements in week 6 → The criteria were not updated after the changes, so they no longer match the solution being built and are no longer relevant.

Section C: Definitions

refine evaluation criteria — Review and reword evaluation criteria as the solution develops, so they stay measurable and relevant, such as making vague wording specific or updating them after changes.

Section D: Fill in the Blanks

criteria.append("Error rate is below 2%")

criteria[0] = "Search runs in under 2 s"

criteria.remove("Looks nice")

if actual_time <= target_time:
    print("Criterion met")

for criterion in criteria:
    print(criterion)

Section E: Spot the Error

A — A refined criterion must be measurable. 'Loads quickly' is still vague. It should give a specific target such as 'Page loads in <= 2 s'.

C — Rewording an unclear criterion should add a measurable value. 'A small amount' is vague. It should state a limit such as 'Uses < 50 MB of memory'.

D — After a change, the criteria must be updated to match it. The login feature was added, so the new criterion should measure login, such as 'Login succeeds in <= 3 s'.

D — 'Not many errors' cannot be measured or tested. The criterion should be refined with a number, such as '< 1 per 100 uses'.

C — Refining means rewording unclear criteria so they are measurable, not deleting them. Step 3 should be 'Reword with a number'.