# Final-year project: build evidence, not just a demo

This is a working template, not a completed report. Fill each field with your own evidence; do not present an example as a result. Your department rubric and supervisor’s instructions take priority. Keep private data and secrets out. Copy individual sections into issues, PRs or team documents as needed.

## 1. Project brief & risk register

Agree the smallest useful outcome with your supervisor before committing to scope.

- Title / team / supervisor / review date / rubric link:
  Response / evidence link:

- User and problem / real evidence or research question / permission to use evidence:
  Response / evidence link:

- Smallest measurable outcome / in scope / explicitly out of scope:
  Response / evidence link:

- Deadline / weekly capacity / budget / equipment and data constraints:
  Response / evidence link:

- Risk / impact and likelihood / early warning / owner / mitigation or fallback / next review:
  Response / evidence link:

- Ethics, privacy and safety approvals / approver / status / evidence link:
  Response / evidence link:

## 2. Team agreement & milestone plan

Write together at kickoff; revisit when availability or scope changes.

- Members / weekly availability / absence and handoff arrangements:
  Response / evidence link:

- Shared board and repo / communication channel / response window / escalation contact:
  Response / evidence link:

- Issue owner and reviewer rule / rotating facilitation and release roles / contribution credit:
  Response / evidence link:

- Ready criteria / Done criteria / WIP limit / blocked-work policy:
  Response / evidence link:

- Milestone / demoable outcome / acceptance evidence / target date / dependencies / scope cut:
  Response / evidence link:

- Supervisor review dates / feature freeze / test-report-defense buffer / disagreement process:
  Response / evidence link:

## 3. Ready-to-pick-up issue

Copy into your task manager. Split the task if a peer cannot explain what Done means.

- Issue ID and behavior-focused title / parent outcome or milestone / requirement ID:
  Response / evidence link:

- Problem and why now / in scope / out of scope:
  Response / evidence link:

- Owner / reviewer / priority / estimate / dependency IDs / risk or spike question:
  Response / evidence link:

- Acceptance: Given [starting state], when [action], then [observable result]; failure/boundary case:
  Response / evidence link:

- Implementation subtasks / test approach and data / docs affected:
  Response / evidence link:

- Status / blocked reason, helper and next check-in / PR link / verification evidence:
  Response / evidence link:

## 4. Pull request & peer review

Use for one coherent change; report checks you actually ran, including failures.

- Issue / requirement / base and feature branch / summary and reason:
  Response / evidence link:

- How to run and review / test commands / environment / actual result and log links:
  Response / evidence link:

- Acceptance evidence / screenshots if relevant / failure and recovery behavior:
  Response / evidence link:

- Security, privacy, accessibility and compatibility impact / config or migration / rollback considerations:
  Response / evidence link:

- Docs changed / known gaps / reviewer / blocking feedback and resolution / approval:
  Response / evidence link:

- CI run link / merged commit / integrated verification / final issue status:
  Response / evidence link:

## 5. Sync-up & weekly review note

Share the agenda first and publish decisions afterward; include absent teammates.

- Date / attendees / facilitator / agenda and milestone:
  Response / evidence link:

- Async update: completed + issue/PR; next action; blocker + help needed:
  Response / evidence link:

- Demo / acceptance criteria checked / actual evidence and feedback:
  Response / evidence link:

- Decision / reason / ADR or issue link / unresolved question:
  Response / evidence link:

- Action / one owner / due or next check-in date / dependency:
  Response / evidence link:

- Retrospective: keep / change / one experiment next week / owner:
  Response / evidence link:

## 6. Decision & traceability record

Explain the tradeoff and connect a requirement to its evidence, not just a diagram.

- ADR ID / context / constraints / at least two options / choice and reason:
  Response / evidence link:

- Consequences / risks / reviewer / review date / trigger to revisit:
  Response / evidence link:

- Requirement ID → scenario → acceptance criterion ID → issue/ADR → implementation/PR → test ID → actual result → release:
  Response / evidence link:

## 7. Risk-based test plan & run report

Plan before implementation; fill actual results only after running the tests.

- Scope / excluded checks and reasons / highest risks / release criteria:
  Response / evidence link:

- Test ID / requirement ID / risk / unit, integration, E2E or manual / owner:
  Response / evidence link:

- Setup / safe fixture / inputs / actions or exact command / expected outcome:
  Response / evidence link:

- Run: commit/tag / runtime and dependency versions / device or environment / date:
  Response / evidence link:

- Actual outcome / PASS, FAIL, BLOCKED or NOT RUN / safe log or screenshot / defect link:
  Response / evidence link:

- Accessibility, permission, performance and recovery checks appropriate to this project:
  Response / evidence link:

- Retest commit / affected tests rerun / peer verification / remaining limitations:
  Response / evidence link:

## 8. Reproducible bug report

Describe what failed so another person can reproduce it without guessing.

- Title / requirement or test ID / affected commit / environment:
  Response / evidence link:

- Preconditions / minimal steps and safe input / expected result / actual result:
  Response / evidence link:

- Frequency / severity and impact / priority and reason / redacted evidence:
  Response / evidence link:

- Owner / workaround / failing regression test / fix PR / retest evidence / verifier:
  Response / evidence link:

## 9. Release, reproduction & handover

Rehearse with a peer using a clean environment; do not merely tick a checklist.

- Release tag and commit / artifact and checksum if applicable / owner / release notes:
  Response / evidence link:

- Prerequisites / exact setup-build-test commands / config example without secrets / safe sample data:
  Response / evidence link:

- Independent reproducer / environment / actual result / issues found and repaired:
  Response / evidence link:

- Deployment and migration steps / smoke test / backup and restore evidence / rollback limits:
  Response / evidence link:

- Known issues / safe operating limits / maintenance owner / access transfer without exposed credentials:
  Response / evidence link:

- Report and demo links / defense questions / permitted offline fallback / department sign-off:
  Response / evidence link:

## 10. Contribution, sources & AI disclosure

Follow your department and publication rules; explain what each person can defend.

- Member / design, implementation, testing or research contribution / evidence links:
  Response / evidence link:

- Borrowed code, assets and datasets / source / license or permission / citation:
  Response / evidence link:

- AI/tool assistance allowed by policy / where used / human verification / limitations:
  Response / evidence link:

- Consent and approval records stored safely / public report redactions / reviewer:
  Response / evidence link:

## Readiness review

- The supervisor/rubric requirements and team contributions are documented.

- Critical requirements have observable acceptance criteria and linked results.

- The main design decision and rejected alternative are explained.

- A peer can run the tagged artifact using the README and safe data.

- Tests include a failure case; results name the environment and remaining limitations.

- Relevant accessibility, privacy, security and physical-safety risks are reviewed.

- Licenses, citations, dataset permissions and AI assistance are honestly attributed.

- Recovery/handover steps and known issues match the demo and report.

## Stage quality bar

### 1 · Define a useful, finishable problem

A one-page brief that another person can explain back to you, with supervisor feedback recorded.

Do not choose microservices, blockchain or an AI model before explaining the problem they solve.

### 2 · Turn requirements into testable promises

A prioritized requirement list and test matrix; someone can tell what passes, what fails and what is deliberately excluded.

Do not invent performance targets or pretend a usability claim is validated without observation.

### 3 · Design the smallest coherent system

A peer can trace one scenario through the design and explain a rejected alternative and one unresolved risk.

Do not add distributed services, Kubernetes or custom authentication just to look industrial.

### 4 · Deliver in small, reviewed slices

A fresh checkout runs using documented steps; a reviewed change shows its requirement, test result and contribution.

Do not save integration until the final week or submit a tutorial clone without explaining your own contribution.

### 5 · Test the claims, including failures

A traceable test report with pass/fail results, fixed-defect evidence and explicit remaining risks—not a claim of zero bugs or universal security.

Do not chase 100% coverage, hide failures, fabricate participants or use AI-generated measurements as results.

### 6 · Make it reproducible and recoverable

An independent reproduction note tied to the release and a tested recovery procedure where relevant.

Do not pay for production hosting or expose sensitive data just to show a public link.

### 7 · Explain, defend and hand over honestly

A report, reproducible artifact and defense that agree with one another; a new maintainer can identify the next safe change.

Do not call a student prototype production-ready, a paper accepted, or a design certified unless you have the relevant evidence.

CSE-Pothik · https://cse-pothik.com · All rights reserved