A capstone project is different than a thesis is in how you demonstrate your

knowledge. With a project you demonstrate this by “building something”. It may involve
something new (new methodology, etc.). Basically, a project is "applied" knowledge and
learning with the product being the goal. A capstone project tests your
understanding of core concepts in your field of study and requires you to apply
them to current situations. For example, a capstone project might require you
to produce a solution to a business or scientific problem. Capstone projects
don't require original research, but you must perform background analysis,
conduct library research, examine similar projects and review best practices,
according to the University of North Carolina. Capstone projects may be
completed individually or in small groups . Some undergraduate and graduate
programs require students to complete capstone projects to graduate. Consult
your adviser about specific capstone requirements. The main difference
between a capstone project and a thesis is that a capstone project addresses a
specific problem, issue or concern in your field of study, and a thesis attempts
to create new knowledge. A **capstone project focuses on a narrow, specific
topic**, whereas a **thesis addresses a broader, generalized issue**.

A thesis paper differs from a capstone project because you must create
new knowledge by developing a hypothesis, conducting data analysis,
assessing your results, drawing conclusions from your research and comparing
your results to others. "A thesis paper feels more like the scientific method than
a field project," according to the University of Wisconsin.

 What makes a GOOD research proposal?

o Relevance, either to the work of the funding body or to the student’s
course.
o The research is unique or offers new insight or development.
o The title, aims and objectives are all clear and succinct.
o Comprehensive and thorough background research and literature review
has been undertaken.
o There is a good match between the issues to be addressed and the
approach being adopted.
o The researcher demonstrates relevant background knowledge and/or
experience.
o Timetable, resources and budget have all been worked out thoroughly,
with most eventualities covered.
o Useful policy and practice implications.
 o PROBLEM
 any significant, perplexing and challenging situation, real or
artificial, the solution of which requires reflective thinking.
 a perplexing situation after it has been translated into a
question or series of questions that help the direction of
subsequent inquiry.
o Elements of a Research Problem
 Aim or purpose of the problem for investigation. This
answers the question “Why?”
 Why is there an investigation, inquiry or study?
 The subject matter or topic to be investigated. This answers
the question “What?”
 What is to be investigated or studied?
 The place or locale where the research is to be conducted.
This answers the question “Where?”
 Where is the study to be conducted?
 The period or time of the study during which the data are to
be gathered. This answers the question “When?”
 When is the study to be carried out?
 Population or universe from whom the data are to be
collected. This answers the question “Who?” “From whom?”
 Who are the respondents?
 From whom are the data to be gathered?

 Characteristics of a Research Problem

Specific
Measurable
Achievable
Realistic
Time-bound

 Specific: The problem should be specifically stated.

 Measurable: It is easy to measure by using research
instruments, apparatus, or equipment.
 Achievable: Solutions to a research problem are achievable
or feasible.
 Realistic: Real results are attained because they are
gathered scientifically and not manipulated or maneuvered.
 Time-bound: Time frame is required in every activity
because the shorter completion of the activity, the
better

 Reasons Why Research Proposals FAIL

o Aims and objectives are unclear or vague.
 o There is a mismatch between the approach being adopted and the issues
to be addressed.
o The overall plan is too ambitious and difficult to achieve in the timescale.
o The researcher does not seem to have conducted enough in-depth
background research.
o Problem is of insufficient importance.
o Information about the data collection is insufficiently detailed.
o Information about the data analysis method is insufficiently detailed.
o Timescale is inappropriate or unrealistic.
o Resources and budget have not been carefully thought out.
o This topic has been done too many times before – indicates a lack in
background research.

 Sources of Research Problem

o Specialization of the researcher
o Current and Past Researches
o Recommendations from theses, dissertations, and research journals
o Original and creative ideas of the researcher based on
the problems met in the locality and country

 Criteria of a Good Research Problem

o Interesting
o Innovative
o Cost-effective
o Relevant to the needs and problems of the people
o Relevant to government’s thrusts
o Measurable and time-bound

 Guidelines in Writing the Research Title

