FYP proposal format: what every section must contain
A final year project proposal is a short document, usually eight to fifteen pages, that convinces your supervisor and the FYP committee that the problem is real, the scope is finishable in two semesters, and your group can build it. This page sets out every section, what belongs in it, and the mistake that gets each one sent back.
Formats differ slightly between departments, so take your own FYP handbook as final. The structure below is the one almost every Pakistani computer science and software engineering department asks for, in the order they ask for it.
Download the template
A blank proposal with every section below already laid out: title page, abstract, problem statement, objectives, scope, a literature review table, methodology, a tools table, architecture, a two-semester timeline table, deliverables, references and the supervisor approval page. Guidance notes sit in grey italics for you to delete, and the blanks you fill are marked in blue.
Download Word template (.docx)Download PDF version
Free, and no email required. Your department handbook overrides this template — check its font, margins and cover sheet before you submit.
The sections, in order
| Section | What goes in it | What gets it rejected |
|---|---|---|
| Title page | Project title, group members with roll numbers, supervisor name, department, university, submission date. | A title that describes a technology instead of a problem. |
| Abstract | 150 to 250 words: the problem, your solution, the main technologies, the expected outcome. | Written last and read first — most are vague because nobody rewrote them. |
| Introduction | Context, who is affected, why it matters now. | Two pages of general background about the industry with no specific user. |
| Problem statement | One paragraph. A specific group of people, a specific difficulty, and what it costs them today. | “There is no proper system” — true of everything, proves nothing. |
| Objectives | Three to five, each measurable and each a thing you can demonstrate at the end. | Objectives that cannot be tested, like “to improve efficiency”. |
| Scope | What the system will do, and an explicit list of what it will not do. | No exclusions. Scope without limits is the single biggest cause of unfinished FYPs. |
| Literature review / existing systems | Three to six comparable systems or papers, with what each does and where it falls short. | Descriptions with no comparison, so the gap your project fills never appears. |
| Proposed methodology | Your development model (incremental, agile, waterfall) and why it suits this project. | Naming a model you will not actually follow. |
| Tools and technologies | Languages, frameworks, database, hosting, and the hardware if any. | A long list that includes things nobody in the group has used. |
| System architecture | A block diagram showing the main components and how data moves between them. | A screenshot of a generic three-tier diagram with no project-specific labels. |
| Work plan and timeline | A Gantt chart or table across both semesters, with deliverables per month and who owns each. | Every task ending in the last two weeks. |
| References | Papers, documentation and systems you cited, in your department’s style. | Blog links with no date or author. |
Writing the problem statement
This is the paragraph supervisors read twice. A weak one reads: “There is no proper system for managing hostels, which causes problems for students.” It names no one and measures nothing.
A strong one names the people, the current method and the cost of it: “Students moving to Rawalpindi for university find hostels through WhatsApp groups and roadside boards. They cannot compare price, distance or facilities before visiting, so a typical search takes several days of travel, and hostel owners lose enquiries they never hear about.”
The test is simple: could a stranger repeat your problem statement back and name who is suffering and what it costs them? If not, it is not finished.
Objectives that survive the defense
Each objective should be a sentence that starts with a verb and ends with something you can show on screen. Compare:
- Weak: To improve the hostel booking experience.
- Strong: To let a student filter hostels by price, distance from campus and facilities, and see results in under two seconds.
- Weak: To use machine learning in the system.
- Strong: To recommend three hostels to a student based on their previous searches, and measure whether the recommended ones are opened more often than random ones.
Three strong objectives beat seven weak ones. The committee will ask you to demonstrate each one at the final defense, so write only what you intend to build.
Scope: the section that decides whether you finish
Most FYPs that fail do not fail because the idea was too hard. They fail because the scope never had a boundary, so the group kept adding features and ran out of semester.
Write scope as two lists. In scope: the features you will demonstrate. Out of scope: the obvious next features you are deliberately not building, and one line each on why. Naming exclusions is not a weakness in a proposal; supervisors read it as a group that understands its own timeline.
A good rule: whatever you think you can build in two semesters, write down two thirds of it.
The timeline most groups get wrong
Departments usually want a Gantt chart across both semesters. The common mistake is loading all the development into the second semester and leaving the first for “research”.
| Phase | When | What exists at the end of it |
|---|---|---|
| Requirements and design | Semester 1, first third | SRS draft, use case and ER diagrams, wireframes. |
| Core build | Semester 1, rest | Database plus the one feature the whole project depends on, working. |
| Remaining modules | Semester 2, first half | The rest of the in-scope features, integrated. |
| Testing and documentation | Semester 2, third quarter | Test cases run and recorded, final report written. |
| Deployment and defense prep | Semester 2, last weeks | Deployed build, demo video, slides, rehearsed viva. |
If your mid-year evaluation arrives and nothing runs, the second semester turns into a rescue. Have one real feature working before the first semester ends.
Before you submit
- Open your department’s FYP handbook and check font, margins, heading numbering and the cover sheet. Proposals get returned for formatting more often than for content.
- Read the problem statement aloud. If you lose the thread, so will the committee.
- Check every objective appears somewhere in the timeline.
- Make sure the title matches what you are actually building, not what sounded impressive in week one.
- Have someone outside your group read it who does not know the project.
Still deciding what to propose? Browse 70 FYP ideas for computer science students, or filter them by interest and difficulty with the FYP idea generator.
FYP proposal questions
How long should an FYP proposal be?
Usually eight to fifteen pages, excluding the title page and references. Check your department handbook, because some set a hard limit. Length is never the thing that gets a proposal accepted; a precise problem statement and a bounded scope are.
What is the difference between the proposal and the final documentation?
The proposal argues that the project is worth doing and can be finished. The documentation records what you actually built: full SRS, design diagrams, test cases and results. The proposal is written before the work, the documentation during and after it.
Can two groups choose the same project idea?
Departments usually allow it only if the scope or approach differs clearly. Since committees see the same ideas every year, the groups that get approved quickly are the ones that narrow a familiar idea to a specific user and a specific gap.
Why do supervisors reject proposals?
In order of how often it happens: scope too large for two semesters, a problem statement that names no specific user, objectives that cannot be demonstrated, a technology stack nobody in the group has used, and a timeline with everything at the end.
Do I need a literature review at proposal stage?
Most departments want a short one: three to six existing systems or papers, each with what it does and where it falls short. The purpose is to show the gap your project fills, so a list of descriptions without comparison does not count.
What file format do I submit in?
Nearly always a printed and signed hard copy plus a PDF, with the supervisor’s signature on the cover sheet. Write it in Word or LaTeX, but submit PDF so your formatting survives.
Next
Once the proposal is approved, the next document is the SRS and the rest of the FYP documentation. Students also find these useful: FYP ideas, internships for computer science students, and the CV that gets shortlisted for the job hunt after. If you want a real company problem as your topic, read how to get an industry-based final year project.