Your proposal explains the planned work, its purpose and the evidence that will demonstrate completion.
This guide focuses on software and computing capstones, including BCA, MCA and engineering projects. Use the example and template to prepare your draft, then adapt them to your institution's brief. Here, “guide” means your project supervisor.
What Is a Capstone Project Proposal?
A capstone project proposal is a planning document that explains what you intend to investigate, design or build, why the work matters and how you will complete and evaluate it. It helps a supervisor assess suitability and feasibility before the main work proceeds.
For example, the IISc M.Tech (Online) project guidelines require a proposal to explain the problem's motivation, questions, technical approach, feasibility and work plan. Those are programme-specific requirements, not a universal format.
| Aspect | Proposal | Final report |
|---|---|---|
| Purpose | Present a plan for review | Explain completed work |
| Methods | Proposed approach and rationale | Approach actually followed and changes |
| Evidence | Planned checks; genuine preliminary work if available | Actual results, analysis and limitations |
Use the final-year project report guide when documenting implementation and findings later.
What Belongs in Each Proposal Section?
1. Project title and submission details
Choose a title that identifies the problem or intended output. “Laboratory Equipment Loan Tracker for a College Department” is more informative than “Smart Management System.”
Include student names, roll numbers, programme, department, institution, supervisor and submission date as required. Add signatures and approval sheets only when requested.
2. Background and problem statement
Describe the current situation, affected users and specific difficulty. Support real-world claims with sources or observations you can identify.
For an equipment-loan project, identify how issue and return records are maintained and what difficulty needs investigation. Label an unverified workflow as an assumption.
3. Aim, objectives and research questions
The aim states the broad purpose; objectives describe observable outcomes.
Weak: “Improve equipment management.”
Stronger: “Record equipment issues and returns, restrict actions by role and produce an outstanding-loan list.”
An objective does not need a percentage to be assessable. Define the starting records, action and expected outcome: after a valid return, the loan is closed and the item becomes available; a repeated return leaves that state unchanged. Record the actual result when testing takes place. For research projects, add research questions or hypotheses when appropriate.
4. Existing work and your proposed contribution
Review relevant studies, products or current workflows. Explain what already works, what limitation remains and how your project responds.
Your contribution might be an adaptation, comparison or evaluation. Cite what you consulted and explain your contribution without unsupported novelty claims.
Identify reused datasets, libraries, code or report structures and their applicable usage terms. For example: “We will use an existing database library; our contribution is the loan workflow, record constraints and evaluation.” Follow your institution's attribution and permitted-assistance rules.
5. Scope, exclusions and limitations
Scope defines the users, functions, setting and data covered. Exclusions identify work you will leave out. Limitations explain what your evidence cannot establish.
A tracker might cover one department while excluding purchasing, payments and campus-wide integration. Testing with synthetic records cannot establish real staff satisfaction. Use the capstone scoping guide to define those boundaries before drafting the proposal.
6. Methodology and proposed design
A technology stack identifies tools. A methodology explains the activities, inputs and evaluation that connect those tools to the project question.
Describe requirements gathering, design, implementation and testing, explaining why the approach fits the problem. Include architecture, entity-relationship or data-flow diagrams where useful or required.
For machine learning, identify dataset access, a baseline for comparison, separate training and evaluation data, and suitable metrics. For research, specify sampling, collection and analysis. For hardware, describe components, operating conditions and measurements.
7. Deliverables and evaluation criteria
A deliverable is an output you submit; an evaluation criterion explains how you will judge whether that output meets the intended objective.
List the prototype, design files, test evidence, report and presentation as applicable. For each objective, state the test conditions and expected behaviour. A working screen alone does not establish record accuracy or correct permissions.
Do not promise an accuracy percentage or performance improvement without a reasoned target and a suitable evaluation plan.
8. Resources, budget, responsibilities and permissions
List tools, equipment, skills, datasets and access requirements. Separate available resources from pending dependencies. Assign each unresolved dependency an owner and verification date.
Estimate relevant costs in rupees, noting quantities, assumptions and who supplies each resource. Team proposals should identify responsibility for outputs and integration.
If personal records, participant responses, restricted datasets or controlled equipment are involved, identify required permissions and institutional approvals before collection or access. State what data is necessary, who may access it, where it will be stored, and the retention or deletion arrangements required by your institution. Record pending permission as a dependency with an owner, decision date and proposed fallback; confirm that the fallback still supports the project question.
9. Timeline, risks and fallback plans
Schedule reviewable outputs for requirements, design, implementation, evaluation and documentation. Include integration and corrections rather than allocating the entire period to development.
For each important risk, record its trigger, owner and response. If a dataset remains unavailable at the agreed check date, review an accessible alternative with your guide. A different dataset may change the question, method and conclusions.
10. References and required additions
List cited sources in your department's required referencing style. Include an abstract, literature matrix, approval record or appendices when requested.
Length varies: Duke MIDS specifies no more than four pages excluding references; OnlineUU's MCA guidelines, page 3 specify a 10–12-page synopsis. Neither rule automatically applies to another programme.
Capstone Project Proposal Example
This is a hypothetical software proposal, not an approved project or a report of completed tests.
Title: Laboratory Equipment Loan Tracker for a College Department.
Problem: In this imagined department, separate loan sheets make equipment availability and outstanding returns difficult to reconcile. A real proposal would verify that workflow and cite its evidence before presenting it as fact.
Aim and contribution: Develop a browser-based prototype that records loans and returns in one place and produces an outstanding-loan list. The contribution is a bounded workflow implementation and evaluation, not a claim of a new inventory-management technique.
Scope: One department; synthetic borrower and equipment records; pre-created synthetic staff and administrator accounts. Both roles record issues and returns and view outstanding loans. Administrators also create and edit equipment records. Purchasing, payments, public registration, CSV export and institutional integration are excluded from the baseline.
Existing workflow versus proposed contribution: These are scenario assumptions, not observed college practices or verified gaps in commercial products.
| Planning question | Assumed separate-sheet workflow | Proposed prototype |
|---|---|---|
| Where is the current loan state? | Manually reconciled across sheets | Derived from one transaction store |
| How are conflicting issues handled? | Depends on manual checking | Enforced by defined transaction rules |
| What is the trade-off? | Little application setup | Development, setup and evaluation effort |
Method: Review the assumed workflow with the guide and turn it into agreed scenarios. Model equipment, borrowers and loans; implement server-side permissions and transaction rules using a relational database and a framework the team can support. Evaluate known synthetic cases, record defects and rerun affected checks after corrections. The method tests defined software behaviour; it does not measure real staff satisfaction.
Planned outputs, checks and owners
Student A and Student B are hypothetical owners; replace them with actual names. The other student reviews each owner's evidence.
| Commitment | Planned output | Completion check | Lead |
|---|---|---|---|
| Reproduce setup | Setup guide and synthetic records | A second student follows the guide and obtains the documented accounts and initial records | A |
| Authenticate users | Account and session controls | Valid credentials allow access; invalid credentials fail; logout ends access to protected actions | B |
| Maintain equipment | Administrator workflow | Administrator creates and edits an item; changes persist; direct staff requests to these actions fail | B |
| Record issues and returns | Transaction workflow and history | For each authorised role, valid issue/return updates the expected records; unknown borrowers, unavailable items and invalid or repeated returns are rejected without changing loan state | B |
| Prevent conflicting loans | Database constraints and transaction handling | Reissue fails; two overlapping requests for one available item create at most one active loan | B |
| Enforce permissions | Server-side access controls | Unauthenticated requests fail; unauthorised staff cannot edit equipment; authorised issue/return succeeds; rejected actions leave records unchanged | B |
| Identify outstanding loans | Active-loan list | On unchanged test data, displayed loan IDs match expected active loans and exclude returned items | A |
For the overlapping-request check, begin with one available item, submit two requests and inspect both responses and stored records. Document the request setup and repeat the defined test. Passing it does not establish correctness under every possible execution order.
For each executed check, record the application version, starting data, input, expected result, actual result and evidence. Until execution, mark the actual-result field “not run.” These are planned checks, not achieved results or security certification.
Resources, dependencies and risks
| Item | Assumed availability or decision | Owner and check point |
|---|---|---|
| Development resources | Existing laptops and selected tools; verify compatibility and usage terms | B, end of week 1 |
| Records and demonstration | Synthetic records and local demonstration proposed; acceptability is pending | A, guide review in week 1 |
| Cash budget | ₹0 additional spending assumed; excludes existing equipment and student time | A, revise if hosting or paid tools become necessary |
| Data-access dependency | If real records are mandatory, obtain permission and revise the method before access | A, resolve before collection |
| Delivery risk | No integrated issue-and-return workflow at the end-of-week-4 review | B, review cause and estimates with the guide; simplify optional interface styling if permitted while preserving mandatory functions and assessment evidence |
CSV export is a future extension, not a fallback deliverable. If the core is infeasible, revise the proposal with the guide while preserving mandatory evaluation.
Timeline and assessment evidence
| Weeks | Planned milestone | Review evidence |
|---|---|---|
| 1–2 | Requirements, access checks and proposal review | Agreed scenarios, source notes and dependency decisions |
| 3 | Design and feasibility check | Data model, role rules and review comments |
| 4–6 | Integrated implementation; core workflow review at week 4 | Issue-and-return demonstration, then remaining baseline functions |
| 7–8 | Evaluation and corrections | Repeatable tests, actual results and defect records |
| 9–10 | Final review and submission preparation | Revised report, setup guide and demonstration |
This ten-week schedule is illustrative, not a workload estimate or university rule. Check actual student availability before adopting it. Documentation starts alongside development.
| Illustrative assessment area | Proposed evidence | Coordinator |
|---|---|---|
| Requirements and design | Problem evidence, agreed scenarios, data model and design rationale | A and B |
| Implementation | Complete baseline workflow and versioned source | B |
| Evaluation | Test setup, expected/actual results and defect corrections | A, reviewed by B |
| Documentation and contribution | Setup guide, report, presentation and individual work records | A and B |
Use your actual rubric: this table is not a marking scheme. Review record: example version 0.1; supervisor review planned for week 2; not yet approved. In a real proposal, record the decision, date, requested changes and next owner.
A Capstone Proposal Template You Can Adapt
Use your college's required headings. Under them, complete this connected statement and expand each part with evidence and detail:
We propose to [build or investigate] for [users or study population] to address [specific problem and supporting evidence]. Our objectives are [observable outcomes]. We will use [methods and reasons], producing [deliverables]. Completion will be evaluated through [checks and recorded evidence]. The scope includes [boundaries] and excludes [omitted work]. Required resources are [confirmed and pending items]. [Owner] will verify [dependency] by [date]. Milestones are [outputs and dates]. Main risks and proposed fallbacks are [items]. Proposal version: [version]. Supervisor decision: [actual status and decision date, when available].
Expand this statement under the ten section headings above, adding a budget table and required diagrams or forms. Replace every placeholder before submission.
How to Write a Capstone Proposal in Five Steps
- Extract the requirements. Read the brief, rubric and deadlines. Output: a checklist of actual requirements, avoiding borrowed university rules.
- Define the problem. Identify users, setting and supporting evidence. Output: one focused problem statement with assumptions labelled.
- Map commitments to evidence. Connect each objective to methods, outputs and checks. Output: an assessable plan.
- Verify feasibility. Check time, skills, budget and access. Output: milestones, dependency owners and fallbacks.
- Record the review. Resolve questions with your guide and revise affected sections together. Output: a consistent draft with an accurate decision status.
Common Mistakes and Practical Improvements
- Listing tools instead of methods: Add the requirements, design and evaluation activities that explain how the tools will be used.
- Promising every feature: Preserve a complete core; label optional integrations separately and account for their testing effort.
- Presenting targets as results: Use planned-outcome language until executed work supports an actual finding.
- Leaving access unresolved: Assign each critical permission or resource an owner, check date and review decision.
Advanced tip: investigate the assumption most likely to invalidate the plan first. When adding work, estimate integration and evaluation too; agree what will be removed or deferred if capacity is fixed.
Frequently Asked Questions
How long should a capstone project proposal be?
Use your department's page or word limit. Programme requirements differ, so another university's template should not determine your submission length.
Is a capstone proposal the same as a synopsis?
A synopsis can serve as a short project proposal in some programmes. Confirm the required contents and approval process because institutions use the terms differently.
Do I need an abstract?
Include an abstract if required. Summarise the problem, objectives, proposed method, expected deliverables and evaluation. Write it after the main sections and distinguish planned outcomes from findings.
Which diagrams should a software proposal include?
Include diagrams required by your department or needed to explain the design, such as architecture, entity-relationship, use-case or data-flow diagrams. Not every proposal needs every diagram.
Should I include completed results?
A proposal normally describes planned work. Include genuine preliminary findings if available, clearly separating them from future targets and untested assumptions.
What if dataset access is still uncertain?
Record access as a dependency with an owner and decision date. Agree an acceptable alternative with your guide and revise the scope or method if the replacement changes what can be concluded.
Can I change the topic after approval?
Follow your institution's change process and obtain required approval. Update affected objectives, methods, resources and milestones, recording the reason and actual decision.
Proposal Review Worksheet
Use this worksheet before submission. Record a page, section or evidence reference for each answer. “Pending” identifies work to resolve; it is not an approval.
| Review question | Evidence to record | If unresolved |
|---|---|---|
| Is the problem supported? | Observation or source, and affected users | Verify the claim or label it an assumption |
| Can every objective be evaluated? | Objective → method → deliverable → check | Define the missing link before adding features |
| Does the plan satisfy the rubric? | Actual criterion → planned evidence | Review the gap with the guide |
| Are resources and permissions available? | Confirmed access, or pending item with owner/date | Agree a feasible fallback or revise the plan |
| Is the contribution clear? | Reused sources/components and original work | Attribute reuse and narrow the contribution claim |
| Is the commitment consistent? | Matching scope, design, tests and milestones | Update conflicting sections together |
Copy a review record: Issue: [item]. Evidence: [reference]. Status: [ready / pending / revise]. Owner: [name]. Resolve by: [date]. Supervisor decision: [actual decision when available].
Before You Submit Your Proposal
After using the review worksheet to assess the plan, check the submission itself:
- Required headings, document length and section order match the current brief.
- Student details, proposal version and actual approval status are present.
- In-text citations and reference entries match; reused materials are acknowledged.
- Required diagrams, captions and cross-references are readable and consistent.
- Required forms are attached, with signatures only where actually obtained.
- File format, filename, submission route and deadline have been checked.
Start with your problem statement and objective-to-evidence table, then take both to your guide. If your topic is still unsettled, browse FileMakr's final-year project ideas and adapt any example to your own contribution and assessment requirements.