o Research Title must be reflective of its problem.
o It must answer the following questions:
 What are you trying to find out, determine or investigate?
 What are you trying to discover?
 Who are the respondents or subjects of the study?
 Where will the research locale, setting or the place where the
research study is conducted?

CAPSTONE PROJECT FORMAT

Title Page
Executive Summary
 This is a summary of the capstone paper. Write a concise summary
of the key points of your research. Executive Summary should
 contain at least your research topic, research questions/objectives,
methods, results, and conclusions.

Table of Contents
List of Figures, List of Tables, List of Notations
Chapter I
Introduction
 The introduction may range from a paragraph or two to possibly
one page in length. Its purpose is to state the general nature of the
problem. Note that this is the general nature and not the problem
itself. It should be brief and it is intended to capture the attention of
the reader. A good introduction should make the reader want to
read more
 The proponent should describe the existing and prevailing problem
situation based on his or her experience. This scope may be
global, national, or regional and local.
 The Introduction is not a summary of the paper. You do
not discuss the outcomes of your work here. This is
entirely about introduction of the context, introduction of
the problem and the methods used.
 Presents a general statement about the study (can be an issue or
claim)
 Presents support about the general statement (organization or
beneficiaries can be introduced also)
 Last paragraph contains either the aims or problems that the study
would want to achieve or solve
- Project Context
 The proponent should introduce the presentation of the problem,
that is, what is the problem is all about.
 The proponent should give strong justification for selecting such
research problem in his/her capacity as a researcher. Being part of
the organization or systems and the desire and concern to improve
the systems.
 The researcher states a sentence or two that would show the link
and relationship of the rationale of the study to the proposed
research problem.
- Purpose and Description
 What is the function of your project?
 What is good in your project?
 What makes your project unique, innovative and relevant?
- Objectives
 Guidelines in Formulating the Objectives of the Project:
o Start with the General Objective which is very parallel to the
project title.
 o Explode the general objective into Specific Objectives that will
help realize the proposed study.
o Objectives should be SMART
- Scope and limitations
 Think the project scope as a box. High-level scope defines the
sides of the box and separates what is relevant to your project from
what is irrelevant.
 The scope refers to the work that needs to be accomplished to
deliver a product, service, or result with the specified features and
functions.
 The scope explains the nature, coverage, and time frame of the
study

 The limitation, on the other hand, explains all that are NOT included
in your project.
 In other words, the scope of the project gives an overview all the
deliverables (i.e. the things that your project gives/delivers), and the
tools and technologies used that will be used in the project
development while the limitations of the project are the boundaries
of the project (i.e. areas/things that are out of scope).
Chapter II
Review of Related Literature/Systems
 Before conducting your own project/study, you need to thoroughly
understand your field and what has already been attempted and
accomplished by others. This chapter is intended to review and
synthesize the information you have found in the process of
researching what others have already accomplished.
 This chapter should not read like a series of book reports. Include
books and scholarly articles but be sure the information is current.
Websites may be included if you can establish the credibility of the site.
Each significant point in your research question(s) and problem
statement should be covered. Anything else, regardless of how
interesting it might be, should not be included.
 A survey or review of related literature and studies is very important
because such reviews literature and studies serve as a foundation of
the proposed study. This is because related literature and studies
guide the researcher in pursuing research venture.

 The following are the different ways on how the review of related
literature and studies help as a guide to the researcher:
o They help or guide the researcher in searching for or selecting a
better research problem or topic.
o They help the investigator understand his topic for research better.
o They ensure that there will be no duplication of other studies.
 o They help and guide the researcher in locating more sources of
related information.
o They help the researcher in making his research design.
o They help and guide the researcher in making comparison between
his findings with the findings of other researchers on similar studies
with the end in view of formulating generalizations or principles
which are the contributions of the study to the fund of knowledge.
 Characteristics of Related Literature and Studies
