FYP Proposal: How to Write One Your Supervisor Approves (with Template)

The FYP proposal is the first formal document of your final year, and for many groups it is the first technical document they have ever written. It decides whether your idea is approved, sent back for changes, or rejected.

Supervisors are not looking for long proposals. They are looking for a clear problem, a scope you can finish, and a plan that shows you have thought about how.

This guide walks through each standard section of a final year project proposal, gives you a fill-in template, and adds short notes on the documentation, report format and viva that follow it.

One rule first: every university, and often every department, has its own proposal format, page limit and submission process. Treat this guide as a way to understand what each section is for. Then follow your department's official template and your supervisor's instructions exactly, wherever they differ from what is written here.

What a supervisor looks for in a proposal

A supervisor approves a proposal when it answers three questions convincingly: is the problem real, is the scope achievable by this team in the time available, and do the students understand how they will build it?

Common reasons proposals come back:

• A solution looking for a problem. "An AI-based platform" with no user and no clear task.
• Scope that cannot be finished, or so small it is a lab assignment.
• Copied literature review that lists papers without comparing them to your idea.
• Tools named without reasons. Saying "React, Node, MongoDB" is not a methodology.
• No timeline, or one where everything is "in progress" until the last month.

If you are still deciding on the idea itself, start with how to choose a final year project and come back once you have one sentence describing it.

The standard sections of an FYP proposal

Most computing departments in Pakistan ask for some version of the sections below. The names and order vary; the questions they answer do not.

Section	The question it answers	Typical length
Title	What is it, in one line?	One line
Abstract	What, for whom, how, and what result?	150-250 words
Problem statement	What is wrong today, and for whom?	Half a page
Objectives	What exactly will you deliver?	3-6 bullet points
Scope	What is in, and what is deliberately out?	Half a page
Literature review / existing systems	What already exists, and how is yours different?	1-2 pages
Methodology	How will you build and test it?	1 page
Tools and technologies	What will you use, and why?	Short table
Timeline	When will each part be done?	Gantt chart
Deliverables	What will you hand in?	Bullet list
References	Where did your claims come from?	As needed

Writing each section

Title

Make it specific and plain: what the system does, for whom. "WhatsApp-Based Appointment and Reminder System for Small Clinics" beats "Smart Healthcare Using AI". Avoid buzzwords you cannot defend in the viva.

Abstract

Write it last, even though it comes first. Four sentences are enough: the problem, the proposed system, the method or technology, and the expected outcome.

Problem statement

Describe the current situation and who suffers from it, with evidence: an interview with a clinic manager, a count of messages, a process you observed. Do not describe your solution here.

Objectives

Write objectives you can tick off at the end. The SMART pattern (specific, measurable, achievable, relevant, time-bound) is a useful check (SMART criteria). "To develop a system that allows patients to book, cancel and reschedule appointments via WhatsApp" is checkable. "To improve healthcare" is not.

Scope

List what the system will do and, just as important, what it will not do. "Out of scope: online payment, multi-branch clinics, Pashto voice input" protects you when someone asks for more features in the mid-term evaluation.

Literature review and existing systems

Review three to six existing systems or papers, and compare them in a small table: what each does, what it lacks, how your project differs. Google Scholar finds papers; a reference manager like Zotero keeps citations tidy.

Methodology

Say how you will work and how you will know it works. Name a development model (for most groups, an iterative or agile approach with short cycles), how you will gather requirements, the high-level architecture, and how you will test and evaluate it, including any accuracy or performance measure.

Tools and technologies

A short table of tool, purpose and reason. "Postgres: relational data with bookings and users; the team has used it in the database course." Reasons show judgement.

Timeline

A Gantt chart across both semesters, with the proposal, requirements, design, development sprints, testing, documentation and defences as rows (Atlassian on Gantt charts). Leave a buffer before the final submission. Mermaid can draw one from text if your department accepts it.

Deliverables

List what you will submit: the working system (source code and deployed link or build), the final report, user manual, presentation, and any dataset or trained model.

References

Use the citation style your department specifies. IEEE style is common in computing (IEEE reference guide); check before you format anything.

FYP proposal template

Copy this into your own document, replace every bracket, and then reshape it to match your department's official template.

FINAL YEAR PROJECT PROPOSAL

Project title:      [What the system does, for whom]
Program / session:  [BS Computer Science / Software Engineering / IT / Data Science, session]
Group members:      [Name, roll number, email] x [2-4]
Supervisor:         [Name, designation]
Co-supervisor:      [If any, e.g. industry contact]

