IT Projects & Technical Due Diligence
A requirements-to-actual-state comparison is meaningful only when the applicable requirement version, implementation state, test evidence and acceptance record belong to the same project baseline. A later document must not be projected backwards onto an earlier build, and a present-day defect does not automatically establish that the same behaviour existed at an earlier acceptance date.
Short answer
Requirements can be distributed across specifications, user stories, tickets, acceptance criteria and change records. The first task is to reconstruct which version was technically applicable to the project state under examination.
The actual state is then fixed through repository revision, build, deployment, configuration and data state. Test and acceptance evidence are interpreted in relation to that state and to the conditions under which the tests were actually performed.
1. Reconstruct the target state from several sources
Requirements need version and time context
Specifications, user stories, tickets, acceptance criteria and change logs can coexist and can conflict. The examination relates them by date, identifier and change history instead of treating the latest document as universally authoritative.
A later wording must not silently be applied to an earlier build. Where possible, the report records requirement versions and the points at which the requirement changed.
Vague quality terms may require operational criteria before they can be tested reproducibly. Performance, security and usability requirements often need measurement rules that differ from a deterministic functional check.
2. Determine the actual technical state unambiguously
The compared implementation must be a concrete state
The actual state should connect repository revision, build artefact, deployment, configuration and relevant data. Mixing a requirement from one date with a different later implementation can produce a technically misleading comparison.
Test, staging and production environments should be distinguished. A passed test in one environment does not automatically establish the behaviour of another if configuration, dependencies or data differ.
Failed or missing tests are part of the project record but are not themselves proof that a requirement was technically violated.
3. Interpret tests and acceptance records
Evidence is conditional on version, environment and procedure
Test cases document what was checked, with which inputs, on which environment and against which expected result. Their technical meaning depends on those conditions.
Acceptance minutes and release approvals can provide important context. The examination asks which build or state they refer to and which checks are actually documented. A formal approval does not replace a technical examination of a later disputed behaviour.
Likewise, an error reproducible today does not by itself establish that the same error existed in the same form at the historical acceptance date.
4. Classify deviations instead of forcing a binary result
Not testable is different from not fulfilled
A structured comparison can distinguish requirement fulfilled, reproducibly not fulfilled, not testable from the available evidence, internally contradictory, or observed only under conditions different from the applicable baseline.
These categories help separate technical findings from project communication and legal interpretation. A missing test environment may make a requirement currently untestable without proving technical non-compliance.
Functional and non-functional requirements may require different evidence. Performance, security or usability should not be evaluated with the same method as a deterministic API response.
5. Include the project history and reasons for revision
Requirement change can invalidate earlier comparisons
Change requests, ticket edits and approvals are included when the target baseline changed. An earlier finding may no longer describe a later implementation after a requirement revision.
A traceable report shows exactly which requirement version, implementation state and test were compared. That allows a third party to reproduce the technical reasoning.
The reconstruction does not automatically decide which party owed a change or whether an acceptance was legally effective.
6. Build a traceability matrix from requirement to implementation and evidence
Existence and strength of evidence should be separate columns
A traceability matrix can list each requirement, its applicable version, related tickets, implementation artefacts, test cases, results and acceptance references. The matrix reveals where the chain is complete and where it breaks.
A passed test supports only the behaviour tested under the documented conditions. An acceptance record may be organisationally relevant without proving that every technical property was tested.
Priority, acceptance criteria and dependencies also matter. A feature can exist while violating a defined boundary condition, performance limit or interface requirement; conversely, an observed variant may be allowed when the valid requirement permits several implementations.
Is the requirements-to-actual-state comparison based on one consistent baseline?
- Is the applicable requirement version identified for the project state in question?
- Are later requirement changes prevented from being projected backwards?
- Is the compared implementation fixed by revision, build, deployment and configuration?
- Are test, staging and production environments distinguished?
- Are test results interpreted only for the documented conditions?
- Are acceptance records tied to a concrete technical state?
- Is 'not testable' distinguished from 'not fulfilled'?
- Does a traceability matrix connect requirement, implementation, test and acceptance evidence?
Constructed example
An original specification describes a feature differently from a later ticket. The productive build implements the ticket wording but not the earlier document. The technical finding first establishes the documented requirement change and the build association.
Which requirement version was contractually binding is not inferred from the software state. The technical reconstruction provides the versioned comparison needed for that separate assessment.
The example is entirely constructed and does not describe a real engagement.
Sources and technical basis
- Technical primary source Git revision model, used for unambiguous reference to development states. Open source.
- Technical specification SLSA provenance, used as a reference for connecting build artefacts to their inputs. Open source.
- Author methodology Sources and Methodology of the German knowledge base. Open source.
- Technical primary source Git documentation: git-log, used for traceable examination of commit histories and changes. Open source.
Further reading
- Reconstructing the History of an IT Project
- Reconstructing Change Requests and Change States
- Reconstructing Test, QA and Release Evidence
- Reconstructing Project Documentation and Decision History
Critical review and methodological limitation
A requirements comparison is only as sound as its version alignment. Later documents, current builds and present-day tests cannot automatically answer a question about an earlier project state.
Technical evidence can show implementation and tested behaviour; it does not by itself decide contractual precedence or the legal effect of acceptance.
- Baseline: requirement and implementation must belong to the same relevant project state.
- Evidence: tests support only the conditions actually exercised.
- Acceptance: an approval record and technical verification are related but distinct sources.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
IT Project Assessments & Project Reconstruction
Traceable reconstruction of requirements, change states, repositories, releases, technical decisions and project risks.
Explore this assessment service