o The surveyed materials must be as recent as possible.
o Materials reviewed must be objective and unbiased.
o Materials surveyed must be relevant to the study.
o Surveyed materials must have been based upon genuinely original
and true facts or data to make them valid and reliable.
o Reviewed materials must not be too few or too many.

 Sources of Related Literature and Studies

o Books, encyclopedias, almanacs, and other similar references
o Articles published in journals, magazines, periodicals, newspapers,
and other publications.
o Manuscripts, monographs, memoirs, speeches, letters, and diaries
o Unpublished theses and dissertations
o The Constitution, and laws and statues of the land
o Bulletins, circulars, and orders emanating from government offices
and departments, especially from the Office of the President of the
Philippines and the Department of Education
o Records of schools, public and private, especially reports of their
activities
o Official reports of all kinds, educational, social, economic, scientific,
technological, political, etc. from the government and other entities
o Articles from the Internet
 Kahn, J. (n.d.). Sample APA paper. Retrieved from
http://my.ilstu.edu/~jhkahn/APAsample.pdf
 Where to locate related literature and studies?
o Libraries, either government, school or private libraries
o Government and private offices
o The Internet

 This portion of the proposal manuscript contains presentations and

discussions of the following two (2) components:
o Related Theories
 Outline first, starting off with an anchor theory
 Supporting theories help elaborate the anchor theory
 Endnoting and footnoting is important which follows
correct bibliography entry
  Fluidity and continuity should be observed
o Related Projects
 Overview of the current system/project
 Inventory of every related and existing projects/systems
 Fluidity and continuity should be observed
 Comparative matrix may be more appropriate
 Screen shots help make the presentation believable
 May consider 3 to 6 related studies/projects

 Here you note the themes of the articles and their common
conclusions, NOT your conclusion. This is not a statement about a
partial solution, but a summary of information about your problem. This
is a fact-based section of the paper. You aren’t writing out the solution
to the problem here; that comes later.
 Also, you note if there is a gap in knowledge – what is not covered in
these articles. You are being critical of the literature. It answered this
and this, but no one has research or thought of this…
 Include quotes if they are helpful. As a general idea, quotes should
only be used when the other person stated it so well that your
paraphrase doesn’t capture enough of their idea. Most ideas can be
paraphrased easily. Quotations are used because the language, the
expression of the idea, is so much better than you could paraphrase.
Chapter III
Technical Background
 This portion will contain the technicality of the project, details of the
technologies to be use, and how the project will work.
 Guidelines in Writing the Technical Background:
o Overview of the current technologies
(hardware/software/network) used in the current system
o Discussions on the current trends and technologies to be
used in developing and implementing the proposed system
 HARDWARE
 SOFTWARE
 PEOPLEWARE
 NETWORK
o Fluidity and continuity should be observed
 This chapter presents the description of the present operations in the
company or agency. You start by describing how big is the company
and how many clients does it cater.
o You can use organizational chart to emphasize the
hierarchy of positions of stakeholders.
 Describe how the company employees perform their tasks (note: only
those processes that are involved in the project)
o You can use workflow diagram to emphasize the step-by-
step process of how the existing system work.
  Enumerate in paragraph and descriptive form the problems
encountered in the present operations
 Describe how you wish to solve those problems that are encountered
by the employees or clients
 List of tools and software to be use in the software development and
its uses
 List of hardware specification to be use during the system
development, its type of application
 List of packages/API to be used in the application and its description
Chapter IV
Methodology, Results and Discussion
 For the proposal of the study - only METHODOLOGY:
