A final year project report documents an engineering or computing project you designed, built, and tested in the last year of your degree: what you set out to do, how you did it, whether it works, and what is still missing. Your department sets the chapter list and the format, and, in the guides quoted here, a supervisor and a committee or panel read the result. This page quotes five department guides from India, Pakistan, Nigeria, and the US, and shows what to check in your draft.
No one sees their own blind spots, with or without AI help. Esmond points them out in your draft from within your field, along with factual errors and inconsistencies.
The project is something you make: a system, a device, software, or an experiment. The Department of Software Engineering at the National University of Modern Languages (NUML) in Islamabad describes its project this way: “The FYP involves proposal, design, and development of a real and substantial project related to software engineering.”
The report has to show the work to a reader who never saw your lab bench or your code: which choices you made and why, how you tested it, and how far it meets the objectives you set at the start.
A hypothetical example of a commentYour objectives promise fault detection within two seconds, but Chapter 4 only reports that detection works on the test set. Where do you measure the two seconds?
A first comment on one part of your own draft, right away and without an account.
Get a free previewDepartment templates differ in names and order, so compare this with the template your department gives you. Three published layouts:
| Purpose | IUST, B.Tech. CSE (India) | ABU, B.Eng. Civil (Nigeria) | Illinois, ECE 445 (US) |
|---|---|---|---|
| Problem and objectives | Introduction | Introduction | Introduction |
| What is known | Background and literature review | Literature review | Covered in the introduction |
| What you designed and built | Work carried out | Materials, methodology, and tools | Design |
| Whether it works | Experimental results and comparison | Analysis and discussion of results | Verification |
| Other items | Costs | ||
| What it means and what is next | Conclusion and future scope | Conclusion and recommendations | Conclusions |
The introduction states the problem and the objectives. Objectives you can test make every later chapter easier to judge. You can't test "build a monitoring app". You can test "detect a sensor fault within two seconds on the test rig".
The background or literature chapter places your project among existing work. At the Institute of Aeronautical Engineering in Hyderabad, the B.Tech. guidelines describe the literature review as an evaluation of earlier research that shows the gap your project addresses, and add: “The key word here is evaluation.” Ahmadu Bello University's civil engineering guidelines say the same in their own words: “This chapter should explain what is missing in the literature.”
The design and implementation chapters show what you built and why you built it that way. The ABU guidelines ask that “The relevance of any data collected/generated and/or both tools used must be justified and their limitations pointed out.” They also set a test for the method chapter: “This section should be such that anyone wanting to repeat the work done in the project should be able to do it without difficulties.” For how a method chapter is built in a thesis, see the page on the methodology chapter.
Several of the guides put their weight on the evaluation. The B.Tech. guidelines of the CSE department at IUST Awantipora put it plainly: “It is extremely important that you evaluate what you have done both in absolute terms and in comparison with existing techniques, software, hardware etc.” They warn against claiming complete success: “Even the very best pieces of work have their limitations and you are expected to provide a proper critical appraisal of what you have done.”
The ECE 445 senior design course at the University of Illinois Urbana-Champaign asks for the targets at the start and the proof at the end. In the introduction you “Give the performance requirements as they appear in the final version of your proposal.” In the verification section you “Discuss the testing of the completed project and its major blocks.”, including the tests “needed to prove that the design goals were met.”
In practice that means evidence for each objective: what you measured, under which conditions, and how close you came to the target. A table of requirement, test, and outcome is easier to check than a narrative. If a test failed or a target was missed, report the measured value and the likely cause. For the difference between reporting results and interpreting them, see results and discussion.
The Hyderabad guidelines describe the conclusion chapter as the place where you show what was achieved: “This is where you emphasise that your research aims/objectives have been achieved.” That claim only holds if the evaluation chapter supports it objective by objective. If one objective was met only in part, the conclusion should say so.
Future work is more useful when it follows from the limitations you found: a test you could not run, a component that did not reach its target, a case your design does not cover. For how to present limitations, see the limitations section.
Some departments prescribe a fixed five-chapter layout, often called "chapter 1-5". ABU's civil engineering guidelines are an example: introduction, literature review, materials and methodology, analysis and discussion of results, and conclusion and recommendations.
Who assesses the report differs by department. At NUML's Department of Software Engineering, the standard operating procedures split the work:
This example is made up. A computer science student builds a mobile app that reads a plant's soil moisture sensor and sends a watering alert. The introduction sets three objectives: alerts within one minute, a battery life of a week on the sensor unit, and a false alarm rate under five percent.
Chapter 4 shows screenshots of the alerts and a graph of moisture over three days in one pot. It reports that alerts "arrived promptly" and that the system "worked well". Battery life and false alarms are not measured. The conclusion states that all objectives were achieved.
A reader would ask how long the alerts took, how long the battery lasted, and how many alerts were false. Each question points to a missing measurement.
| Weak spot | How it shows | What to ask yourself |
|---|---|---|
| Objectives you can't test | "Develop an efficient system" | What number or observation would show it was met? |
| Literature as a list | Summaries of tools and papers, no comparison | What do existing solutions miss that your project does? |
| Unjustified design choices | "We used a Raspberry Pi" | Why this option over the alternatives you considered? |
| Testing without targets | Screenshots and "it works" | Which objective does each test check, and what did it show? |
| No comparison | Results of your system only | How does it compare with an existing technique or a baseline? |
| Conclusion beyond the evidence | "All objectives were achieved" | Can you point to the table or figure that shows each one? |
Esmond evaluates every assignment before you submit. It never writes it.
Esmond is an AI tool that doesn't write for you. If your course doesn't allow any AI tools, don't use Esmond for that work. If you're unsure, ask your instructor or advisor.
Esmond reads the draft of your report from within your field and flags factual errors, inconsistencies, and blind spots, for example an objective in Chapter 1 that no test in the evaluation chapter addresses, a design choice without a reason, or a conclusion that claims more than your results show. It adds no text to your report. See the sample report for what comes back, and how Esmond works for the steps.
Esmond doesn't check your report against your department's template, rubric, or similarity rules, and it doesn't run your code, test your hardware, or verify a design or calculation beyond what the report says. What you change is up to you, and your supervisor and committee assess the project.
The report you submit at the end of an undergraduate engineering or computing degree, describing a project you designed, built, and evaluated. In the guides quoted here it runs from introduction and objectives to background, design, testing, and conclusion, in the format your department sets.
The problem, the objectives, and the scope. The IUST guidelines ask for an opening statement of what the project is about that a lay reader can follow, a summary of what you set out to achieve, and the project's background, relevance, and main contributions.
In the IUST guidelines, yes: the evaluation compares your work with existing techniques, software, or hardware. If no direct comparison exists, a baseline or the current manual process can serve, as long as you say why you chose it.
It depends on the department. At NUML's Department of Software Engineering, the supervisor assesses the students against the supervisor's rubric, and a project committee evaluates the proposal, the progress, the final presentation, and the report. Ask your project coordinator who reads yours.
It covers similar ground, but the weight lies on what you built and how you tested it, more than on a research question. The Hyderabad guidelines, for example, use "thesis" and "project report" side by side. Use the term your department uses.
Read on November 7, 2026.
Get your paper evaluated before you submit