A 12-page checklist of 144 evidence checkpoints, mapped to SWEBOK knowledge areas and named professional standards. Free. No email required.
I built this checklist for the early-stage scoping work that happens before an expert is formally instructed: that period when a solicitor has a software or IT dispute on the desk, a Letter of Claim is on its way out or has just arrived, and the question is whether the technical record is substantive enough to take further. Running through the checklist with a client, or with a paralegal, produces an inventory of what evidence exists, what is missing, and where the technical record bears on the dispute.
The Resources page links through to related guides, including how to assess a failed software project and how to read technical debt as evidence.
Why This Guide Exists
The first question a software expert is asked in a dispute is usually the simplest to state and the hardest to answer cleanly: was professional practice followed?
Answering it cleanly requires a body of knowledge to compare against. Not vague notions of “good practice” or appeals to industry custom, but the standards an experienced engineer would expect to see followed. The checklist is structured around the Software Engineering Body of Knowledge (SWEBOK), the international consensus document on what software engineering as a discipline considers professional practice. SWEBOK is published jointly by the IEEE Computer Society and the ACM, and is updated periodically as the field matures. A longer narrative treatment of the standards landscape is on the industry standards article; the checklist is the operational version.
The eight checklist categories mirror the SWEBOK knowledge areas. Within each, the specific checkpoints are drawn from the standards bodies that cover that area in depth: ISO/IEC/IEEE for software engineering processes and quality, ISTQB for testing terminology and methodology, OWASP for secure development, PRINCE2 for project governance, and GDPR for data-protection compliance.
A note on scope. This is a pre-action scoping tool, not an expert report and not a document intended to be filed. It produces inventory and information-request input: the kind of structured groundwork a solicitor uses to decide whether expert instruction is warranted, and a Letter of Claim drafter uses to target specific information requests. The reasoned opinion a court ultimately needs is the work of an instructed expert under CPR Part 35. The checklist is the upstream evidence-scoping that informs whether that work is ready to commission.
What the Checklist Covers
The checklist covers eight categories across the development lifecycle, mirroring the SWEBOK knowledge areas:
- Requirements engineering and business analysis
- Architecture, design, and technical decisions
- Code quality, version control, and development practices
- Testing, quality assurance, and UAT sign-off
- Deployment, operations, and production monitoring
- Project management, governance, and change control
- Security, compliance, and data protection
- Documentation and knowledge transfer
Within each category, there are 18 specific checkpoints, each phrased as a question about whether evidence of professional practice exists and where it would be found. The document includes columns for recording presence, absence, and evidence location, and a scoring summary that surfaces the pattern of strengths and gaps across categories.
It is designed to be run by a solicitor or paralegal with a client’s input, rather than by a technical specialist. The checkpoint phrasing is plain enough for a non-technical case-handler, and the evidence categories are concrete enough that gaps surface clearly without expert interpretation. Solicitors use it to identify what to request in pre-action correspondence; businesses on either side of a dispute use it to inventory their own position; claims teams use it to triage technical merit before reserving budget.
The format is an editable Microsoft Word document, downloaded directly with no email gate or form submission.
Download the Checklist
Software Standards Assessment Checklist DOCXWord document. Free. No email required.
Reading the Pattern of Gaps
The first time a completed checklist comes back, it is rarely the obvious gaps that matter most. A missing test report or a missing UAT sign-off is easy to spot. Those are the gaps a solicitor would have asked about anyway. The gaps that bear on the dispute, in my experience, are usually subtler than that.
A version-control record that is sparse or absent across the disputed period is one. Real development leaves a granular trace: commits frequent and incremental, messages describing what changed and why, branches reflecting iterative refinement. When the checklist surfaces gaps in this category, with no commit history, no branch policy, and no author attribution, it points to a specific request for the full Git history covering the relevant window. That request lands well in pre-action correspondence under CPR Part 18 because the format is specific and the relevance is concrete.
A requirements record with no traceability between scope decisions and the artefacts that record them is another. The lifecycle expects requirements to be versioned, scope changes to be recorded against a change-control mechanism, and acceptance criteria to be agreed and dated, which is where a forensic reading of requirements records begins. When the checklist shows gaps here clustered around late-phase scope decisions, the implied information request is for the change-control log and the related scope-variation records. Where those exist, they tell the story of how the project’s commitments evolved. Where they do not, that absence is itself evidentially significant.
A test record that names what was tested but not how rigorously is a third example. The relevant question for a dispute is not whether testing happened (almost every project will show some testing), but whether the testing performed was professionally proportionate to the system being delivered. When the checklist shows that ISTQB-style test design (equivalence partitioning, boundary-value analysis, decision-table coverage, traceability to requirements) is absent, the request is for the test plan and the test-execution evidence covering the disputed functionality.
Patterns aggregate. A project with sparse version control, missing change-control records, and test evidence that surfaces only at UAT typically reflects a delivery that was rushed past its own quality assurance, not a project that ran cleanly. The job of the checklist is to make that pattern visible, to take the diffuse feeling of “something went wrong here technically” and convert it into a specific list of things to request, examine, and form expert opinion on.
What the pattern means for the next step is a judgement call, not a formula. If the gaps are minor and the technical record is otherwise substantive, the case may not need expert evidence at all. If the gaps are pervasive and pattern-consistent, expert instruction is usually warranted. The solicitor’s guide to instructing software experts and the failed software project assessment article work through what that next step looks like in practice; the checklist is the structured first input.
Frequently Asked Questions
Do I need technical expertise to use this checklist? No. It is designed to be run by a solicitor, paralegal, or business case-handler, with a client’s input where the answers require it. The phrasing is plain English, and the evidence categories are concrete.
Will the result tell me whether I have a strong case? The checklist identifies what evidence exists and what is missing, in categories that map to recognised professional standards. Whether the gaps add up to a strong case is a judgement call that depends on the contractual position, the specific obligations the supplier assumed, and the proportionality of the dispute. A pattern of pervasive gaps is a signal worth investigating. An isolated gap rarely is.
Can I share the completed checklist with the opposing party? The blank checklist is a general assessment tool and can be shared freely. The completed checklist is an internal scoping document and should not be sent to the other side without legal advice. It may reveal more about the evidential position than is intended to be disclosed at the pre-action stage.
Will a court think a checklist is too reductive a tool to reference? The checklist is a pre-action scoping tool, not an evidence substitute, and not a draft document to be filed in. Its job is to structure the conversation between solicitor, client, and prospective expert before the formal expert work begins. A reasoned expert opinion under CPR Part 35 is what a court eventually needs. The checklist is upstream of that work.