o Methods is not where you tell us what you discovered. This is an
analysis of the process (strengths and weakness of the process).
DO NOT give the results of any of your research here.
o Discuss all aspects of data collection – who, what, when, where,
and HOW. “How” is a big issue.
o Discuss why you choose one form of data collection over
another. What were the strengths and weaknesses of one format
over another.
o Discuss any ethical issues about the collection of data, the
questions themselves, any sort of ethical issues involved.
o You must also discuss the methods of analysis. Go into detail
about how you coded interviews and how you did the statistics.
You must describe this. It is not just drawing conclusions based
on interpretation of a comment, but how did you go about
reaching the conclusion. You must analyze your methods.
o You are NOT telling us what you discovered in method section.

 This chapter details the method used to conduct your study. Be

specific – almost like a recipe from a cook book. After reviewing this
section, the reader should be able to conduct the exact same
research with no further information than what you provide here.
Take the reader through the process you went through, step-by-
step.
 Subjects/Participants
o Discuss all aspects of data collection – who, what, when,
where, and HOW. “How” is a big issue.
 Discuss why you choose one form of data collection over another.
What were the strengths and weaknesses of one format over
another.
o Data Collection Approaches/Strategies
o Advantage of Strategy
o Limitation of Strategy
o Potential Risk
 Discuss any ethical issues about the collection of data, the
questions themselves, any sort of ethical issues involved.
 o Ethical Issues About Collection Upon The Subjects /
Participants
 Data Analysis Approaches And/Or Software (NOT The Results
Themselves, Just How You Are Going To Analyze The Data –
Coding Method, Analysis Of Interviews/Recordings, Mathematics
And Stats Analysis)
o You must also discuss the methods of analysis. Go into
detail about how you coded interviews and how you did the
statistics. You must describe this. It is not just drawing
conclusions based on interpretation of a comment, but how
did you go about reaching the conclusion. You must analyze
your methods.

And / or

 Begin the chapter with a brief explanation of what the chapter is all about. The
common introductory explanation is as follows:
o Writing the Introductory Paragraph This chapter presents the
discussion on the research methodology of the study, the subjects,
sampling technique, research instruments, procedure of data
gathering, and statistical treatment that will be uses for accurate data
analysis and interpretation
o Research Methodology This section specifies what method of
research will be used – descriptive, correlational, experimental, or
documentary analysis
o Subjects/Respondents of the Study
A distinction should be made between subjects and respondents of
the study.
- Subjects are persons investigated in the study.
- Respondents, therefore, are providers of information needed
in the study, elicited orally or in writing. It is important to state
your number of subjects or respondents and who they are.
Also, explain how the number will be decided upon.
o When learning abilities of pre-school pupils are
being assessed in the study, the preschool pupils
are the subjects. The pupils’ teachers and mothers
who will be interviewed and asked to fill out a
questionnaire are the respondents of the study.
 Sampling Technique Explain what sampling technique will be used
– random, purposive, stratified, etc.—why you used it, and what
procedure will be followed to carry out the technique.
 Research Instruments It is necessary to have a separate
discussion for this, if several research instruments have been utilized
in the study. Research instruments are questionnaires, tests,
interviews, observations, etc.
 Procedures of Data Gathering Identify your sources of data. If a
questionnaire will be used, explain what kind and how it will be
constructed if it is original, how it is pre-tested, distribution, retrieval,
collation, etc. Thus, your procedures may include: Construction of
the questionnaire, Validation, Distribution, Retrieval, Collation,
Presentation of Data and Interpretation of Data.
 oStatistical Treatment of Data Specify the statistical
treatment/s you will use for interpreting your data and why
they are necessary. Also, include the scale or verbal
interpretation for the statistical processing of your data;
mention the name of the office or agency, or the person
taking charge of it.
 NOTE: Past tense was used because it is a finished research. For proposals, future tense
verbs should be employed.)

- Requirements Analysis
 Requirements analysis is critical to the success or failure of a
systems or software project. The requirements should be
documented, actionable, measurable, testable, traceable, related to
identified business needs or opportunities, and defined to a level of
detail sufficient for system design. Conceptually, requirements
analysis includes four types of activity:

 Eliciting requirements: the task of communicating with

customers and users to determine what their
requirements are. This is sometimes also called
requirements gathering.

 Analyzing requirements: determining whether the

