University of Science & Technology, Bannu

Department of Software Engineering

Thesis submitted in the partial fulfilment of the requirements for the degree of B.Sc.
Software Engineering

Title of the Project

Submitted by:
1. Mr. ABC Reg #___________________
2. Mr. XYZ Reg #___________________
3. Mr. RST Reg #___________________

Supervised by:

Signatures of Supervisor: _____________________________

Declaration
We hereby declare that this project report/thesis entitled “TITLE” submitted to the “DEPARTMENT
NAME”, is a record of an original work done by us under the guidance of Supervisor “NAME” and that

1
no part has been plagiarized without citations. Also, this project work is submitted in the partial
fulfillment of the requirements for the degree of Bachelor of “Discipline Name”.

Team Members Signature

Name _____________________

Name _____________________

Name _____________________

Supervisor Signature

Supervisor Name

Date:

_________________________

2
Abstract

Include a brief summary of the problem statement, challenges, proposed solution, approaches,
scope, and comparison with existing systems/evaluation methods, conclusion and future
directions. The abstract should be restricted to one page – plain text with font size of 12.
Abstract must be self-explanatory and should not include any references or short hand notations
in the abstract

29
Plagiarism Check Report

You are required to attach the plagiarism check report dully verified and signed by your
supervisor. Similarity score above 19% is not acceptable.

Name of Supervisor: Signature:

30
Acknowledgement

31
List of Abbreviations

Abbreviation Expansion

32
List of Symbols

[This list should include all the symbols that you will use in various equations in your thesis.
Each of the symbols should be explained in the line in front along with the units which should
be in bold text. The list of symbols should be sorted in a way as the symbols appear in the thesis
document. The symbol should be in italics bold while the explanation should only be in regular
italics]

Symbols Meaning

33
Table of Contents

Please note that you don’t have to type the List of Figures – after you are done with all of your
document, right click on your table of contents and click on Update option

List of Figures

Please note that you don’t have to type the List of Figures – after you are done with all of your
document, right click on your table of contents and click on Update option

List of Tables

Please note that you don’t have to type the table of contents – after you are done with all of your
document, right click on your table of contents and click on Update option.

34
Chapter-1: Introduction

Introduction is mostly written for non-specialists so that they can get an overview of the project
without technical details. It should provide a brief overview of the project aims and structure of
the solution. It should also specify what unmet need or problem the FYP caters for and who
needs it.
At the end of chapter, provide a summary of the report organization, chapter outlining what has
been covered in this chapter and explain what comes in the following chapters.

1.1 General Formal of Thesis

Following is the generic format for the final thesis.

1. Introduction
2. Literature Review
3. Problem Definition
4. Methodology/Solution Statement
5. Detailed Design and Architecture
6. Implementation and Testing
7. Results and Discussion
8. Conclusion and Future Work
9. References
10. Appendices (if any)
1.2 Styles
1.2.1 Typeface
Space of the text should be 1.5, Font. 12 Times, text must be justified The first line of the
paragraph should be indented and single line space be given between paragraphs.
1.2.2 Margins
Left 1.5 inches
Right, Top, Lower 1.2 inches
1.2.3 Headings

35
 Chapter Number 14 Times (Bold, Justified to the left, first letter in capital i.e. “C”)
Chapter Heading 14 Times (First letter in capital, bold, Justified to the left)
The following headings should all be left aligned and text should begin from the next
line with indentation.
First Level Heading 13 Times (First letter in capital, bold)
Second Level Heading 12 Times (Bold, First letter of each main word in capital)
Third Level Heading 11 Times (Bold, Only first letter of first word in capital)

1.3 Tables and Figures

