The limitations section of a computer science final year project in Nigeria is a short, factual account of what your system, dataset, or testing conditions could not cover — usually 200 to 400 words in Chapter Five. It names constraints on scope, data, hardware, or evaluation honestly, without apologising for them or letting them undercut your contribution to knowledge.
Where does the limitations section go in a computer science project?
In the near-universal five-chapter structure Nigerian departments use, limitations sit in Chapter Five, after your summary and conclusion and before or alongside your recommendations. Some departments — check your own project guideline first — ask for a short limitations paragraph inside Chapter One as well, flagging scope decisions the reader should know before they reach your methodology. When both are required, Chapter One states the boundary you set deliberately (a delimitation); Chapter Five reports what happened to you despite your best planning (a true limitation). Confusing the two is one of the most common corrections a supervisor returns on Chapter Five.
What counts as a technical limitation in a computer science project?
Technical limitations are constraints that came from your tools, data, or environment, not from your design choices — and they follow directly from whichever system development methodology you chose in Chapter Three. The ones examiners in Nigerian computer science departments see most often are:
- Dataset size and source. A model trained on a few thousand rows scraped or downloaded from Kaggle, UCI, or a single Nigerian organisation cannot claim the generalisability a national or industry-scale dataset would support.
- Testing environment. A system tested only on your own laptop, a single Android version, or a departmental local area network was not tested under the load, device diversity, or network conditions of a live Nigerian deployment.
- Third-party API and service limits. Free-tier API keys, rate limits on services such as Google Maps, payment gateways, or SMS gateways, and dependency on a service that could change its terms after your defence.
- Hardware and connectivity. If your system assumes stable electricity or broadband that a typical Nigerian user or institution cannot guarantee, that assumption is a limitation, not a footnote.
- Algorithm and feature scope. You implemented one algorithm family (say, a single classifier) rather than a comparative study of several, or your system covers one module of a larger real-world workflow.
What counts as a methodological limitation?
Methodological limitations concern how you evaluated the system rather than what the system does. Common ones in Nigerian undergraduate and HND computer science projects include a small or convenience sample of test users (often classmates or one department, not a randomised or representative sample), a short evaluation window fixed by the academic calendar rather than by the system’s needs, no formal usability testing beyond informal feedback, and reliance on self-reported user satisfaction rather than measured task completion or error rates. None of these disqualify your project — panels expect them at undergraduate level — but naming them precisely, rather than in general terms such as “time constraint” alone, is what separates a strong limitations section from a weak one.
How is a limitation different from a delimitation?
A delimitation is a boundary you chose: “this system focuses on the accounting module of the ERP, not procurement,” or “the recommender system is scoped to the university bookstore, not a general e-commerce catalogue.” A limitation is a constraint you did not fully choose: your dataset was smaller than you wanted because the organisation would not release more records, or your API quota capped how many requests you could test. Panels penalise a project that states its delimitations as if they were unavoidable weaknesses — “I only covered the accounting module because of time” reads as an excuse; “this project scopes the system to the accounting module to allow a working prototype within the project timeline” reads as a design decision. Say what you chose as a delimitation in Chapter One, and reserve Chapter Five’s limitations for what happened despite your planning.
How long should the limitations section be?
Three to six limitations, each stated in one to three sentences, is the range most Nigerian computer science supervisors expect — long enough to show you understand your system’s boundaries, short enough that it does not read as a list of apologies. A single overlong paragraph that buries the actual constraints in hedging language (“it is possible that,” “there may have been some challenges”) usually loses marks for clarity rather than for content. State the constraint, then its effect on your results in one sentence: “The model was trained on 3,200 labelled transactions from one Lagos-based SME due to data-sharing restrictions, so its accuracy figures should not be generalised to other transaction volumes or sectors.”
What should you not write as a limitation?
Three things reliably cost marks. First, do not write “I did not have enough time” as a standalone limitation — every undergraduate project runs on the same academic calendar, so this reads as an excuse rather than a scoped constraint; instead, name what the time constraint actually prevented you from testing or building. Second, do not restate your delimitations as limitations — a deliberate scope decision belongs in Chapter One, not as a weakness confessed in Chapter Five. Third, avoid vague language such as “the system may have bugs” or “results may not be accurate” without saying which part of the system and under what condition; a panel member will ask you to be specific in the defence if you are not specific on the page.
Worked example: limitations for a machine learning project
“This study trained the fraud-detection model on 4,150 anonymised transaction records obtained from one Nigerian fintech partner over a six-month period, which limits the model’s exposure to seasonal fraud patterns and to transaction types outside that partner’s product line. The evaluation used an 80:20 train-test split rather than a separate, independently sourced test set, so reported precision and recall figures should be read as an estimate of performance on similar data rather than a guarantee of performance in production. Model training and inference were carried out on a single consumer-grade GPU, which constrained the model architectures that could be trained within the project timeline; a deeper network or a larger ensemble may yield different results. Finally, the system was not tested against adversarial or deliberately obfuscated transactions, so its robustness to active evasion by fraudulent actors remains untested.”
Worked example: limitations for a web or mobile application project
“The application was tested with 22 student users drawn from one department over a two-week period, a convenience sample that does not represent the age, digital literacy, or device range of the university’s full student population. Usability testing measured task completion and a five-point satisfaction rating but did not include eye-tracking or think-aloud protocols, so findings on where users hesitated are based on observation notes rather than instrumented data. The system was deployed on a shared low-cost hosting plan for the demonstration period, which does not reflect the concurrent-user load a full institutional rollout would place on the database layer. The offline mode was implemented for the student registration module only, so claims about the system’s usability during network outages apply to that module and not to the payment or results modules.”
How do limitations affect Chapter Five’s recommendations?
Every limitation you name should generate at least one recommendation, and every recommendation for further work should trace back to a named limitation — panels notice when the two sections do not connect, and they will read your Chapter Four results against the limitations you claim before deciding how far to trust your conclusion. If your dataset was small because one organisation supplied it, your recommendation is to validate the model on a larger, multi-organisation dataset, not a generic “further research is needed.” If your evaluation used a convenience sample, recommend a study with a probability-sampled or larger user base. This one-to-one mapping is also what makes your contribution to knowledge defensible: you are telling the panel exactly what your finding does and does not support, which is stronger — and reads more carefully hedged, the way strong Chapter Five findings statements are — than an unqualified claim a panel member can pick apart in the defence.
Frequently asked questions
Is it acceptable to have no limitations in a computer science project?
No. Every study has boundaries, and a panel reads “no limitations” as a sign the student has not thought critically about their own work, not as a sign of a flawless project.
Can I put limitations in both Chapter One and Chapter Five?
Yes, if your department’s guideline asks for it — Chapter One states what you deliberately scoped out (delimitations), and Chapter Five reports what constrained your results despite that scoping (limitations). Confirm the exact requirement with your supervisor, since not every department separates the two.
How many limitations should a computer science project have?
Three to six specific, well-explained limitations are typical. Fewer than three usually means you have not examined your methodology closely enough; more than six often means you are listing minor issues that dilute the ones that matter.
Does naming limitations weaken my project’s grade?
No — the opposite. Supervisors and external examiners read a precise limitations section as evidence of methodological maturity. What weakens a grade is a limitation stated so vaguely that the panel cannot tell whether you understand its effect on your results.
What is the difference between a limitation and a research gap?
A limitation is a constraint on your own study’s scope or method. A research gap is an unanswered question in the wider literature that your Chapter Two identified before you started. They can overlap — your limitation might point to the same gap — but a gap is about the field, and a limitation is about your specific study.
Should I mention limitations during my project defence even if I don’t get asked?
Yes, briefly, if you have the chance during your summary — it signals to the panel that you understand your project’s boundaries before they have to ask. If you are asked directly, answer with the specific constraint and its effect, the same way you wrote it in Chapter Five, rather than a general apology.
Can a small sample size be both a delimitation and a limitation?
It can be either depending on why it happened. If you chose a small, defined sample on purpose (say, one faculty rather than the whole university) to keep the project feasible, state it as a delimitation in Chapter One. If the sample ended up smaller than planned because participants did not respond or an organisation withdrew access, that is a limitation to report in Chapter Five.
Do limitations apply differently to a system-development project than to a survey-based project?
The categories differ but the principle does not. A system-development project’s limitations usually concern dataset, testing environment, and evaluation method, as covered above; a survey-based project’s limitations usually concern sample size, response rate, and self-report bias. Either way, state the constraint and its concrete effect on what your results can and cannot support.
Tesify’s AI editor flags a vague or unscoped limitations paragraph the same way a supervisor would, and its Chapter Five templates keep your limitations, recommendations, and contribution to knowledge lined up so a panel can trace one to the other. Start on the free plan to draft yours alongside the rest of Chapter Five.