stated requirements are unclear, incomplete, ambiguous,
or contradictory, and then resolving these issues.

 Requirements modeling: Requirements might be

documented in various forms, such as natural-language
documents, use cases, user stories, or process
specifications.

 Review and retrospective: Team members reflect on

what happened in the iteration and identifies actions for
improvement going forward.

 Requirements analysis is a team effort that demands a combination

of hardware, software and human factors engineering expertise as
well as skills in dealing with people. Here are the main activities
involve in requirement analysis:

 Identify customer's needs.

 Evaluate system for feasibility.

  Perform economic and technical analysis.

 Allocate functions to system elements.

 Establish schedule and constraints.

 Create system definitions.

 Requirement analysis helps organizations to determine the actual

needs of stakeholders. At the same time, it enables the
development team to communicate with stakeholders in a language
they understand (like charts, models, flow-charts,) instead of pages
of text.

 Once the requirements are gathered, we document the

requirements in a Software Requirements Specification (SRS)
document, use cases or as User Stories, which are shared with the
stakeholders for approval.

 A business project requires a variety of requirements to help define

goals and establish a scope for the work that will be undertaken.
Requirements also provide context and objective ways to measure
progress and success. Once business requirements are
established, software requirements are defined and developed in
order to move a project forward.

 Business requirements relate to a business' objectives,

vision and goals. They also provide the scope of a business
need or problem that needs to be addressed through a
specific activity or project.

 SOFTWARE REQUIREMENTS break-down the steps

needed to meet the business requirement or requirements.
Whereas a business requirement states the 'why' for a
project, software requirements outline the 'what'.

o For example, if the business requirement is to create

a member directory for a trade association, the
software requirements will outline who has access to
the directory, how member register with the directory,
who will have ownership of the data, what vehicle or
vehicle will be used such as a website or paper-based
directory, and so on.

- Requirements Documentation
 This specifies what a future software application or IT product
might look like, and more importantly, how it will be used and
how it needs to be built. This is done by showing various
markets for product development, along with other essential
data. In writing a requirements document, these basic steps will
assist in detailing what is needed.
o Create a comprehensive explanation of what is needed
for a product. The requirements document will need to
fully develop the context around a product and what it
must look like to help developers implement their work.

o Interview various sources. Get information for the

requirements document from business leaders,
engineers, developers, sales reps, customers or anyone
else with important information about needs for product
development.
o List system requirements or properties. One of the
important elements of requirements is the system
requirements, or how the product will interact with a given
system for a workstation or network.
o Identify any constraints for the project. Explaining
restrictions or constraints within the requirements
document will help further guide those who are working
on the software or IT product.
o Consider any interface requirements. Interface
requirements are an important part of this document
because they determine how the end-user will view the
product. They often have a critical influence on the user-
friendliness of a product.

o Identify color schemes, command button requirements

and any other part of a successful interface.

o Keep in mind the programming tools that will be used to

develop the project or product when listing interface
requirements. This will provide more guidance for
developers and others.

o Identify parameters like cost and scheduling. These

practical considerations should also be part of a
requirements document.

o Work up a development plan. Along with the above

information, a good requirements document will often
include further instructions about development of the
 product. This can take one of a number of forms, and
may require a bit of creativity.
o Insert visuals. Graphic mockups of a product keep the
project fresh and appealing to the eye, while providing
more detail about how something will look.
o Categorize and organize requirements. Find a way to
neatly fit each of these categories of requirements into a
single document.
o Write the requirements document. Utilize good document
planning strategies in constructing something that reads
well, where individual areas of the requirements
document are easy to access.

- Design of Software, Systems, Product, and/or

Processes
 Software design is a process to transform user requirements into
some suitable form

 For assessing user requirements, a Software Requirement

Specification document is created whereas for coding and
implementation, there is a need of more specific and detailed
requirements in software terms.

 Software design is included in Software Design Life Cycle, which