Every table must bear a title and table number which should be written on the top of the table
(Table 1: Abc)
Titles of the figures should be written under the figures, along with the figure number (Figure
1: Xyz)
1.4 References
All factual material that is not original with you must be accompanied by a reference to its
source. Please use IEEE guideline on reference and citation style. The information for writing
a
reference for a Conference paper, Paper published in a Journal, Book, Book Chapter, Website
and any other source. You should use the same citation style as given below.
1.4.1 Journals
Author Name/s (Surname, initial), year of publication in-parenthesis, title of the article, name
of the journal, volume number, issue number (in parenthesis) followed by a colon and page
numbers
1.4.2 Books
Author Name/s (Surname, initial), year of publication in-parenthesis, title of the book,
publisher’s name, place of publication, page numbers
1.4.3 Reference from Internet

36
Name of the Author/s (If Known), Title of the topic followed by complete web address

37
Chapter-2: Literature Review

Provide an overview to the projects background knowledge without too much in detail (stick to

the scope of the project). The background can refer to previous work referenced from journals,

articles, newspapers, or any academic literature providing evidence that the proposed problem is

significant and real problem worth solving.

If available, provide closely related work done within the project scope and the challenges or

defects identified which can be considered as part of the new solution.

Describe why you worked on this project in light of the literature review?

38
Chapter-3: Problem Definition

39
Chapter-4: Methodology

The methods, approaches, tools, techniques, algorithms, or other aspects of the solution are
sufficiently discussed with sufficient details and supporting figures.

40
Chapter-5: Detailed Design and Analysis
5.1 SYSTEM ARCHIECTURE
This section should provide a high-level overview of how the functionality and responsibilities
of the system were partitioned and then assigned to subsystems or components.
Don't go into too much detail about the individual components themselves (there is a subsequent
section for detailed component descriptions). The main purpose here is to gain a general
understanding of how and why the system was decomposed, and how the individual parts work
together to provide the desired functionality.
At the top-most level, describe the major responsibilities that the software must undertake and
the various roles that the system (or portions of the system) must play. Describe how the system
was broken down into its components/subsystems (identifying each top-level
component/subsystem and the roles/responsibilities assigned to it). Describe how the higher-
level components collaborate with each other in order to achieve the required results. Don't
forget to provide some sort of rationale for choosing this particular decomposition of the system
(perhaps discussing other proposed decompositions and why they were rejected). Feel free to
make use of design patterns, either in describing parts of the architecture (in pattern format), or
for referring to elements of the architecture that employ them.
If there are any diagrams, models, flowcharts, documented scenarios or use-cases of the system
behavior and/or structure, they may be included here (unless you feel they are complex enough
to merit being placed in the Detailed System Design section). Diagrams that describe a particular
component or subsystem should be included within the particular subsection that describes that
component or subsystem.
5.1.1 Architecture Design Approach
Describe the architectural design approach.
5.1.2 Architecture Design
Provide and describe a figure that depicts the overall system architecture. Develop a modular
program structure and explain the relationships between the modules to achieve the complete
functionality of the system. This is a high level overview of how responsibilities of the system
were partitioned and then assigned to subsystems. Identify each high level subsystem and the

41
roles or responsibilities assigned to it. Describe how these subsystems collaborate with each
other in order to achieve the desired functionality.
Don’t go into too much detail about the individual subsystems. The main purpose is to gain a
general understanding of how and why the system was decomposed, and how the individual
parts work together. Provide a diagram showing the major subsystems and data repositories and
their interconnections. Describe the diagram if required.
5.1.3 Subsystem Architecture
Provide a decomposition of the subsystems in the architectural design. Supplement with text as
needed. You may choose to give a functional description or an object oriented description.
For a functional description, put top level data flow diagram (DFD) and structural decomposition
diagrams. For an OO description, put subsystem model, object diagrams, generalization
hierarchy diagram(s) (if any), aggregation hierarchy diagram(s) (if any), interface specifications,
and sequence diagrams here.
5.2 DETAILED SYSTEM DESING
Most components described in the System Architecture section will require a more detailed
discussion. Other lower-level components and subcomponents may need to be described as well.
Each subsection of this section will refer to or contain a detailed description of a system software
component. The discussion provided should cover the following software component attributes:
5.2.1 Classification
The kind of component, such as a subsystem, module, class, package, function, file, etc.
5.2.2 Definition
The specific purpose and semantic meaning of the component. This may need to refer back to the
requirements specification.
5.2.3 Responsibilities
The primary responsibilities and/or behavior of this component. What does this component
accomplish? What roles does it play? What kinds of services does it provide to its clients? For
some components, this may need to refer back to the requirements specification.
5.2.4 Constraints

