Skip to content
ProductHow it worksFind a topicProject topics

Computer Science methods Student writing guide

Planning and Evaluating a Computer Science Project Prototype

A software project needs a defensible problem, defined users or operating context, requirements, a build method and evaluation evidence. A list of features is not a research question, and a successful demo does not by itself establish usability, security or usefulness. NASA’s public software handbook is written for agency projects, but its verification-versus-validation distinction and planned test evidence offer a useful engineering reference that should be scaled to a student project.

A practical guide from FINAL YEAR NG Check your department's current instructions before you submit.

Bound the problem before choosing the stack

  1. Name one user group or process and the specific difficulty the proposed system addresses.
  2. Check whether a simple existing tool, workflow change or no-build option could address the need.
  3. Define a small number of measurable functional requirements and constraints.
  4. Confirm data access, hosting, security, device and maintenance limits before promising features.
  5. Write acceptance criteria that someone else could use to check each requirement.
Worked planning example

Instead of claiming to build a complete university e-voting platform, scope a prototype that demonstrates ballot setup, one test election, duplicate-submission rejection and an auditable result summary using synthetic ballots. State that the prototype is not certified for real elections; do not claim security or production readiness without suitable threat analysis and independent testing.

Plan evaluation that matches each claim

Verification checks whether implementation meets specified requirements. Validation asks whether the chosen system addresses user needs in its intended context. Keep the questions distinct and record the planned setup, test data, steps and expected outputs. Small project constraints may justify a modest test scope, but not vague acceptance claims.

  • Functional claim: trace each requirement to a test case and observed output.
  • Usability claim: define tasks, participant eligibility, measures and limitations before recruiting anyone.
  • Performance claim: define hardware, dataset size, timing procedure and repeated runs.
  • Security claim: limit claims to checks actually conducted and disclose threats not assessed.
  • Compare the result with the acceptance criteria and report failures as well as passes.

Keep implementation and research evidence traceable

Keep version-controlled code, dependency versions, test outputs and a short change log. If people test a system or provide feedback, establish whether ethics or departmental approval is required before collecting identifiable responses. Use synthetic or public test data only when it suits the question, and label it accurately.

Sources and further reading

These university writing resources inform the general advice here. They do not replace your department's handbook or supervisor's guidance.

  1. NASA Software Engineering Handbook: Requirements Validation
  2. NASA Software Engineering Handbook: Verify Implementation
  3. Node.js documentation: Test runner
← All writing guidesChoosing a project topic →