How to Write Chapter 1 (Introduction) for Capstone Project — With Examples

How to Write Chapter 1 (Introduction) for Capstone Project is one of the most common questions asked by BSIT students. Many already have a solid project idea and the technical skills to build it, but when it comes to writing the introduction, they often get stuck.

The blank page wins, deadlines slip, and adviser sign-offs get pushed back another week.

The fix is structural. Chapter 1 is not a creative writing assignment; it is 7 specific sections with predictable shapes. Once you know the shape of each section, you can write a defendable Chapter 1 in 4-6 hours, not 4-6 days.

This guide walks through all 7 sections — what each one says, what your panel is looking for, and word-for-word examples you can adapt for your own system.

If you have not yet picked a topic, start with our 150+ Best Capstone Project Ideas (2026) first. If you already have a topic, this guide gets you from blank page to finished Chapter 1 (Introduction) for Capstone Project today.

Part of our complete capstone documentation series:

• Chapter 1: Introduction (you are here)
• Chapter 2: Review of Related Literature (RRL)
• Chapter 3: Methodology
• Chapter 4: Results / Implementation (coming soon)
• Chapter 5: Recommendations / Conclusion (coming soon)
• Full Chapter 1-5 Template (Free Download)

About the running example. Throughout this guide, we use a Barangay Information System as the worked example — chosen because it has a clear domain, real stakeholders, and matches the Philippine BSIT context.

Your system might be a Library Management System, Hospital Management System, Inventory System, Attendance Tracker, AI Chatbot, or anything else. The 7-section structure is the same. Only the specifics change. Adapt the framing, swap the domain, write your own sentences.

What Chapter 1 actually is (and what it is not)

Chapter 1 is the introduction to your capstone documentation — not the introduction to programming or to the technology. It introduces YOUR SPECIFIC project: what problem you solved, who you solved it for, and why it matters.

Your panel reads Chapter 1 first; if it does not make them want to keep reading, the rest of your defense gets harder.

Chapter 1 is also NOT a technical document. Do not paste code, screenshots, or database schemas here. That belongs in Chapter 3 (Methodology) and Chapter 4 (Results). Chapter 1 is pure prose — the story of why your system needed to exist.

The voice should be formal but readable. Third person, past tense for the research process, present tense for what your system does. Most panels in Philippine BSIT programs reject Chapter 1 drafts written in first person (“I made the system”) or marketing tone (“This amazing solution will revolutionize…”). Stay calm and academic.

The 7 sections every Chapter 1 needs

Most Philippine BSIT and BSCS capstone templates require these 7 sections in this order. Adjust slightly based on your school’s specific template — some add Theoretical Framework, some combine Significance with Scope, but the core structure is consistent across CHMSC, USLS, UP, Mapua, Adamson, and most other Philippine programs:

1. Background of the Study — context for the problem (~400 words)
2. Statement of the Problem — the specific problem your system addresses (~300 words)
3. Objectives of the Study — general + specific objectives (~250 words)
4. Significance of the Study — who benefits and how (~300 words)
5. Scope and Limitations — what your system DOES and DOES NOT do (~250 words)
6. Definition of Terms — domain-specific vocabulary (~200 words)
7. Conceptual Framework (optional but recommended) — visual model of your system (~200 words)

Target total: ~1,900 words. Most schools want Chapter 1 to be 1,500-2,500 words. Less than that signals you did not think enough; more than that signals you padded with background or definitions that belong in other chapters.

Section 1: Background of the Study (~400 words)

What this section does

It gives the panel three things in this order: (1) the broad context of the problem area, (2) what currently exists in that area, and (3) what is still missing or broken — which leads into the gap your system fills.

The 3-paragraph structure that always works

This template works for management systems, AI projects, and almost every capstone domain. Adapt the specifics, keep the structure:

1. Paragraph 1 — Broad context: 4-6 sentences about the problem domain in general. Use statistics if you have them. Cite the source of any number. Example opening: “In the Philippines, over 18,000 barangays serve as the smallest political unit of local governance, each handling resident records, business permits, blotter reports, and certificate issuance for an average of 2,500 residents (Philippine Statistics Authority, 2024).”
   
2. Paragraph 2 — Current state: 4-6 sentences about how the problem is currently handled. What systems exist? What manual processes are still in use? What are the consequences? Example: “Most barangays in Negros Occidental still maintain resident records using paper logbooks and Microsoft Excel files. Certificate of indigency requests often take 2-3 working days to process because clerks must manually search through binders dating back to 2018…”
   
3. Paragraph 3 — The gap: 4-6 sentences that name the specific problem your system solves and why existing solutions are insufficient. This paragraph leads directly into Section 2 (Statement of the Problem). Example: “However, paper-based and Excel-based barangay information systems suffer from data redundancy, slow retrieval times, and zero backup against fire or flood damage. Existing commercial barangay systems cost between PHP 80,000 and PHP 250,000 per installation, putting them out of reach for most rural barangays. This gap motivates the development of a free, web-based barangay information system that…”

Worked example — Barangay Information System

Here is a complete 400-word Background of the Study written using the 3-paragraph structure. Adapt the specifics to your own system:

In the Philippines, over 18,000 barangays serve as the smallest political unit of local governance, each handling resident records, business permit applications, blotter reports, and certificate issuance for an average of 2,500 residents (Philippine Statistics Authority, 2024). The barangay also acts as the first point of contact for government services in both urban and rural communities, making efficient record-keeping critical to local governance.

Recent surveys by the Department of the Interior and Local Government suggest that more than 60% of rural barangays still rely on paper-based or spreadsheet-only record systems for daily operations (DILG, 2023).

In Barangay [name], the current resident information system consists of paper logbooks dating back to 2018, supplemented by three Microsoft Excel files maintained inconsistently by the barangay secretary. Certificate of indigency requests typically take 2 to 3 working days to process because clerks must manually search through binders to verify resident status.

Blotter reports are recorded in a separate physical notebook, and there is no connection between resident records and the blotter file. The current system also has no backup; a single fire, flood, or termite infestation would destroy years of data.

However, paper-based and Excel-based barangay information systems suffer from data redundancy, slow retrieval times, and zero protection against natural or human-caused data loss. Existing commercial barangay information systems cost between PHP 80,000 and PHP 250,000 per installation, putting them out of reach for most rural barangays in the Philippines.

This gap motivates the development of a free, web-based barangay information system that consolidates resident records, certificate issuance, and blotter reports into a single database with automated backup. The proposed system aims to reduce certificate processing time from days to minutes while providing a foundation that other barangays in the municipality can adopt at no licensing cost.

Common mistakes panels reject

• ❌ Opening with “Technology is everywhere these days…” (generic and lazy)
• ❌ Listing definitions or features (those go in other sections)
• ❌ No citation or statistic (the panel will ask “where did this come from?”)
• ❌ Background longer than the rest of Chapter 1 combined (sets wrong proportions)
• ❌ Marketing voice: “Our amazing system will revolutionize barangay management” (the panel is not your customer; cut the sales pitch)

Section 2: Statement of the Problem (~300 words)

What this section does

It names the SPECIFIC problem your system solves, in plain language, with sub-problems broken out as questions. The panel reads this section to verify your project actually addresses a real problem.

The structure: 1 main problem + 3-5 sub-questions

Start with one sentence that names the central problem. Then list 3-5 specific sub-questions your system will answer. Each sub-question should map directly to a feature in your system — if a sub-question has no corresponding feature, either add the feature or drop the question.

Worked example

The main problem this study addresses is the absence of an affordable, computerized resident records management system in Barangay [name], which forces the barangay staff to rely on manual processes that are slow, error-prone, and vulnerable to data loss.

Specifically, this study seeks to answer the following questions:

1. How can the barangay reduce the average certificate of indigency processing time from 2-3 working days to under 15 minutes?
2. How can resident records and blotter reports be linked so that case histories are accessible without searching multiple logbooks?
3. How can the barangay protect records against fire, flood, and termite damage without commercial backup software?
4. How can the system be designed so that future barangay secretaries can use it with minimal training?
5. How can data privacy be protected per Republic Act 10173 (Data Privacy Act of 2012) while still allowing authorized staff full record access?

Common mistakes

• ❌ More than 5 sub-questions (scope creep — your system can’t deliver all of them)
• ❌ Sub-questions not answerable by software (e.g., “Why do residents not pay taxes?” — that is sociology, not your system)
• ❌ Statement of the Problem repeats the Background (use new specific language)
• ❌ Sub-questions that are really feature lists (“How can we have a login page, a search bar, and a print button?” is not 3 questions, it’s a feature list)

Section 3: Objectives of the Study (~250 words)

What this section does

It states what your system will accomplish in specific, measurable terms. Always uses action verbs like “to develop,” “to design,” “to implement,” “to evaluate.” Avoid weak verbs like “to help,” “to improve,” “to enhance” without a specific measurement.

The structure: 1 general + 4-6 specific objectives

The general objective is one sentence. The specific objectives are 4-6 numbered items, each measurable.

Worked example

General Objective:

To develop a web-based Barangay Information System for Barangay [name], Negros Occidental, that consolidates resident records, certificate issuance, and blotter reports into a single database with automated backup and printable certificate templates.

Specific Objectives:

The study specifically aims to:

1. Design and implement a normalized MySQL database storing resident demographics, certificate requests, and blotter reports with proper foreign key relationships;
2. Develop a role-based authentication module for Barangay Captain, Secretary, and Kagawad with different access permissions;
3. Implement an automated certificate issuance module that generates printable indigency, residency, and clearance certificates from stored resident data in under 60 seconds;
4. Develop an integrated blotter management module that links each blotter record to the involved residents’ profiles;
5. Implement a daily automated database backup routine that exports the entire database to a secondary location;
6. Evaluate the system’s usability with at least 10 barangay staff members using the System Usability Scale (SUS) and target a score of 70 or higher.

Common mistakes

• ❌ Objectives that are not measurable (“to improve barangay management” — what does “improve” mean numerically?)
• ❌ More objectives than your system actually delivers (scope creep)
• ❌ Objectives written as features instead of outcomes (“To create a login page” — login is a feature, not an objective)
• ❌ Missing the evaluation objective (most schools require at least one objective focused on measuring success)

Section 4: Significance of the Study (~250 words)

What this section does

Lists who benefits from your system and how. Panels expect 4-7 stakeholder groups, each with a 1-2 sentence specific explanation. Be CONCRETE — “Reduces clerk processing time from 15 minutes to 2 minutes per resident” beats “Helps the barangay.”

Common stakeholder groups for a management system capstone

• The end users (residents, students, customers, patients — whoever your system directly serves)
• The administrators (the staff who run the system day-to-day)
• The organization (the school, barangay, business that adopts the system)
• The researchers (you and your team — what skills you developed)
• Future researchers (your work becomes their reference)
• The community (broader societal impact, often the weakest item — be specific)
• The institution (your university or college — their reputation benefits)

Worked example

To the residents of Barangay [name]: They will receive faster certificate of indigency, residency, and clearance processing — from the current 2-3 working days down to under 15 minutes per request. They can also request certificates without taking time off from work to wait in long lines.

To the Barangay Captain and Secretary: They will have real-time visibility of resident records, certificate volumes, and blotter cases without manually searching binders. The dashboard provides monthly summary reports for use during barangay assembly meetings.

To the barangay itself: Data is automatically backed up daily, protecting years of records against fire, flood, or hardware failure. The barangay also saves an estimated PHP 12,000 per year in paper, printer ink, and physical storage costs.