42
Any relevant assumptions, limitations, or constraints for this component. This should include
constraints on timing, storage, or component state, and might include rules for interacting with
this component (encompassing preconditions, post conditions, invariants, other constraints on
input or output values and local or global values, data formats and data access, synchronization,
exceptions.
5.2.5 Composition
A description of the use and meaning of the subcomponents which are a part of this component.
5.2.6 Uses/Interactions
Description of component collaboration with other components. What other components is this
entity used by? What other components does this entity use (this would include any side-effects
this entity might have on other parts of the system)? This concerns the method of interaction as
well as the interaction itself. Object-oriented designs should include a description of any known
or anticipated subclasses, super classes, and meta classes.
5.2.7 Resources
A description of any and all resources that are managed, affected, or needed by this entity.
Resources are entities external to the design such as memory, processors, printers, databases, or a
software library. This should include a discussion of any possible race conditions and/or
deadlock situations, and how they might be resolved.
5.2.8 Processing
A description of precisely how this component goes about performing the duties necessary to
fulfill its responsibilities. This should encompass a description of any algorithms used; changes
of state; relevant time or space complexity; concurrency; methods of creation, initialization, and
cleanup; and handling of exceptional conditions.
5.2.9 Interface/Exports
The set of services (resources, data, types, constants, subroutines, and exceptions) that are
provided by this component. The precise definition or declaration of each such element should
be present, along with comments or annotations describing the meanings of values, parameters,
etc. .... For each service element described, include (or provide a reference) in its discussion a

43
description of its important software component attributes (Classification, Definition,
Responsibilities, Constraints, Composition, Uses, Resources, Processing, and Interface).
Much of the information that appears in this section is not necessarily expected to be kept
separate from the source code. In fact, much of the information can be gleaned from the source
itself (especially if it is adequately commented). This section should not copy or reproduce
information that can be easily obtained from reading the source code (this would be an unwanted
and unnecessary duplication of effort and would be very difficult to keep up-to-date). It is
recommended that most of this information be contained in the source (with appropriate
comments for each component, subsystem, module, and subroutine). Hence, it is expected that
this section will largely consist of references to or excerpts of annotated diagrams and source
code. Any referenced diagrams or source code excerpts should be provided at any design
reviews.
5.2.10 Detailed Subsystem Design
Provide a detailed description of this software component (or a reference to such a description).
Complex diagrams showing the details of component structure, behavior, or information/control
flow may be included in the subsection devoted to that particular component (although, unless
they are very large or complex, some of these diagrams might be more appropriately included in
the System Architecture section. The description should cover any applicable software
component attributes (some of which may be adequately described solely by a source code
declaration or excerpt).

5.3 CLASS DIAGRAM

44
Chapter-6: Implementation and Testing

45
Chapter-7: Results and Discussion

A comprehensive evaluation of the solution is presented with supporting figures and graphics.
System testing is performed through a strong testing strategy and the test cases cover all the use
cases.

46
Chapter-8: Conclusion and Future Work

Include a brief summary of how the proposed solution is going to/has addressed the problem
statement specified in the introduction section. Provide an overview of what kind of evaluations
were undertaken in order to prove that the solution really solves the problem with evidence on
results findings.
Provide an overview of the recommendations and include a future direction which is required as
part of the future work.

47
References
A comprehensive list of references is cited using a standard format.
Any material/information referred from research papers, books or/and websites should be
acknowledged under this heading.
The students are recommended to use any biblography management software to keep
track of references. e.g. EndNote, Mendlay, Jabref

48