How expert witnesses assess software requirements as evidence in IT disputes: disclosure surfaces, recurring failure patterns, the standard of care, and what good documentation looks like under CPR Part 35.
In a software dispute, the requirements documentation is almost always the first place I look. It sits at three layers of the matter at once: the contract layer (what was specified), the specification layer (what the engineering team was meant to build), and the acceptance layer (how completion was to be judged). Anything that turns on whether the supplier delivered what the client asked for runs through these documents.
That places requirements artefacts at the centre of the technical case. When a project has gone wrong and a solicitor begins working out where the breaches sit, the requirements are where the answer tends to live, whether the answer favours the claimant or the defendant. The functional gap that produced the production incident is either visible in the specification or it isn’t. So is the non-functional shortfall the system was tested against. So is the change that turned a delivered system into a missed-deadline disaster, the kind of outcome a failed project assessment exists to untangle.
The complication is that most requirements documentation was written for delivery, not for evidence. The team writing user stories during a sprint isn’t thinking about disclosure. The practitioner capturing acceptance criteria isn’t writing for cross-examination. When the matter reaches the point where these artefacts have to support a position under CPR Part 35, the test they are now being asked to pass is one they were never designed for.
This guide is about that gap. It sets out how I assess requirements as evidence in a UK software dispute: the surfaces I examine, the patterns of strength and weakness I see, and what good documentation looks like under scrutiny.
What Requirements Are, in Litigation Terms
Requirements appear in software projects under several names. There are functional requirements (what the system must do) and non-functional requirements (the qualities it must exhibit, such as performance, security, and availability). There are user stories on a backlog, use cases written up in a specification, formal software requirements specifications produced under an SRS template, and the bodies-of-knowledge taxonomies set out in BABOK and SWEBOK that name the disciplines around them.
For the project, the choice of format matters. A team operating in agile sprints documents requirements differently from one delivering a fixed-scope waterfall contract. I have watched the agile-versus-waterfall argument go round for the best part of two decades, and reasonable practitioners disagree.
For the dispute, the choice of format matters less than people often expect. The forensic question is not “agile or waterfall?” It is whether the discipline of specification was adequate to what the dispute now requires those specifications to evidence. A backlog of well-written, well-tracked user stories with clear acceptance criteria can carry the same evidential weight as a formal SRS. A loose SRS that nobody updated and nobody signed off carries less weight than a tightly maintained agile backlog. The format is downstream of the discipline.
In my experience, this distinction matters in two practical ways for a solicitor assessing the case. The first is that an allegation framed as “they didn’t write proper requirements” rarely survives contact with an opposing expert if the framing is methodology-specific. The opposing expert will say the supplier’s chosen methodology doesn’t produce documents of the kind the claimant expected, and the argument collapses into a debate about whether the methodology was appropriate. The second is that an allegation framed in terms of specification discipline (what was specified, with what precision, how acceptance was defined, how change was tracked) applies regardless of methodology. It can be evaluated against what a reasonably competent engineering team would have produced under comparable constraints, as set out in the instructing solicitor’s guide.
The methodology question is a layer above the dispute. The discipline question is where the dispute lives.
How Requirements Become Evidence
When I am instructed in a software dispute, the disclosure bundle from the requirements side typically falls into six categories. None of them was designed for me, but each carries part of the evidential story.
The contract and statement of work. What was contractually specified, in the document the parties signed. Sometimes this is detailed; more often it incorporates a separate specification by reference. The first task is to follow the references and confirm what actually counts as the contracted requirements.
The requirements register or backlog. Whatever artefact the delivery team used to track work as it happened. A Jira backlog with epics, stories, and acceptance criteria. A spreadsheet of numbered requirements. A Confluence space. The format varies; what matters is whether the artefact records what was specified, who specified it, and when.
Change records and supplementary specifications. Requirements rarely survive a project unmodified. The question is whether changes were captured (in a change log, in revised specifications, in updated tickets) or whether they happened in conversation and only later resurfaced in dispute.
Acceptance criteria and acceptance test artefacts. How “done” was defined for each requirement, and what was done to verify it. Acceptance criteria written into stories; UAT scripts; signed-off test results; pass and fail summaries from the test phase. These bridge from specification to delivery.
Production behaviour and incident reports. What the system actually did once deployed. Incident tickets, support reports, monitoring alerts, post-mortem write-ups. When a claim turns on a specific failure mode, this layer evidences what went wrong against what was specified to happen.
The conversational trail. Emails, Teams messages, meeting minutes, design notes, slide decks attached to invitations. Much of the real specification work in a modern project happens in conversation, and the conversational trail is often where the missing context lives.
The specifics that follow are illustrative composites drawn from typical engagements. In one matter, the only artefact captured in the formal specification was a one-line requirement for “an export function.” The detail of what fields the export needed, in what format, with what frequency, was spread across seventeen emails, a Teams chat, and a verbal agreement at a steering committee, recovered for disclosure only by working through three years of mailbox archives. The export was the dispute. The requirement was a sentence.
That distance between what the contract documented and what the parties had actually agreed is the work the evidence has to bridge.
Patterns of Requirements Failure in Disputes
Across the engagements I have worked on, the failures in requirements documentation tend to fall into recurring patterns. Each shows up differently in disclosure, and each carries a different evidential weight in argument.
Functional gaps. The thing the dispute now turns on was not specified at all. Found by working backward from the production incident, the customer complaint, or the missed acceptance criterion, and noting the absence in the specification. In the export example above, the requirement existed in principle but was so thin that almost every detail of how the export should behave fell into a functional gap. Functional gaps tend to be the clearest evidential pattern: what isn’t written is straightforwardly not written.
Non-functional gaps. The functional capability was specified, but the qualities the system needed to exhibit (performance, security, reliability, scalability, usability, maintainability) were not, or were specified in language that could not be tested. “The system shall be fast” is the canonical example, but the same pattern appears in “easy to use,” “secure,” “robust,” and “available.” When the live system fails on a non-functional dimension and the specification did not set a testable bar, the breach allegation has to bridge a gap the documents themselves leave open.
Acceptance ambiguity. Requirements were written, but in language no one could fairly test for breach. The system shall be intuitive to operate. The reports shall be commercially useful. These are not requirements in any forensic sense; they are aspirations. They cannot decide who was right when the system was rejected as unsatisfactory. In disputes where acceptance was contested, the acceptance language is often the first place the case becomes hard to argue from either side.
Documentation drift. The project produced requirements documentation, but the documentation drifted out of sync with the actual specification work. Multiple versions of the same requirement in different artefacts, with different acceptance criteria. Stories closed against an early version when the team had moved to a later one. A signed-off SRS that the backlog had quietly diverged from over six months. In drift cases, the dispute is less about what was specified and more about which specification we hold the parties to.
The supplier’s duty to flag. Where the requirement, as written by the client, was unsafe, unworkable, or ambiguous, and the supplier, as a reasonably competent engineering supplier, should have raised it. The supplier’s defence of “we built what they asked for” runs into the question of whether asking, in those terms, ought to have prompted a flag. Industry-standard practice expects suppliers to challenge requirements they recognise as problematic. Where the trail shows the supplier silently proceeded, the standard-of-care argument is in play.
Verbal agreement gaps. The specification existed, but in conversation. A meeting where the steering committee agreed that two systems would integrate, with no follow-up specification. A phone call confirming that a deadline was movable, never written down. A decision in a Teams huddle that became the de facto requirement. Verbal agreement gaps are the hardest disputes to evidence on either side: the claimant has to prove what was agreed in the absence of documentation, and the defendant has to defend a position that may contradict what witnesses recall.
These six patterns are not mutually exclusive. A single dispute often shows three or four of them stacked together. The forensic task is to separate them out, name what each one evidences, and assess what weight each carries against the standard the matter is being measured by.
The Standard of Care: Methodology Choice vs Methodology Discipline
The single most contested point in a requirements dispute, in my experience, is whether the supplier’s chosen methodology excuses what is alleged to be inadequate specification. The supplier’s argument, in agile-led projects, often runs along these lines: agile teams do not write detailed up-front requirements, the client knew this when they signed the contract, and what the claimant is now calling a “gap” is simply how agile delivery works. It is a serious-sounding defence and it has won cases.
It should not win on its own merits. The question the standard of care actually asks is not whether the supplier chose a methodology. It is whether the supplier executed that methodology with the discipline a reasonably competent engineering team would have brought to it. The two questions sound similar. They are not.
A team operating in agile sprints can produce well-written, testable, traceable requirements. The artefacts are user stories rather than an SRS, but the discipline of specifying what the system must do, in language that supports a clear test for done, exists in the agile playbook. Teams that take requirements seriously write stories that are concrete, testable, and signed off. Teams that do not produce stories like “user can export data” with no acceptance criteria and a sprint closing date.
The same dichotomy exists in waterfall. A team producing a formal SRS can write it carefully and maintain it, or write it once and never update it. A 200-page SRS that nobody read after week three of the project is not better evidence of specification discipline than a well-curated agile backlog of the same project’s requirements.
The standard of care is methodology-agnostic on this question. What it asks is whether the team specified the work in enough detail that delivered and not-delivered could be distinguished, with quality bars that could be tested, with change tracked as it happened, and with acceptance defensible on the documents. That discipline applies to every methodology that has earned its name.
When I report on a matter in which methodology is in dispute, the strongest position I can hold is the one that does not pick a side. The choice of methodology was the parties’ to make. The discipline of executing that choice is the question the matter actually turns on. The argument is laid out at length in Better Software Requirements, which is the handbook the methodology side of this work draws from.
What Good Requirements Documentation Looks Like Under Scrutiny
The mirror image of the failure patterns is what an expert hopes to find when the requirements stand up well under examination. Across the requirements work I have audited, six characteristics tend to mark documentation a court can usefully rely on.
Specificity. Requirements concrete enough that a competent engineer can test against them. Not “the system shall be fast” but a stated response-time bar for a named operation under stated load. Not “intuitive” but a defined user task with a defined success measure. Specificity does not require formality of language; it requires that the requirement has a determinable answer.
Testability. Each requirement has a way for the parties to agree whether it has been met. For functional requirements, this usually means acceptance criteria that name an input, a precondition, and an expected outcome. For non-functional requirements, it means a quantifiable bar plus a method by which the bar is to be measured. Testability is the property that turns a requirement from an aspiration into something a contract can sensibly reference.
Acceptance trail. Documentation showing who signed off on what, against which version, on which date. Sign-off on a story is a small artefact; in aggregate, a sign-off trail across a project is one of the strongest pieces of evidence the documentation produces. Its absence, or its inconsistency, is often where contested acceptance arguments take root.
Change discipline. Where requirements changed, the changes were captured at the time, attributed to whoever proposed them, reviewed against impact, and agreed by whoever owned the decision. Change records of this kind turn a moving target into one with a documented trajectory.
Risk-flagging. Where a requirement was unsafe or unworkable as written, the supplier flagged it: in a risk register, in a meeting minute, in a written note to the client. The act of flagging is what evidences the supplier discharging the duty to surface issues. Its absence is what makes a “we built what they asked for” defence harder to sustain when the requirement turns out to have been the problem.
Preserved conversational trail. Emails, ticket comments, meeting minutes, design notes preserved in a form that can be retrieved at disclosure. Much of the real specification work happens in conversation; documentation that does not preserve those conversations leaves the parties dependent on memory.
Documentation showing all six is rare. Four or five is creditable — the band most well-run projects sit in. Documentation showing only one or two is usually where the dispute is taking root.