To the researchers: This capstone provides hands-on experience in full-stack web development, database normalization to 3NF, and user testing with real stakeholders. Skills directly transferable to entry-level IT roles after graduation.

To future researchers: The source code, database schema, and Chapter 1-5 documentation are released under the MIT License and serve as a reference for other barangay information system capstones in Philippine BSIT programs.

Section 5: Scope and Limitations (~250 words)

What this section does

Tells the panel EXACTLY what your system does and does not do. This section protects you in defense — when the panel asks “but does it also handle X?”, your written limitation lets you answer “no, that is outside scope, here’s why.”

The structure: 2 sub-sections

1. Scope — bullet list of features your system delivers
2. Limitations — bullet list of features your system does NOT deliver, with a brief reason for each

Worked example

Scope:

This study covers the development of a web-based Barangay Information System with the following functionalities:

• Resident records management (add, edit, delete, search residents)
• Certificate issuance for indigency, residency, and barangay clearance
• Blotter management with resident profile linking
• Role-based access control (Captain, Secretary, Kagawad)
• Monthly summary reports printable in PDF format
• Daily automated database backup to a secondary file location
• User account management with password reset

Limitations:

This study does not cover:

• Mobile native applications — the system is web-based only, accessible via desktop and mobile browsers. Native Android/iOS apps are outside scope due to the 4-month timeline.
• Online payment integration — certificate issuance does not process payments. Payment is handled offline at the barangay window.
• Multi-barangay coordination — the system serves one barangay per installation. Inter-barangay data sharing is outside scope.
• Biometric authentication — login uses username and password only. Fingerprint or facial recognition is outside scope due to hardware cost constraints.
• Cloud hosting — the system is designed to run on a single local PC at the barangay hall, not deployed to a public cloud server, to remain operational without internet connectivity.

Section 6: Definition of Terms (~200 words)

What this section does

Defines 5-10 domain-specific terms used throughout your documentation. Include both technical terms (PHP, MySQL, ERD, DFD) and domain terms specific to your project (resident, barangay clearance, certificate of indigency for a barangay system).

The structure

Each term gets a bold heading followed by a 1-3 sentence definition. Use operational definitions — define how the term is used in YOUR study, not the general dictionary meaning.

Worked example

Barangay Information System. A web-based application developed in this study that manages resident records, certificate issuance, and blotter reports for a single barangay.

Certificate of Indigency. An official document issued by the barangay certifying that the holder belongs to a low-income household, used for accessing PhilHealth coverage and government assistance programs.

Resident. A person registered in the barangay’s population database who has resided in the barangay for at least six months or who is a registered voter assigned to the barangay.

Role-Based Access Control (RBAC). A security pattern in which user permissions are assigned based on their role (Captain, Secretary, Kagawad) rather than per-user, used to restrict who can issue certificates or modify records.

Normalized Database (3NF). A relational database design that eliminates redundancy by ensuring every non-key attribute depends only on the primary key. This study’s database is normalized to Third Normal Form to prevent data anomalies.

System Usability Scale (SUS). A standardized 10-item questionnaire used to evaluate the perceived usability of a system on a 0-100 scale, where 70+ is considered above average.

Section 7: Conceptual Framework (optional, ~200 words)

What this section does

A visual model showing how your system’s INPUTS become OUTPUTS through specific PROCESSES. The most common form is the Input-Process-Output (IPO) Model. Required by some schools, optional in others. If your school requires Theoretical Framework separately, add it before Conceptual Framework.

The 3 layers of an IPO model

• Input: what enters the system — user data, hardware, software, requirements
• Process: how it is transformed — development methodology, modules built, technologies used
• Output: what the system produces — working application, reports, documentation, deployment

Worked example narrative

The conceptual framework of this study follows the Input-Process-Output (IPO) model. The Input phase consists of resident data collected from existing paper records, the system requirements gathered through interviews with barangay staff, and the development tools (XAMPP, PHP 8.1, MySQL 8.0, Bootstrap 5).