1. Abstract (150-250 words)
   Problem: [...]  Proposed system: [...]  Method: [...]  Expected outcome: [...]

2. Problem statement
   Current situation: [...]
   Who is affected and how (with evidence): [...]

3. Objectives
   1. To develop [...] that allows [user] to [task].
   2. To integrate [...] for [...].
   3. To evaluate [...] by measuring [...].

4. Scope
   In scope:     [feature], [feature], [feature]
   Out of scope: [feature], [feature]

5. Literature review / existing systems
   | System or paper | What it does | Limitation | How ours differs |

6. Methodology
   Development model: [...]
   Requirements gathering: [interviews, observation, survey]
   Architecture: [front end] -> [API] -> [database] -> [AI / integration]
   Testing and evaluation: [unit tests, user testing with N users, accuracy on held-out data]

7. Tools and technologies
   | Tool | Purpose | Why this one |

8. Timeline (Gantt chart)
   Semester 1: proposal, requirements, design, prototype
   Semester 2: development sprints, testing, documentation, final defence

9. Deliverables
   Source code (Git repository), deployed system or build, final report,
   user manual, presentation, [dataset / trained model]

10. References
   [1] [Author], "[Title]," [Source], [Year]. [URL]

From proposal to documentation and report format

The proposal grows into your final report, so write it in a way you can reuse. Departments set their own report format, but most computing FYP reports follow a similar chapter structure:

1. Introduction: background, problem statement, objectives, scope (largely from your proposal).
2. Literature review: an expanded version of the proposal's comparison.
3. Requirements: functional and non-functional requirements, use cases or user stories.
4. System design: architecture, database design, diagrams (use case, class, sequence, ERD as your department requires).
5. Implementation: key modules, algorithms, integrations, with short code excerpts only where they help.
6. Testing and evaluation: test cases, results, user feedback, performance or accuracy measures.
7. Conclusion and future work: what you achieved against each objective, limitations, next steps.

Appendices usually hold the user manual, extra screenshots and survey forms. Check your department's rules on fonts, margins, page numbering, plagiarism reports and binding before the last week, not during it.

Write as you build. Finish the design chapter when the design is done, the implementation chapter during the sprints. A report written in the final fortnight reads like one.

Preparing for the viva

The viva tests whether you understand your project, and examiners usually question each member separately.

• Know your own part deeply and every other part well enough to explain it.
• Run the demo from a clean start at least three times, on the machine and network you will use. Keep a recorded backup video.
• Prepare for "why" questions: why this database, this model, this framework, and what you would change.
• Know your numbers: users tested, response times, accuracy, and how you measured them.
• Practise out loud with someone who asks hard questions.

Using AI tools to understand a concept is one thing; submitting work you did not do is another. Follow your department's academic integrity policy. Buying or outsourcing an FYP is misconduct, and the viva is exactly where it shows.

FYP proposal FAQ

Is there one official FYP proposal template in Pakistan?

No single national template applies to every department. Your department or FYP committee issues its own, so ask your FYP coordinator or supervisor for the current version before you start writing.

Where do I find the AWKUM FYP format?

Ask your department's FYP coordinator or supervisor at Abdul Wali Khan University Mardan for the current proposal and report templates, and follow them over any online sample, including this one. The same applies at every other university.

How long should an FYP proposal be?

Whatever your department specifies. When there is no limit, 6-10 pages is usually enough to cover every section properly.

Can my proposal include an AI component?

Yes, if it serves the problem. State exactly what the model does, where its data comes from and how you will measure whether it works.

Key takeaways

• Follow your department's official template and your supervisor's instructions above any general guide.
• A proposal is approved when the problem is real, the scope is achievable and the method is clear.
• Write measurable objectives and an explicit out-of-scope list.
• Compare existing systems in a table instead of listing papers.
• Plan a two-semester timeline with documentation running alongside development.
• Prepare for the viva by knowing every part of the project and the reasons behind each decision.

Get mentorship for your FYP

Softhat mentors final-year students at our Mardan, Khyber Pakhtunkhwa office or remotely: idea selection, the proposal, scope, architecture, weekly code reviews, AI integration, deployment, documentation structure and viva practice. Your group writes the proposal and builds the project; we review, question and guide. See FYP mentorship, and if you are still choosing an idea, browse our final year project ideas for computer science.

Ask about FYP mentorship