Project Marking as BDD

AssessmentAssessment rubrics for substantial software projects tend to read like exactly the kind of requirement Behaviour-Driven Development was invented to fix: plausible-sounding prose that two different readers can honestly disagree about. "Demonstrates a good understanding of the research context" is a criterion nobody can fail to nod along with and nobody can unambiguously check. BDD's core discipline — turning a vague requirement into a concrete Given/When/Then scenario before anyone starts building ^[1] — applies just as well to turning a vague rubric into a concrete, checkable scenario before anyone starts marking, or writing.

Why Rubric Prose Fails the Same Way Requirements Prose Fails

AA conventional software requirement and a conventional marking descriptor share a structural flaw: both describe a desired quality in language that sounds precise but decomposes, on inspection, into several independent judgement calls bundled into one sentence — the classic ambiguity failure mode requirements-engineering practice has long warned about ^[4]. Compare:

BDD's answer to the requirements version is well established: don't argue about the adjective, write the scenario. The same move works on the marking descriptor.

Turning a Descriptor Into a Scenario

TakeTake the literature-review example above and write it the way a product owner and a developer would negotiate an acceptance criterion — turning an example of what "done" looks like into a concrete Given/When/Then, anchored to something checkable rather than to an adjective ^[2] — the same negotiation a well-run user story goes through before a team commits to building it ^[3]:

Feature: Literature review demonstrates critical evaluation

Scenario: A reviewed source is positioned, not just summarised
  Given a source cited in the literature review
  When the review discusses that source
  Then it states what the source's approach cannot do, or where it
    conflicts with another cited source, or how the current project's
    approach diverges from it
  And a source that is only summarised, with no such statement, does
    not satisfy this scenario

Notice what changed. "Critical evaluation" is still an adjective an examiner ultimately judges — BDD doesn't remove the judgement, any more than it removes a product owner's judgement about whether a feature is actually done. What it removes is the ambiguity about what's being judged: a student reading this scenario before writing the review knows exactly what evidence to leave on the page, and an examiner reading it while marking knows exactly what to look for. The disagreement that's left is about quality, not about scope.

A Second Example: Evaluation, Not Just Description

TheThe same translation works for the other rubric line that routinely produces disappointing marks: an evaluation chapter that presents results without evaluating them.

Feature: Results are evaluated against stated objectives

Scenario: A result is compared to what was promised, not just reported
  Given an objective stated in the Project Initiation Document
  And a result produced during evaluation
  When the report discusses that result
  Then it states explicitly whether the objective was met, partially
    met, or not met, and why
  And a results table with no accompanying judgement against the
    objective does not satisfy this scenario

This scenario also does something the PID discipline earlier in this section of the site depends on: it only makes sense if the objective it refers to was stated precisely enough in the first place. See Writing the Project Initiation Document — a report that can satisfy this scenario is, not coincidentally, a report written against SMART objectives with the numbered On/Dn traceability that page recommends. Vague objectives produce unfalsifiable evaluation chapters for the same underlying reason vague requirements produce unfalsifiable software: there was never a concrete scenario to check against.

Where the Analogy Genuinely Breaks Down

It'sIt's worth being honest about the limits of this framing rather than overselling it:

• There is no test runner. A BDD scenario in software is eventually executed by a machine, which returns a binary verdict. A marking scenario is eventually read by a human, who exercises judgement about whether the evidence on the page is convincing — "states what the source's approach cannot do" still has a quality gradient a rubric level (excellent/good/satisfactory/poor) has to capture separately. The scenario narrows what's being judged; it doesn't automate the judging.
• Overfitting is a real risk. A student who treats the scenario as a literal checklist to tick — one sentence of criticism per source, mechanically inserted — satisfies the letter of the scenario while missing the point, in exactly the way a developer can write code that passes a test's assertions without doing anything useful. A scenario narrows ambiguity; it doesn't replace the need to actually understand the material.
• Not every descriptor is worth this treatment. Writing precise scenarios takes real effort, and a rubric line that's already unambiguous ("all required sections are present") doesn't need it. Reserve the exercise for the descriptors that generate the most disagreement or the most disappointing surprises at marking time.

Using This as a Student, Before You Write

TheThe most direct use of this framing isn't for assessors — it's for you, before you write the section a vague descriptor covers. For any rubric line you're unsure how to satisfy, write your own one-paragraph Given/When/Then for it: given the material you actually have, what would the marker need to read to be able to say the criterion was met? If you can't write that scenario, that's a sign you don't yet know what the section needs to contain — which is worth discovering before the deadline, not after. This is the same acceptance-criteria discipline as the literature review's role in Project Navigation & Triangulation, and it produces exactly the kind of evidence-first writing described in The Report as the Front-End.

References

1. North, D. (2006). "Introducing BDD." Better Software. https://dannorth.net/introducing-bdd/
2. Adzic, G. (2011). Specification by Example: How Successful Teams Deliver the Right Software. Manning Publications.
3. Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley.
4. Wiegers, K. & Beatty, J. (2013). Software Requirements (3rd ed.). Microsoft Press.