The Process phase applies the Agile Software Development methodology over a 4-month period, divided into four 1-month sprints covering authentication, resident records, certificate issuance, and blotter management. Each sprint includes design, implementation, and user testing with the barangay staff.

The Output phase produces a working web-based Barangay Information System, complete Chapter 1-5 documentation, a defended capstone presentation, and a maintenance manual handed over to the barangay.

[Insert IPO Diagram here — typically drawn in MS Visio, draw.io, or Lucidchart, exported as PNG.]

Chapter 1 writing process — how to go from blank page to finished in 4-6 hours

1. Hour 1: Pick your system topic + write the Background (3 paragraphs). Use the 3-paragraph structure exactly. Do not move on until the Background flows.
2. Hour 2: Write the Statement of the Problem (1 main + 4-5 sub-questions) and Objectives (1 general + 4-6 specific). Each objective should map to a sub-question.
3. Hour 3: Write the Significance (4-5 stakeholder paragraphs) and Scope and Limitations (lists). Be specific in Significance.
4. Hour 4: Write Definition of Terms (8-10 terms) and the Conceptual Framework if required. Draw the IPO diagram.
5. Hour 5-6: Revise. Read aloud (this catches awkward sentences). Fix grammar with Grammarly. Check that every section flows into the next.

Plan a full 8-10 hours total spread across 2-3 sittings if you include adviser review and revisions. Avoid trying to write Chapter 1 in one sitting — your judgment degrades after hour 4.

Common panel questions on Chapter 1 (and how to answer them)

These are the questions your panel will actually ask during defense. Practice your answers before submitting:
“Why is this problem worth solving?”

Your answer should come straight from Section 1 (Background) — the specific gap you identified, plus the stakeholder benefits from Section 4 (Significance). Quote numbers from your Background — they show you researched the problem, not just made it up.
“How did you arrive at these specific objectives?”

Your answer should map each objective back to a sub-question in Section 2 (Statement of the Problem) AND a feature your system delivers. The panel is checking whether your objectives are arbitrary or whether they emerged from the problem analysis.
“Why these scope limits and not others?”

Your answer should reference timeline (4-month semester), team size (3 people), and technology constraints (PHP/MySQL only, no native mobile, no biometric hardware budget). Specific constraints justify specific scope limits.
“Why is your significance section so generic?”

Most students lose points here. Be SPECIFIC: “Reduces clerk processing time from 15 minutes per resident to 2 minutes” beats “Helps the barangay manage residents.” Re-read your Significance — if every sentence could apply to ANY capstone in the world, rewrite with measurable numbers.

Free Chapter 1 template — download and adapt

Skip the blank page by downloading our Chapter 1-5 Template (Free Download) — pre-formatted Word document with placeholders for every section above. Replace placeholders with YOUR system’s details, customize the worked examples, and you have a defendable Chapter 1 in 4-6 hours.

Continue the series

Once Chapter 1 (Introduction) for Capstone Project is done, move on to the next chapter:

• 📚 Chapter 2: Review of Related Literature (RRL) — With Examples
• 🔧 Chapter 3: Methodology
• 📊 Chapter 4: Results / Implementation (coming soon)
• ✅ Chapter 5: Recommendations / Conclusion (coming soon)

Related capstone resources

• 150+ Best Capstone Project Ideas for IT Students (2026) — if you have not picked a topic yet
• 100+ AI Capstone Project Ideas (2026) — for AI-focused projects
• UML Diagrams Library — for Chapter 3 Methodology diagrams
• Database Design Projects — for ER diagrams
• All Project Hubs — find working source code for your chosen topic

About this guide

This guide was written by the editorial team at PIES Information Technology Solutions — working developers who have helped 200+ BSIT students pass capstone defense.

Every example in this guide comes from real defended capstones at Philippine BSIT programs. Have a question or want a custom capstone built? See our Hire Us page.

Now open Google Docs. Type “Chapter 1” at the top. Write your Background paragraph.