You spent months building the system — it runs, it does what you designed it to do, your demo works. Now you are staring at Chapter Three with nothing written, because building software and writing a final year project about it are two different skills, and Nigerian computer science departments grade the second one just as hard as the first.
Why is writing up a software project harder than building it?
Coding gives you constant, immediate feedback — it compiles or it does not, the test passes or it fails. Writing a thesis chapter gives you none of that until a supervisor reads it, which is exactly why it feels harder even when it should be more familiar territory: you already know your system better than anyone. The actual difficulty is translation — turning what you built and why into the specific chapter structure, terminology, and evidence format a panel expects, which is a different exercise from the build itself and does not get easier just because the system works well. Students who leave the write-up until the system is fully finished usually find this translation gap is bigger than expected, because six months of decisions made in the moment are hard to reconstruct as a coherent justified narrative after the fact. The same blank-page freeze happens to survey-based projects once their data is collected — a working system and a full dataset are both the easy half of the project; the write-up is the half that actually determines the grade.
What goes in Chapter Three for a software-project thesis?
Chapter Three for a system-development project names your development methodology explicitly (Agile, Waterfall, SSADM, or a prototyping approach) and justifies why it fits your project’s scope and timeline, then documents your requirements gathering (how you determined what the system needed to do — interviews with prospective users, a review of an existing manual process, or both), your system design (architecture diagrams, database design or entity-relationship diagrams, and the tools and technology stack you used, each with a stated reason for the choice), and your testing plan (what kinds of testing you intended to run and against what criteria, written here as a plan and reported as results in Chapter Four). This chapter is where “I used Python and Firebase” becomes “Python was selected for its established libraries for [your specific feature], and Firebase was selected for real-time synchronisation without requiring a dedicated backend server for a project of this scale” — the justification, not just the naming, is what a panel is grading.
What goes in Chapter Four?
Chapter Four presents your system’s implementation and testing results: screenshots of key interfaces with captions explaining what each one demonstrates, a description of how the system was built following the design from Chapter Three, and your testing results — unit tests, integration tests, and user acceptance testing, each reported with what was tested, the method, and the outcome. If you ran a small usability test with real users, report it the way any evaluation is reported: number of testers, what task they completed, and the measured outcome (task completion rate, time taken, or a satisfaction rating), not a general claim that “users liked the system.” Screenshots alone are not results — a screenshot shows the system exists; a testing table shows the system works, and Chapter Four needs both, with the testing table doing the heavier evidential lifting.
What goes in Chapter Five?
Chapter Five follows the same summary-conclusion-recommendations-contribution structure any final year project’s Chapter Five needs, adapted to a system-development project: your summary restates what the system does and how it was built and tested, your conclusion states plainly whether the system met its stated objectives (a genuine assessment, not an unqualified success claim), your recommendations point to specific future features or improvements a later project could build on, and your contribution to knowledge names precisely what your system adds — a working implementation of a specific technique in a specific context, a comparison of two approaches you tested, or a solution to a defined local problem. A software project’s contribution to knowledge is easy to overstate (“this system revolutionises X”) or understate (“this is just a student project”); the accurate version is specific and modest: what exactly does your working system demonstrate that did not exist, in that form, before you built it.
How do you turn code and testing into “results” a panel accepts?
A panel does not evaluate your source code directly in most Nigerian computer science defences — they evaluate what you present about it, which means your testing evidence has to be organised the way any other project’s results are organised: a table of test cases with expected versus actual outcomes, a usability metric if you collected one, and a discussion paragraph interpreting what the results mean for your original objectives. If your system passed all your functional tests, say so with the actual test count and pass rate rather than a general “the system was tested and works well.” If something did not work as intended, report it honestly as a limitation rather than omitting it — an examiner who runs your demo and finds a feature that Chapter Four claimed worked perfectly is a worse outcome than an honestly reported partial result.
How should you keep a build log so the write-up is not a reconstruction job?
The single most useful habit for a software-project write-up is keeping a running log from the day you start building, not just at the end: a short dated entry each time you make a significant design decision, run a test, or change direction, with a one-line reason. This log becomes the raw material for Chapter Three’s justifications and Chapter Four’s testing narrative directly — instead of trying to remember in week fourteen why you switched from one database design to another in week four, you already have the reason written down. Students who keep this log from the start consistently spend less time on the write-up than students who wait until the system is finished and then try to reconstruct six months of decisions from memory and old commit messages.
Common mistakes CS students make writing up their software project
Four mistakes recur. First, describing the system in Chapter Four without ever stating a testing methodology in Chapter Three, so the results have no stated method behind them. Second, treating screenshots as self-explanatory evidence instead of captioning each one with what it demonstrates and why it matters to an objective stated in Chapter One. Third, writing a contribution to knowledge that is either wildly overstated or so vague it says nothing measurable. Fourth, leaving the limitations section as an afterthought rather than connecting it explicitly to what the testing results actually showed — the two sections should read as though the same person who ran the tests wrote both, because they did. A fifth, closely related mistake is starting Chapter Four the night before submission, once every screenshot is already taken but no testing log was kept along the way — reconstructing which test covered which requirement after the fact is far slower than logging it as you go.
How does Tesify help you get from working code to a finished write-up?
Tesify does not write your code and does not generate fake test results — the system and its testing have to be genuinely yours. What it does is take you from a working system with no chapters written to a structured Chapter Three through Five draft built around what you actually built: describe your methodology, your architecture, and your testing approach, and Tesify’s editor helps structure it into the format your department expects, checks that your Chapter Three testing plan and Chapter Four results actually match, and flags a contribution-to-knowledge claim that is too vague or too broad. For a student who has spent the semester in an IDE rather than a word processor, this is the fastest way to close the gap between “the system works” and “the project is submitted.” The free plan is the place to start turning your build log and screenshots into a first Chapter Three draft tonight.
Frequently asked questions
Do I need to include my full source code in the thesis document?
Most Nigerian departments ask for key code excerpts (a critical algorithm, a core function) in the body or an appendix, not the entire codebase, plus a note on where the full source is available (a repository or a submitted disc/drive) if your department requires it.
How many test cases should I report in Chapter Four?
Enough to cover your system’s core features and edge cases — commonly 10 to 20 for an undergraduate project — reported in a table with expected versus actual outcome for each, rather than an exhaustive log of every test run during development.
Is a system that only partially works still defensible?
Yes, if you report honestly which features work, which do not, and why, and connect that honestly to your limitations section — an examiner respects an accurate account of a partially working system far more than an inflated claim a live demo then contradicts.
Does Tesify write code for my project?
No. Tesify is a writing and editing tool for your thesis document, not a code-generation tool for your system — the software itself is your own work, built and tested by you.
Will using an AI editor on my write-up be treated as academic misconduct?
Tesify edits and structures your own account of a system you built and tested — it does not generate fabricated results or claims. Used this way it is legitimate writing support, the same as any editing help, not a plagiarism or misconduct risk.
Can I start writing Chapters Three to Five before my system is fully finished?
Yes for Chapter Three, since your methodology and design can be documented once decided, even before every feature is built. Chapters Four and Five need your actual testing results, so they follow once implementation and testing are substantially complete.
What if my supervisor keeps asking for a different testing methodology than the one I already used?
Document what you actually ran, and discuss with your supervisor whether additional testing is feasible in your remaining timeline; retrofitting a Chapter Three testing plan to match tests you never ran is a worse outcome than an honest, if smaller, testing scope reported accurately.
Is it too late to start a build log if my system is already mostly finished?
No — start now for whatever development remains, and reconstruct the earlier decisions as accurately as you can from commit history, saved files, and memory for the parts already done. A partial log from this point forward still saves significant time compared with reconstructing everything at the very end.
Start on Tesify’s free plan to turn your working system into a finished Chapter Three through Five this week.