moves the concentration from problem domain to solution
domain. It tries to specify how to fulfill the requirements
mentioned in Software Requirement Specification.
 A DFD is often used as a preliminary step to create an
overview of the system without going into great detail, which
can later be elaborated.

 A use case diagram is the primary form of system/software

requirements for a new software program under developed. A
use case diagram is usually simple. It does not show the
detail of the use cases. It only summarizes some of the
relationships between use cases, actors, and systems. It
does not show the order in which steps are performed to
achieve the goals of each use case.

 A user story is a note that captures what a user does or

needs to do as part of his/her work. Each user story consists
of a short description written from user's point of view, with
natural language. Unlike the traditional requirement capturing,
 user story focuses on what the user need instead of what the
system should deliver. This leaves room for further discussion
of solutions and the result of a system that can really fit into
the customers' business workflow, solving their operational
problems and most importantly adding value to the
organization. User stories are well compatible with the other
agile software development techniques and methods, such as
scrum and extreme programming.

 User Stories vs Use Cases - The Similarity

 User Stories contain, with user role, goal and

acceptance criteria.

 Use Cases contain equivalent elements: an actor,

flow of events and post conditions respectively (a
detailed Use Case template may contain many
more other elements).

 User Stories vs Use Cases - The Difference

 The details of a User Story may not be
documented to the same extreme as a Use Case.
 User Stories deliberately leave out a lot of
important details. User Stories are meant to elicit
conversations by asking questions during scrum
meetings.
 Small increments for getting feedback more
frequently, rather than having more detailed up-
front requirement specification as in Use Cases.
 Software design yields three levels of results:
o Architectural Design - The architectural design is the
highest abstract version of the system. It identifies the
software as a system with many components interacting
with each other. At this level, the designers get the idea
of proposed solution domain.
o High-level Design- The high-level design breaks the
‘single entity-multiple component’ concept of architectural
design into less-abstracted view of sub-systems and
modules and depicts their interaction with each other.
High-level design focuses on how the system along with
all of its components can be implemented in forms of
modules. It recognizes modular structure of each sub-
system and their relation and interaction among each
other.
o Detailed Design- Detailed design deals with the
implementation part of what is seen as a system and its
 sub-systems in the previous two designs. It is more
detailed towards modules and their implementations. It
defines logical structure of each module and their
interfaces to communicate with other modules.

 In this section of the paper you will tell the readers the results of your research,
what did the data say. Here you lay out the statistics and their interpretation. If
needed, include a graph with your interpretation.
o Graphs, charts, and survey results are appendices.
 Interpret the data –not just the raw numbers, but themes that come up from the
numbers. Are there multiple interpretations possible? Multiple ideas/themes
present? As part of the interpretation, spend time with how the method/format of
research produced these results.
 Here is where all the conclusions are stated. Here you state the conclusions from
the literature review. Here you describe the conclusions drawn from your surveys
and interviews. In this section you connect the results of your research to your
initial problem. Now you tell us how it all relates AND how to move forward. If
done properly, this conclusion is driven entirely from the research you did, both
literature review and other data collection.

- Development and Testing

 Development testing (DevTest) is an approach in software
development that aims to bring the development and testing
phases closer together. In traditional software development,
development and testing are two separate siloed functions. The
challenge with this approach is that it introduces delay between
code being written and that same code being tested.

 In DevTest, these phases are more tightly integrated so that code

that is being written and checked in is automatically tested. In this
way, problems can be more quickly discovered and addressed.

 Using a DevTest software development methodology can deliver

numerous benefits like:

 Higher code quality at any given time because new code is

continually being tested

 Shortened time to market for new features

 Present a model of the software testing process and relate each

phase of your model to activities of testing that you did.
 - Description of the Prototype

- Implementation Plan (Infrastructure/Deployment)

- Implementation Results

Chapter V
Recommendations
 Here you state recommendations for future application of your
research. In other words, this application points to what you are going
to do/are doing now that you know what to do.