Choose a Computer Science final-year project by defining a technical question or deliverable, accessible inputs and a way to evaluate it. Then check the work against your confirmed brief, resources and deadline. A title such as “attendance system” or “AI platform” does not by itself establish novelty, feasibility or success.
UniDraft’s free topic generator can help you produce candidate directions from your department and a course you enjoyed. Use the checks below before discussing them with your supervisor. UniDraft supports the written documentation; building and evaluating the computing work remain your responsibility.
Your project idea is only the beginning; the written document needs to explain what you actually built, how you evaluated it and the instructions you must follow. UniDraft helps turn that confirmed work into an editable Word document, so you can focus your review on the technical decisions and evidence. Start your project document with UniDraft.
Start with the deliverable, not a fashionable label
A project might involve designing software, analysing an algorithm or dataset, investigating an interaction, or evaluating a defined technical approach. Confirm which forms your assignment permits. The ACM/IEEE-CS/AAAI CS2023 knowledge areas include software engineering, data management, human-computer interaction, security and AI among other fields; that breadth is not a rule about what your Nigerian department will approve.
For the wider deadline, access and supervision checks, use the general project-topic selection guide. This guide focuses on turning a computing direction into a bounded deliverable and evidence plan. A Computer Science seminar may instead review published work; do not claim implementation evidence you have not produced.
Five directions to investigate
The table contains fictional planning directions, not approved titles, tested systems or student case studies. Each still needs evidence and a method appropriate to the brief.
| Direction | Bounded candidate question | Evidence needed before commitment |
|---|---|---|
| Booking or allocation prototype | How should a defined process handle conflicting reservations and cancellations? | Confirmed rules, permitted test material, implementation boundary and expected cases |
| Inventory or records tool | How will specified transactions preserve an agreed record-consistency rule? | A data model, transaction definitions and cases including invalid or repeated input |
| Data-science comparison | How do suitable approaches compare on a defined task and accessible dataset? | Licence, provenance, target definition, baseline, split plan and appropriate measures |
| Accessibility-oriented interface | How does one defined interaction meet selected criteria or user needs? | Relevant criteria, a documented evaluation method and participant permission where applicable |
| Defensive security exercise | Does a defined protective check behave as expected in a permitted training environment? | Isolated environment, authorisation, configuration and expected observations |
Choose a branch because its question and evidence are workable. Do not claim that a records tool reduced real losses, an interface helped all users or a model is accurate before conducting a suitable evaluation.
Worked example: a booking prototype
Fictional planning exercise — no application has been built or tested. A student proposes a room-booking prototype. Their first decision is not which animation library to use; it is what counts as a booking conflict.
They need to establish the relevant rules: whether intervals include their end time, whether two events may share a room, who can cancel, and when a cancellation releases availability. Those are proposed questions for the process owner, not facts about a real campus.
A candidate first version might create, cancel and check bookings. Payment collection, biometric attendance and a campus-wide rollout remain outside that proposed scope unless the brief and resources justify adding them. A clear exclusion helps the reader understand the work; it does not excuse missing an agreed requirement.
Use an original decision record before choosing the title:
| Decision | What to record | Current status in this fictional exercise |
|---|---|---|
| Rule source | Who defines overlap and cancellation rules? | Not yet confirmed |
| Inputs | What test records may be used, and with what permission? | Not yet confirmed |
| Boundary | Which actions belong in the candidate version? | Proposed: create, cancel, availability check |
| Evaluation | Which expected behaviours and failure cases should be checked? | To be agreed before testing |
| Evidence | Where will versioned observations and unresolved defects be recorded? | Not run; no result exists |
After implementation, connect requirements to actual observations using the software-test-case guide. A success toast alone cannot establish that conflicting bookings are impossible. The system-design-diagram guide explains separate views of roles, information movement and stored data; a diagram is not proof of implementation.
If you choose a data-science or AI project
Define the task, what each record represents, the target and when each feature would be available. Identify missingness and label limitations. Check whether repeated people, devices or time-related records require grouping or a time-aware design rather than assuming every row is independent.
The scikit-learn common-pitfalls guide explains that using information unavailable at prediction time can make evaluation look better than it is. It also warns against fitting preprocessing on the held-out test data. Plan separation and development decisions before evaluating the final model; do not copy a universal split percentage or invent an accuracy target from this article.
Start with a defensible comparison or baseline. Explain the measure you will use and what it cannot establish. A downloadable dataset needs a licence and provenance check; an attractive topic title cannot supply missing permission or valid labels.
Use the methodology guide for the design and evidence plan. UniDraft does not train models or execute statistics for you.
If you choose a security topic
Define a defensive question and the environment you are authorised to use. OWASP’s WebGoat project is a deliberately vulnerable educational application intended for safe, permitted practice. Its documentation warns about exposure; follow its setup guidance and keep a training environment isolated rather than exposing it publicly.
This is a potential learning environment, not evidence about the security of your university. Do not scan a campus portal or another person’s system without appropriate authorisation. Record the configuration, expected behaviour, actual observations and limits of your exercise. Avoid turning a laboratory result into a claim that a real organisation is secure.
Prepare the documentation and defence handover
Keep the confirmed requirements, design decisions, source and data permissions, implementation versions, actual tests, failures and limitations. Distinguish proposed features, built features and evaluated behaviour. Report an unresolved defect rather than inventing a successful test.
The results-chapter guide helps present actual evidence. For your defence preparation, explain what you built or investigated, why the chosen method fits, and what remains untested.
UniDraft can help organise that confirmed work into an editable project document around the applicable project, supervisor and institutional instructions. It cannot supply a missing implementation, run tests, recruit users or establish approval. Use the citation finder for candidate references and verify the publications yourself, then start your document when you have the material to describe honestly.
A selection worksheet for your shortlist
- What question or deliverable will this candidate address?
- Which inputs are actually available, and what licence or permission applies?
- What environment, equipment or access is needed?
- What comparison, baseline or agreed criteria will support evaluation?
- Which observations and evidence files would support the eventual claim?
- What dependencies, costs and exclusions remain?
- Which supervisor or departmental decision is still required?
Use the answers to discuss the candidate. They do not guarantee acceptance, a particular grade or a system without defects.
Sources
- ACM/IEEE-CS/AAAI CS2023 knowledge areas — breadth of computing fields, not local project-approval rules.
- scikit-learn: Common pitfalls and recommended practices — preprocessing consistency and data-leakage concerns.
- OWASP WebGoat — an authorised educational security environment and its exposure limits.