A computer science final year project in Nigeria rarely gets sent back because the underlying code does not work. It gets sent back because the system cannot be demonstrated live on the day, the methodology chapter claims a process the actual build does not evidence, or the student cannot explain a section of their own code when an examiner asks a direct question about it. Here are the objections that come up again and again, and how to close each one before your defence.
Objection 1: The System Cannot Be Demonstrated Live
A project that only exists as screenshots in Chapter Four is one of the most damaging gaps an examiner can find, because a live demonstration is usually part of a computer science defence and a system that will not run on the day undermines everything written about it. Test your system on the actual machine and network you will present with, well before your defence date, not the night before — a system that worked on your development laptop but fails on the projector’s network or a different browser is a completely avoidable failure. Have a backup: a recorded video of the system working, in case of a live technical failure on the day itself, and tell your supervisor this backup exists rather than hoping you never need it.
Objection 2: The Claimed Methodology Does Not Match What You Built
Claiming Agile without a product backlog, sprint log, or commit history that shows genuine iteration is one of the most commonly raised objections, because Agile is a team methodology with named artefacts, and a solo student who cannot produce them is describing a process they did not actually follow. The same applies to SSADM without a real case-study organisation whose existing system you analysed, or waterfall claimed for a project whose requirements visibly changed partway through. Our comparison of SSADM, waterfall, Agile and prototyping covers exactly which evidence each methodology needs to be defensible — choose the one your actual process produced evidence for, not the one that sounds most rigorous on paper.
Objection 3: The Case Study or Data Is Invented
A system that claims to computerise a named organisation’s manual process but was never actually shown to anyone at that organisation is a red flag examiners routinely probe: they will ask what the organisation’s current forms looked like, who you interviewed, and what problems staff there named. If you cannot answer with specifics, the analysis of the existing system reads as invented rather than researched. Where genuine access to an organisation was not possible, say so honestly and build the system around a documented, labelled hypothetical scenario instead — an honest hypothetical survives scrutiny; an invented case study presented as real does not.
Objection 4: The Testing Section Is Missing or Thin
A one-paragraph claim that “the system was tested and works correctly” without a test case table is treated as an incomplete chapter, not a minor omission. Examiners expect unit testing, integration testing and user acceptance testing each described, with a table of test cases covering both normal inputs and edge cases: the input, the expected output, the actual output, and a pass or fail result. Build this table as you test, not retrospectively from memory once the system is already finished — a reconstructed table is far more likely to contain errors an examiner catches by asking you to re-run a specific case live.
Objection 5: You Cannot Explain Your Own Code
Code copied from a tutorial or another project without genuinely understanding what it does is exposed the moment an examiner asks “why did you use this approach here instead of an alternative?” and the student cannot answer. Many examiners accept that some tutorial-derived code is normal in a student project — what fails a defence is not being able to explain a design decision in your own submitted system. Before your defence, go through your own codebase and be ready to explain, in your own words, what each major module does and why you built it that way, even for sections you adapted from external sources.
Objection 6: Scope Mismatched to What Was Actually Delivered
A project whose Chapter One promises a comprehensive system with many features, but whose Chapter Four demonstrates only a fraction of them working, invites an objection about whether the scope was realistic from the start. Scope your Chapter One objectives to match what you can genuinely deliver and demonstrate, and if your build’s actual capability narrowed during development, revise Chapter One to match reality rather than leaving an aspirational scope statement that your working system does not support.
Objection 7: The Database Design Does Not Match the System
An entity relationship diagram or a set of data flow diagrams in Chapter Three that does not correspond to the actual database tables implemented in your working system is a discrepancy examiners can check by asking to see your database structure alongside your diagrams. Every entity, relationship and data store on your design diagrams should map directly to a table or a data flow in your finished system; where the system evolved and the design changed, update the diagrams to match the final build rather than submitting an earlier, outdated design alongside a different working system.
Objection 8: Security Claims Without Evidence
A system that claims to be “secure” without describing what specific measures were implemented (password hashing, input validation, access control by user role) and without at least basic testing of those measures invites a direct objection, particularly for projects handling any kind of sensitive data (patient records, financial transactions, personal information). State exactly what security measures your system implements, and be honest about what it does not cover — a stated limitation is defensible; an unsupported blanket security claim is not.
Objection 9: Documentation Does Not Match the Final Build
Screenshots in Chapter Four taken from an earlier version of the system, before a late change, are a common and entirely avoidable objection — retake every screenshot from your actual final, submitted build immediately before binding your project, not from whatever version happened to be running when you first wrote that chapter section weeks earlier.
A Worked Illustrative Example
The following is a labelled, illustrative example, not a real case. A student builds a hospital appointment-booking system, writes Chapter Three claiming an Agile process, but at defence cannot produce a backlog, sprint dates or commit history — only a single final version of the code. The examiner’s objection is not that Agile is a poor choice, but that no evidence supports the claim; the student is asked to instead describe, in their own words, how the system was actually built, and the honest answer (built iteratively over several months based on informal feedback from a friend who works at a clinic, with no formal sprints) would have been a defensible prototyping-methodology claim from the start. The lesson generalises beyond this one example: match the methodology label to the evidence you can actually produce, not to whichever term happens to test well with a supervisor at the proposal stage.
How to Prepare for These Objections Before Your Defence
Run through this list against your own project honestly, a week before your defence, not the night before: can the system run live, right now, on the machine you will actually present with; does your methodology chapter’s claimed process match evidence you can actually produce; can you explain every major design decision in your own words; does your test case table reflect tests you genuinely ran; and do your diagrams and screenshots match your final build exactly. A short rehearsal defence with a coursemate or your supervisor, run to a strict clock and covering at least three of the nine objections above, catches more gaps in a single afternoon than another week of silently reviewing the written chapters alone. The broader set of questions a computer science panel raises beyond these nine specific objections is covered in our guide to what is asked during a project defence, and how to state honestly what your system does not cover is explained in our guide to writing the limitations section of a computer science project.
Tesify helps you keep your Chapter One scope, your Chapter Three methodology and your Chapter Four testing evidence consistent with each other as your project develops, so the gaps examiners look for are closed before your defence rather than discovered during it. Start your computer science project with Tesify — over 9,000 students and 15,000+ chapters written, 100% written by you.
Frequently asked questions
What is the most common reason a computer science project gets sent back?
A system that cannot be demonstrated live, working exactly as described in the written chapters, is among the most consistently raised objections, because it undermines the credibility of everything else written about the system.
Can I claim Agile if I worked alone on my project?
Only with genuine evidence: a written product backlog, sprints of a stated length, a commit history matching your sprint dates, and at least one named stakeholder who reviewed an increment. Without that evidence, prototyping is usually a more honest and equally defensible label for solo iterative work.
What happens if my case study organisation refused to let me visit in person?
State this honestly rather than presenting an invented visit as real, and build your system around a clearly labelled hypothetical scenario instead, or switch to a project design that does not require an existing organisation’s process analysis.
How many test cases should my testing table include?
There is no fixed national number; include enough to cover every main function of the system, both expected inputs and edge cases, and confirm with your supervisor whether your department sets its own minimum.
Will an examiner really ask me to explain a specific line of my own code?
It is a common and reasonable question, especially for sections that look more sophisticated than the surrounding code, and being unable to explain a design choice in your own submission is treated seriously regardless of whether the code itself works.
Should I remove features I could not finish before my defence?
State clearly in Chapter One and Chapter Five which planned features were delivered and which were not, rather than presenting an incomplete feature as though it were finished; an honestly scoped, fully working system defends better than an overstated, partially working one.
Do I need to retest my system right before my defence?
Yes, on the actual hardware, network and software environment you will present with, as close to your defence date as practically possible, since an environment difference between your development machine and the presentation setup is a common, avoidable cause of a live demonstration failing.
What if my database structure changed after I drew my ERD?
Update the ERD and any related diagrams to match your final, actually implemented database structure before submission; a diagram that does not match your working system is a discrepancy an examiner can check in minutes.
Is it better to under-promise in Chapter One or risk over-promising features?
A scope that is modest but fully delivered and demonstrable defends far better than an ambitious scope where several claimed features do not actually work at defence time; examiners generally respond better to an honestly bounded, complete system than to an impressive-sounding but partially broken one.
Should I rehearse my defence before the actual day?
Yes. A rehearsal with a coursemate or supervisor acting as the panel, covering a live demonstration and at least a few direct code-explanation questions, surfaces gaps far more reliably than reading your own chapters back silently.