How to Draw the Conceptual Framework (IPO) of a BSIT Capstone Project, Step by Step (Philippines, 2026)

To draw the conceptual framework of a BSIT capstone, write your objectives, list what the project takes in (requirements, users, tools), list what you do with it (the development and testing activities), state what comes out (the system, documentation and evaluation results), add a feedback arrow, and write a paragraph explaining each box. The result is an input-process-output (IPO) diagram that matches your objectives line by line.

Plan your capstone chapters on Tesify

What is an IPO framework in a capstone, and what is it not?

The input-process-output model is a widely used approach in systems analysis and software engineering for describing the structure of an information processing program or other process. It is one of the most basic ways to describe a process, which is why Philippine IT programs use it for capstone projects. In a capstone, it shows what your project takes in, what your team does, and what the project produces.

It is not the same as a theoretical framework. The theoretical framework names the theories or models behind the study, such as the technology acceptance model for an evaluation of usability. The conceptual framework is yours: it shows how your project works. It also differs from the independent-dependent variable diagram used in a purely quantitative thesis. A capstone usually builds something, so IPO fits, and you may add a second diagram of variables only if you also test relationships. A comparison of IPO and IV-DV diagrams for other courses is in conceptual framework and research paradigm examples, and the general method is in how to make a thesis conceptual framework. This guide is specific to a system development capstone.

Step 1: Write your objectives first

Do this: list your general and specific objectives, for example: to design and develop an online document request system for a barangay (illustrative), to evaluate its quality using a chosen instrument, and to determine user acceptance.

Expected output: three to five objectives, each beginning with a verb. Every box in your diagram must trace back to one of them. If you cannot link a box to an objective, delete it or add an objective.

Step 2: List the inputs

Do this: write everything the project needs before development starts. Group them into four kinds:

• User requirements: what the users need, gathered through interviews, observation or document review.
• Existing process or system: the manual or old process you are replacing, as documented in your Chapter 1 background.
• Tools and platform: hardware, software, programming languages, framework and database that you will use.
• People: the client, end users and your adviser or technical expert.

Expected output: a short list of three to six inputs. Use nouns, not sentences. Write “interview results from barangay staff,” not “we will interview the staff.”

Step 3: List the process

Do this: write the activities your team performs, in the order they happen. Use the software development method you chose in Chapter 3. For example, with an iterative or agile approach: requirements analysis, system design, development, testing, deployment and evaluation. A comparison of methods and how to document your choice is in what method an IT capstone should use. The process box should name the method, so that the framework and Chapter 3 agree.

Expected output: four to six verbs or verb phrases in order. Under design, you may list the design artefacts you will produce, such as use case diagram, entity relationship diagram and data flow diagram. Under testing, name the kinds you will do, such as unit testing, integration testing and user acceptance testing.

Step 4: List the outputs

Do this: write what exists when the project ends. Outputs are results, not activities:

• The developed system with its main modules.
• Documentation: user manual, technical documentation and this manuscript.
• Evaluation results: the quality or acceptance scores that answer your objectives. Instruments for that evaluation are compared in ISO 25010 vs SUS vs TAM for capstone evaluation.
• Recommendations for improvement.

Expected output: three to five outputs that you can show to the panel during the defense.

Step 5: Add the feedback arrow

Do this: draw an arrow from the outputs, specifically the evaluation results and user comments, back to the process. This shows that you will improve the system based on feedback, which is true of any iterative approach.

Expected output: one arrow with a short label such as “feedback from users and evaluators.”

Step 6: See it in a worked example

Here is an illustrative framework for a “Barangay Online Document Request System.” The content is invented to show the structure. Adapt each cell to your own project.

In the final manuscript, convert this table into a figure with three large boxes labelled Input, Process and Output, arrows from left to right, and the feedback arrow underneath returning from Output to Process.

Three more illustrative frameworks, by type of system

The structure stays the same, but the content of each box changes with what you build. These rows are invented examples to show the pattern.

Notice that none of the three rows lists a programming language as the whole input. The tools are one item among several. Panels frown on frameworks that read like a shopping list of technologies, because a capstone is judged on whether it solves the stated problem for real users.

What if your capstone is also a research study?

Some programs expect the capstone to test something, for example whether users accept the system. In that case, keep the IPO figure for the project and add a second, smaller diagram for the research part, usually independent variables such as perceived usefulness and perceived ease of use pointing to a dependent variable such as intention to use. That second diagram needs its own theory, hypotheses and instrument, which is why it belongs in the theoretical framework section and in the evaluation chapter. Do not merge the two diagrams into one crowded figure. A reader should be able to tell at a glance which diagram describes what you built and which describes what you measured.

Step 7: Write the narrative paragraph

A diagram alone is not accepted. Under the figure, write a paragraph that walks through the boxes. A template to adapt:

“Figure 1 presents the conceptual framework of the study. The input consists of [list inputs]. These serve as the basis of the process, which comprises [list process steps] following the [method] approach. The output is [list outputs]. Feedback from [users and evaluators] is returned to the process to improve the system.”

Then add one sentence connecting the framework to your objectives, for example: “The evaluation results correspond to Specific Objective 2.” That sentence is what shows the panel that the framework is not decoration.

Step 8: Format the figure in APA 7

1. Place the figure number above the figure in bold, for example “Figure 1.”
2. Put the figure title below the number, in italic title case, such as “Conceptual Framework of the Barangay Online Document Request System.”
3. Use readable text, consistent boxes and no decorative clip art.
4. Mention the figure in the text before it appears.
5. If you adapted the framework from another source, add a note citing it.

Step 9: Check for consistency before you submit

• Every specific objective is answered by at least one output.
• The process box uses the same method name as Chapter 3.
• Terms in the figure match the terms in your definition of terms and statement of the problem.
• The evaluation instrument named in the outputs matches Chapter 3.
• The system modules in the outputs match the modules in your scope and delimitation.

The balance between building and researching in a capstone is discussed in software project versus research thesis in BSIT and BSCS, and the documentation that supports your outputs is covered in capstone documentation from the artifacts you already built.

What mistakes do capstone panels flag in the framework?

• Listing activities in the input box, such as “coding,” which belongs in the process.
• Showing the technology stack as the whole framework, with no users or requirements.
• Leaving out the output that answers your evaluation objective.
• Using a different method name in the figure than in Chapter 3.
• Copying a framework from another capstone without changing it to your system.

Frequently asked questions

Is the conceptual framework of a capstone the same as the theoretical framework?

No. The theoretical framework names the theories or models behind your study. The conceptual framework shows how your own study turns inputs into outputs. Many capstones have both.

Do I need an IPO diagram or an IV-DV diagram?

A system development capstone normally uses IPO. If you also test relationships between measured variables, such as usability and user satisfaction, add an IV-DV diagram.

Where does the framework go in the manuscript?

Usually in Chapter 1 or Chapter 2, depending on your school’s format, right after the theoretical framework.

Should the framework show the system architecture?

No. The architecture diagram belongs in Chapter 3 or 4. The conceptual framework is higher level: what goes in, what you do, what comes out.

What tool should I use to draw it?

Any diagram tool your school accepts, such as a drawing app or presentation software. Keep boxes aligned, text readable and the figure numbered.

How many boxes should each column have?

As many as your study needs, but keep each column short enough to read at a glance. Three to six items per column is common.

What is the feedback arrow for?

It shows that evaluation results and user comments return to the process to improve the system, which is how iterative development works.

Can the framework change after the proposal defense?

Yes, if the scope or method changed, but update the objectives, the Chapter 3 method and the figure together so they still agree.