1

Preliminaries
Title Page
Abstract
Table of Contents
List of Figures
List of Tables
Introduction
Overview of the Current State of Technology
Statement of the Problem
Project Objectives
General Objective
Specific Objectives
Significance of the Project
Review of Related Literature
Requirements Analysis and Documentation
Scope of the Project
Overview of the Requirements Documentation
General Description
Product
Perspective
Product
Functions User
Characteristics
General
Constraints
Assumptions and Dependencies
Specific Requirements
User Requirements
System
Requirements
Interface
Requirements
Design of Software, Systems, Product, and/or Processes
Development Method
Description of the
Prototype Testing
Implementation Plan
(Infrastructure/Deployment) Conclusion
and Recommendations
Bibliography
Appendices
Project Gantt Chart
Supporting Documentations (User Guide/Manual, etc.)
Sample Input/output/reports
Evaluation Tool or Test
Documents Relevant Source
Code Communication
Letters
Project Status Reports

One-Page Curriculum Vitae per team member

Format for the

Capstone Project
Preliminari
es
Title Page
Abstract
An abstract is a summary of your completed project with 150 to 200 words
of short, direct and complete sentences. If done well, it makes the reader want
to learn more about your project.
These are the basic components of an abstract in
any discipline:
1. Motivation/problem statement: Why do we care about the problem?
What practical, scientific, theoretical or artistic gap is your research
filling?
2. Methods/procedure/approach: What did you actually do to get
your results? (e.g. analyzed legacy systems, completed three webbased information systems, interviewed
17 technical
experts)
3. Results/findings/product: As a result of completing the above
procedure, what did you learned/developed/created?
4. Conclusion/implications: What are the larger implications of your
findings, especially for
the
problem/gap
identified
in
step
1/opportunities seen?

Table of Contents
List of Figures
List of Tables
Introduction
Note: Provide an introductory paragraph of what the reader should expect in this section.

Overview of the Current State of Technology

This section gives the reader an overview of the specific technology or field in
the international or local setting. The information regarding the technology or
field should be contemporary and not based on outdated sources. Discussion
must not be too technical or too detailed.
This section ends with a discussion on the problems faced by or that still
exist in the specific technology or field (e.g., limitations of existing software
or algorithms). The problem statement would lead to the project objectives.
However, in some instances there will be no existing problem that can be
identified but possible opportunities that can be looked into.

Project Objectives
General
Objective
This section states the over-all goal that must be achieved to
answer the problem.

Specific
Objectives
This subsection is an elaboration of the general objective. It states the
specific steps that must be undertaken to accomplish the general
objective. These objectives must be SMART (specific, measurable,
attainable, realistic, and time-bounded). Each specific objective may
start with to design/survey/review/analyze
Studying a particular programming language or development
tool
(e.g.,
to
study Windows/Object-Oriented/Graphics/C++
programming) to accomplish the general objective is inherent in
all project paper and, therefore, must not be included here.

Significance of the Project

This section explains why the project must be done in this area. It rationalizes
the objectives of the

project with that of the stated problem/opportunity. Avoid including here

sentences
such
as
This
project
will
be
beneficial
to
the
proponents/department/college as this is already an inherent requirement
of all projects. Focus on the projects contribution to the field of
Information and Communications Technology.
Some things you may want to consider when writing this section is the answer
to the question Why is this product required? This section can provide
justification when requirements are being negotiated, to assess whether a
particular change is a good idea. This section will also provide

readers an initial understanding why certain requirements have been included in the Requirements
Analysis and Documentation section.

Review of Related Literature

Note: Provide an introductory paragraph of what the reader should
expect in this section.
This section discusses the features, capabilities, and limitations of existing work,
algorithms, or software that are related/similar to the project. The reviewed works and
software must be arranged either in chronological order, or by area (from general to
specific). Observe a consistent format when presenting each of the reviewed works.
Provide
literature.

5-10

Requirements Analysis and Documentation

Note: Provide an introductory paragraph of what the reader should
expect in this section.
Requirements are the basic functions that a system needs to be able to carry out in
order to perform the task(s) for which it was designed. The meat of a requirements
document is, of course, the list of requirements. User requirements are functions that
someone using the system will see or do. System requirements (also called technical
requirements) are behind-the-scenes, technical functions that the system must be
capable of doing in order to support the user requirements. You don't need to
separate requirements by type in a requirements document, although you can if you
wish.
To get requirements out of scenarios, ask yourself the following questions as you
examine each scenario:

What is the user trying to do?

What part of that task is facilitated by the system or product?

What part of that task is independent of the system or product?

What has to happen "behind the scenes" while the user does this task?

What does the user see on the screen while s/he is working on the task?
A requirements document explains why a product is needed, puts the product in
context, and describes what the finished product will be like. A large part of the
requirements documentation is the formal list of requirements.
Requirements include descriptions of system properties, specifications for how the
system should work, and constraints placed upon the development process. Generally,
requirements are statements of what a system should do rather than how it should
do it. The answers to how questions fall into the realm of design. Requirements
specifications should not include design solutions (except for interface requirements,
which often include embedded design).
Requirements come from end users, from customers, and sometimes from developers.
End users tend to state requirements in descriptive or narrative terms ("I'd like a
welcome screen with links to the things I use regularly, and I want to be able to
select from a couple of different color schemes for the welcome screen") which might
need to be broken down into individual requirement statements. Customers, who may
well be different from end users, are the people who are paying for the
development of the system. Their requirements will often be stated in terms of costs
or scheduling issues. Developers might have requirements related to system
performance and other technical topics.
It's important to have all these groups contribute to the requirements
documentation to create a fuller description of the system. The practice of including
these groups also helps to ensure that everyone is in agreement about what is to be
done before development begins.
Requirements
documentation
usually
include
user,
system,
and
interface
requirements;
other
classes
of requirements are included as needed. User
requirements are written from the point of view of end users, and are generally
expressed in narrative form: The user must be able to change the color scheme of the
welcome screen. System requirements are detailed specifications describing the
functions the system needs to do. These are usually more technical in nature: The
system will include four preset color schemes for the welcome screen. Colors must be
specifed for the page background, the text, visited links, unvisited links, active links, and
buttons (base, highlight, and shadow). Interface requirements specify how the
interface (the part of the system that users see and interact with) will look and
behave. Interface requirements are often expressed as screen mock-ups; narratives or

lists are also used.

Besides listing requirements, the document should explain why the product is
needed, put the product in context for development, and describe what the finished
product will be like.

Obviously, the scale of the project will infuence the contents and length of a
requirements document. Large, complex projects are likely to have more requirements.
Smaller, quicker projects will have fewer requirements and will need shorter
requirements documents, which can double as project proposals.

Scope of
Project

the

Include a brief narrative here which describes the product as you intend it to
be realized. Use this section to define boundaries and set expectations.

Overview
of
Documentation

the

Requirements

If your project is small to medium in size, include a summary of the requirements

here. This may be
a numbered list of the most important requirements. The purpose of this
section is to give the reader a general understanding of the requirements and
focus attention on the most critical ones. This section may also help point
readers to the specific requirements that are of particular interest to them.

General
Description
This section will give the reader an overview of the project, including why it was
conceived, what it
will do when complete, and the types of people we expect will use it. We also
list constraints that were faced during development and assumptions we
made about how we would proceed.
This section contains a nontechnical description of the project, usually in
narrative form, which may serve to acquaint new readers with the purpose of
the project. It also sets the stage for the specific requirement listing which
follows.

Product Perspective
Why have you chosen to develop this product? What need does it serve?
Who are the
primary stakeholders, who is developing the project, and who will
directly benefit from the finished product?

Product Functions
What does your product do? What activities can users perform while
using it? List the
main functions that you will build into your product here.

User Characteristics
Who do you expect to use your finished product, and why? What is their
technical
background, their training or education, their motivation to use it?
What obstacles might they encounter, and what specialized skills
will they need?

General Constraints
Did you work under any constraints such as platform or development
environment? Did you have to make your product compatible with any
existing software or other products currently in use?

Assumptions and Dependencies

In this section, list any assumptions you made about your project (for
example, did you assume that the finished product would need to be
delivered over the internet?). If your project depends on any particular
technical infrastructure, or requires administrators or others with
specific skills, note that here.
You may also provide additional description to any assumptions
or dependencies regarding the software and its use. These may
concern such issues as:

Related software or
hardware

Operating
systems

End-user
characteristics

Possible and/or probable changes in functionality

Specific
Requirements
1.

This section of the document lists specific requirements for name of project.
Requirements are divided into the following sections:
User requirements. These are requirements written from the point of view of end users,
usually expressed in
narrative form.
2. System requirements. These are detailed specifications describing
the functions the system must be capable of doing.

3.

Interface requirements. These are requirements about the user

interface, which may be expressed as a list, as a narrative, or as
images of screen mock-ups.

User Requirements
List user requirements
here.

System Requirements
List detailed system requirements here. If your system is large, you may
wish to break
this into several
subsections.
Here are some samples of system requirements. Note that not all
possible requirements are listed here.
1. Logging In & Out, Registering, and Profiles
1.1
Users must be able to log in and log out.
1.2
The site must be usable over a modem.
2. Reviewing Course
Materials
2.1
Students must be able to see at a glance which
materials are associated with certain dates and/or units.
2.2
The system must allow for inclusion of materials
including, but not limited to: text files, digitized audio,
digitized video, and web forms.
2.3
Students must be able to work through material at
their own pace,
repeating audio/video clips or re-reading text as desired.
3. Completing Student
Assignments
1.1
The system must allow students to complete
various types of
assignments, quizzes, etc. and to submit them to the
instructor(s).
1.2
The system should support the user by providing
information, when
appropriate, so the user does not have to type it in
(i.e., including a student's name on a quiz when the
student is logged in).
4. Evaluating Student
Assignments
4.1
Instructors must be able to design assignments, quizzes,
etc.
4.2
Instructors must be able to see easily which students
have completed
an
assignment.
4.3
Instructors must be able to easily review a student's
assignment and comment on it.
4.4
Instructors must be able to save the comments
they make on a student's work, and send those
comments to the student at a later time.

Interface Requirements
List interface requirements
here.

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

This section presents the internal design of the system, by discussing its major
components and their
interactions. These components include the software components (e.g., modules,
database systems, etc.), as well as the hardware components (e.g., processors, devices,
etc.). The components and their interactions are graphically represented using data
fow diagrams, system and program fowcharts, entity-relationship diagrams,
hierarchical or structure charts, network diagrams, and block diagrams. In addition,
discussion on why certain alternative and trade-offs was chosen must be included (e.g.,
issues on software decomposition, cost of hardware).

Development Method
Briefly describe the method or approach used for this software design. If one or
more formal/published methods were adopted or adapted, then include a reference to a
more detailed description of these methods. If several methods were seriously

considered, then each such method should be mentioned, along with a brief explanation
of why all or part of it was used or not used.

Description of the Prototype

This section provides a listing of all the functions that must be performed or delivered
by the system, and a description of each. Screen designs must be included, to help
visualize the function being discussed. When using screenshots, be sure to explain
major features or functions with narrative to avoid confusion or omission of desired
features. Usually, the functions are based on the menu and toolbar options. If a function
generates reports, the report formats must be included in this section.

Testing

This section presents the analysis, interpretation and implications of the summarized
test results, as well as the observations on the limits of the systems capabilities. It also
discusses the type(s) of testing performed on the system, the test data used, and the
results of the tests.
The type(s) of tests performed varies depending on the system developed. For
instance, commissioned software would require a detailed acceptance test and
system response time analysis, while software implementing an algorithm would
require an analysis of the performance of the algorithm on different machines or
on different test data.
We cannot test quality directly, but we can test related factors to make quality visible.
Quality has three sets of factors -- functionality, engineering, and adaptability. These
three sets of factors can be thought of as dimensions in the software quality space.
Each dimension may be broken down into its component factors and considerations
at successively lower levels of detail. The table below illustrates some of the
most frequently cited quality considerations.
Functionali
ty
(exterior
Correctness

Engineeri
ng
(interior
Efficiency

Adaptability
(future quality)
Flexibility

Reliability

Testability

Reusability

Usability

Documentation

Maintainability

Integrity

Structure

To initially determine if the product will meet the factors as stated above which we can
consider as success factor criteria, you will need to identify how we can determine we
meet each criteria. Some examples are:
1. Correctness: Assurance that the data entered, processed, and outputted by
application system is
accurate and complete. Accuracy and completeness are achieved through control
over transactions
and data element, which should commence when a transaction is originated
and conclude when the transaction data has been used for its intended
purpose.
2. File Integrity: Assurance that the data entered into application system will be
returned unaltered.
The file integrity procedure ensures that the right file is used and that the data
on the file and the
sequence in which the data is stored and retrieved is correct.
3. Access control: Assurance that the program prevents unauthorized
access and prevents unauthorized users to destabilize work environment.
4. Scalability: Assurance that the application can handle the scaling criteria
within constrains of
performance criteria.

Implementation Plan
(Infrastructure/Deployment)
System deployment is a complex endeavor which is a critical aspect of the software
development lifecycle (SDLC), an endeavor that is all but ignored by most who write
documentations. If you can't get software into the hands of your users then what is
its value? Absolutely nothing. The implementation plan should be documented and
presented.
The following tips and techniques should help to make your system
deployment efforts successful:
1. Identify and understand your deployment audience. There are at least three
distinct groups that you need to consider: your end users, the operations staff
responsible for running the software once it is in production, and the support staff
who is responsible for aiding your users with the software once it is in production.
You need to identify the level of control that each group has over your actual
deployment. Can one group stop your deployment if you don't meet their specific
requirements? For example, it is quite common to discover that if an organization
has an operations department then they may have a defined criteria for the release
of new software, criteria that your deployment approach must meet.
2. Identify your deployment strategy early. Will you run the new system in parallel with
the existing system
or will you perform a cutover? Running the system in parallel offers the advantage
that you can easily back out to the original system if the new one runs into
problems. However, parallel operations requires significant effort on the part of
everyone involved: Your users need to do double entry, operations staff need to run
both systems, support staff need to support both systems, and development staff
may need to create integration code that temporarily works behind the scenes
to synchronize data. For many systems, particularly ones supporting online

customers via the Internet, a cutover is your only option few customers would be
willing to place their book order with both BuyMeOnLine version N and with
BuyMeOnLine version N+1. With a straight cutover you will need to plan for a
downtime period in which the cutover occurs, anywhere from a few seconds to a
few hours, or even a few days depending on the nature of the system being
deployed.
3. Installation testing. Just like you test your application, you should also test your
installation scripts. A
good way to do this is to develop your installation scripts as you
develop your system.
4. You may need to upgrade your user's existing environments. These upgrades
could include changes to
existing hardware, operating systems, databases, or middleware. If you dont know
the current status of

your technical environment you will also need to plan for activities to perform
the required legacy analysis. If you are upgrading your database, you may be
upgrading the database software itself or the schema of your database; you will
need to include data conversion activities in your deployment plan. Physical
considerations should also be considered when performing environment upgrades.
Is sufficient power available? Are working areas such as desks and cubicles in place?
Does sufficient room exist in the building(s) that you are deploying to? Do sufficient
network drops exist for new workstations?
5. Training is an important part of deployment. Remember that your stakeholders
may need training
beyond that of learning how to work with your application. For example, this may
be the first time that some users are working with a PC, a browser, or even a
mouse. Similarly, this may be the first time that your operations staff is working
with a new technology that your system users, such as on a client-server
environment, and therefore will need to be trained and educated in that technology
to qualify them to work with your system.
6. Develop supporting documentation. Another important effort is the development of
operations, support, and user documentation.
This should include installation
manual, a comprehensive user manual, resource requirements, and back-up
procedures.

Conclusion and Recommendations

This chapter gives an assessment of what happened in this project. It presents
explanations and justifications on how the objectives of the project were met, to what
extent and why some objectives were not met.
This chapter also includes a discussion of possible improvements that can be made on
the software, as well as future directions of the project in general. This serves as a
springboard for projects that may be done by future project proponents.

Bibliography
Note:
Use
the
APA
http://www.calstatela.edu/library/guides/3apa.pdf

Style

Appendices
Project Gantt Chart
Supporting Documentations (User
Guide/Manual, etc.) Sample
Input/output/reports
Evaluation Tool or Test
Documents Relevant Source
Code Communication
Letters
Project Status Reports
One-Page Curriculum Vitae per team member