`

NOVEMBER

2016
ADDIS ABABA
UNIVERSITY
DEPARTMENT OF
COMPUTER SCIENCE

UNDERGRADUATE FINAL PROJECT

GUIDELINE [VERSION 1.0]
This document contains information on how to successfully compile a written final project report
for computer science students. This guideline plays an integral role in your project work, in your
report preparation, and the overall grading scheme. The sections and sub sections tries to
elaborate the general report structure including content, formatting style, and referencing style to
be used. Students are encouraged to stick to the guideline throughout their final year project.
TABLE OF CONTENTS

TABLE OF CONTENTS ................................................................................................................. i

1. INTRODUCTION ................................................................................................................... 1

2. OBJECTIVE ............................................................................................................................ 2

3. DOCUMENT STYLE AND FORMATTING ........................................................................ 3

3.1. Language .......................................................................................................................... 3

3.2. Paper Size and Specification ............................................................................................ 3

3.3. Font................................................................................................................................... 3

3.4. Spacing ............................................................................................................................. 4

3.5. Tables ............................................................................................................................... 4

3.6. Figures .............................................................................................................................. 4

3.7. Margins............................................................................................................................. 4

3.8. Page Numbers .................................................................................................................. 4

3.9. Headers ............................................................................................................................. 2

3.10. References .................................................................................................................... 2

4. PRESENTATION SLIDE FORMATTING ............................................................................ 4

4.1. Slide layout ....................................................................................................................... 4

4.2. Font................................................................................................................................... 4

4.3. Total number of slides ...................................................................................................... 4

5. OVERALL GUIDELINE ........................................................................................................ 6

5.1. Evaluation guideline ......................................................................................................... 6

5.1.1. Advisor contact ......................................................................................................... 6

5.1.2. Project Deliverables .................................................................................................. 6

5.1.3. Presentation and Demonstration ............................................................................... 7

i
 5.2. Plagiarism ......................................................................................................................... 7

5.3. Grade Decision ................................................................................................................. 7

5.4. Group effort evaluation .................................................................................................... 8

5.5. Approaches, methodologies and tools .............................................................................. 8

6. CONTENT OF THE PROJECT DOCUMENT ...................................................................... 9

6.1. Preliminary Sections ........................................................................................................ 9

6.2. Project Proposal (Chapter one of Your Document) ......................................................... 9

6.2.1. Introduction ............................................................................................................... 9

6.2.2. Statement of the Problem and Justification ............................................................ 10

6.2.3. Project Objective ..................................................................................................... 10

6.2.4. Scope of the Project ................................................................................................ 10

6.2.5. System Development Methodology........................................................................ 10

6.2.6. Significance of project ............................................................................................ 10

6.2.7. Beneficiaries ........................................................................................................... 10

6.2.8. Time Schedule ........................................................................................................ 10

6.3. Requirement Analysis .................................................................................................... 11

6.3.1. Introduction ............................................................................................................. 11

6.3.2. Current System........................................................................................................ 11

6.3.3. Requirement Gathering ........................................................................................... 11

6.3.4. Proposed System ..................................................................................................... 11

6.3.5. System Model ......................................................................................................... 12

6.4. System Design ................................................................................................................ 13

6.4.1. Introduction ............................................................................................................. 13

6.4.2. Current software architecture (if any) ..................................................................... 13

ii
 6.4.3. Proposed software architecture ............................................................................... 14

6.4.4. Detailed Class Diagram .......................................................................................... 15

6.4.5. Packages .................................................................................................................. 15

6.5. Implementation............................................................................................................... 15

6.5.1. Mapping Models to code ........................................................................................ 15

6.5.2. Source codes of major classes, packages or interfaces ........................................... 16

6.5.3. Screen Images ......................................................................................................... 16

6.6. Conclusion and Recommendation .................................................................................. 16

6.7. Reference ........................................................................................................................ 16

6.8. Glossary.......................................................................................................................... 16

7. REFERENCE ........................................................................................................................ 17

8. APPENDICES ....................................................................................................................... 18

Appendix I: Sample Weekly Contact Monitoring Form ........................................................... 18

Appendix II: Sample Cover Page .............................................................................................. 19

Appendix III: Sample Declaration ............................................................................................ 20

Appendix IV: Sample Certificate .............................................................................................. 21

Appendix V: Minimum Standards ............................................................................................ 22

Website Development............................................................................................................ 22

Mobile Development ............................................................................................................. 22

Other Systems ........................................................................................................................ 22

For all of your systems .......................................................................................................... 23

iii
 1. INTRODUCTION

Graduation Project is an important part of computer science discipline at undergraduate level.

The main purpose of these projects is to encourage students to apply the knowledge acquired
during their studies. Students are also expected to show how proficient they are in solving
real world problems with certain constraints for the outcome-based evaluation set by the
department of computer science. Consequently, all computer science students are required to
participate in group based final projects provided in the first and second semesters of their
final year.

Despite their uniqueness, final year projects involve common software development
techniques and principles to solve problems in an area of relevance to Computer Science and
Software Engineering. As a student, it is important to note that you are responsible for your
project. Supervisors will provide you with guidance and feedback, but you must put in the
effort to achieve a successful project. So work hard on your final year project, while
balancing your time and effort with other subjects.

To this end, the department requires its students to demonstrate knowledge right from project
planning to implementation. This guide is meant to assist students on the rules, procedures
and guidelines that should be followed in order to plan and execute a productive and
successful final year project. This guide is also used as a reference for all participants in the
final year projects: department advisors and the project evaluation committee members.

This document is divided into six major sections. Section two describes the objective of this
document and sections three and four explain about document and presentation slide formats.
Section five discusses about the general rules and principles that students, their advisors,
examiners, and project committee members should follow in order to have a homogeneous
communication and evaluation setup. Finally section six details about the major phases that
students should pass through to complete their project.

1
 2. OBJECTIVE

This guide aims to:

 Help students to have a good insight on the rules and procedures that should be
followed in project planning, design and implementation phases.
 Inform students about the evaluation and grading policies.
 Assist students use consistent formatting throughout their documentation.
 Notify final project rules, procedures and guidelines for advisors and the evaluation
committee.

2
 3. DOCUMENT STYLE AND FORMATTING

The department of Computer Science sets the minimum documentation preparation format
for the final project work, while issues like document content and length are decided by the
group and the advisor. Grammar, punctuation, spelling and other mechanical issues are the
sole responsibilities of the group members.

3.1. Language

 The final project document must be prepared in English.

3.2. Paper Size and Specification

 You have to use a standard A4 (8.27" X 11.69") paper size.

3.3. Font

The specifications below should be strictly followed throughout your document. For the title
page(s), refer appendix II.

 Body:
o Font type: Times New Roman
o Font size: 12
 Major Heading:
o Font type: Times New Roman [UPPER CASE]
o Font size: 14 [bold]
 Second Order Heading:
o Font type: Times New Roman
o Font size:13[bold]
 Third Order Heading:
o Font type: Times New Roman
o Font size:12[bold]
 Font Color: Black (Recommended unless and otherwise other colors carry some
sort of message)

3
3.4. Spacing

 Document line spacing should be 1.5 with the exceptions of captions, lists,
graphs, charts, items with tables and lists in the appendices.
 The alignment of each paragraph should be justified
 Lengthy tables may be 1 line spaced.
 Format paragraphs with 6 point spacing after paragraph end. New paragraphs to
start on next line (that is, there is no need of an extra line between paragraphs if
paragraphs are formatted as suggested). No paragraph indents necessary.
 Each chapter must start on a new page. Chapter titles hould be centered and a
Major Heading.

3.5. Tables

 Tables should be consecutively numbered and labeled. Table numbering should

indicate the chapter where it resides in.

3.6. Figures

 Figures should be consecutively numbered and labeled. Figure numbering should

indicate the chapter where it resides in.

3.7. Margins

 Use the custom margins bellow for your document.

o Top: 1" o Left: 1.25"
o Bottom: 1" o Right: 1"

3.8. Page Numbers

 Except for the title page, number all pages which come before the first page of the
body chapters consecutively with lower case roman numerals (i, ii, iii, iv…).
 The first page with Arabic numeral (1, 2, 3, and so on) starts from the page of the
introduction. Put page numbers right aligned.

4
3.9. Headers

The header will comprise the title of the Project report. On every odd page will appear the
title of the report while on the even pages the title of the chapter or section will be
mentioned. The first page of every section or chapter shall not carry the header.

3.10. References

Reference numbers should be cited within the text as well as figure/table captions either as
superscripts or enclosed in square brackets. In this way of citation, all references should be
numbered (Arabic numerals) in the order in which they are first cited in the report. Another
alternative is citing references using the author’s last name and the year the material
published. Here, all references should be arranged in a chronological ascending order.
Strictly avoid citing references in chapter/section/subsection titles. References are cited to
convey to the reader that the idea, concept, formulation, data, inference or information being
discussed is attributable to the cited literature. All figures/tables, which are taken from
literature, must be acknowledged by citing the reference number or the author and the year of
publication at the end of the caption.

The main reference sources include books/monographs/ handbooks, archived journal papers,
conference papers in published proceedings, institutional technical reports, theses/ project
documents, dissertations and other archived reports and standards. Internet websites are also
increasingly becoming an important source. However, it should be noted that Internet
references should not form the entire list of references. Allowing URLs as references must
not be misunderstood to mean that all Internet material is acceptable. Internet material may
be transitory, may not be technically reviewed and may have questionable authenticity, that
is, it may not be proper archival material. It may be used as secondary information source to
supplement the main sources.

List references at the end of the paper in either numerical order or chronologically ascending
order. Sample references could be as listed below:

 For a book: author(s), book title (italic), edition. City of Publisher, Abbrev. of
Publisher, year, ch. x, sec. x, pp. xxx–xxx.

2
 Example:

[1] L. R. Rabiner and B. H. Juang, Fundamentals of Speech Recognition.

Englewood Cliffs NJ, PTR Prentice Hall Inc, 1993.

[2] ጌታቸው በለጠ፣ የጥበባት ጉባኤ:: አዲስ አበባ፣ አስቴር ነጋ አሳታሚ ድርጅት፣ 2012::

 For a journal paper: author(s), paper title (in quotes), in journal name, volume
number, issue number, page numbers (inclusive), publisher, year.
Example:
[3] R. K. Aggarwal and M. Dave, "Acoustic modeling problem for automatic
speech recognition system: conventional methods (Part I)," in International
Journal of Speech Technology, Vol. 14, Issue 4, pp 297 - 308, Springer
Science+Business Media, 2011.
 For a proceedings paper or chapter in an edited book: author(s), paper or chapter title
(in quotes), in volume title, editor(s) (if applicable), volume number (if applicable),
page numbers (inclusive), publisher, city, year.
Example:
[4] S. T. Abate and W. Menzel, "Syllable-Based Speech Recognition for
Amharic," in Proceedings of the 5th Workshop on Important Unresolved
Matters, pp. 33–40, Association for Computational Linguistics, Prague, Czech
Republic, 2007.
 For an internet source: author(s), year, webpage title (bold), URL [access date].
Example:

[5] M. P. Lewis (Ed). (2009). Ethnologue: Languages of the World (Sixteenth

edition) [Online]. Available: http://www.ethnologue.com/ [February 05,
2013].

3
 4. PRESENTATION SLIDE FORMATTING

You are expected to defend your project by preparing a catchy presentation. Developing an
outline or structure for your presentation will help you communicate a clear and meaningful
message to your audience.

4.1. Slide Layout

 Your slides should have white background with little or no graphics.

 Your bullet points should be short and quick hits and try to keep the number of
bulleted items around six per slide.

4.2. Font

 Use Arial font type with color black.

 Main body contents should be coined in 20-24 pts.

 Font type, size and style of the main content area on all slides except for the title slide
should be the same.
 Title of your project should be maximum of 36 point-size
 Each content slide should have a title and should solely reflect the comprised content.
The titles should be brief and descriptive. They should not be full sentences.
 The title of each slide should be 30- point size

4.3. Total Number of Slides

 A general rule of thumb is one slide per minute. If you have a 20-minute
presentation, you should include about 20 slides. You don’t want to overwhelm your
audience with too much information. Focus on the key concepts you want your
audience to remember. However, for the sake of your defense up to 26 slides are
allowable.

Notice!

This is one of the biggest mistakes students make with PowerPoint: They cram too much text
onto their slides. Your text-only slides should be short, quick-hit highlights written as phrases
rather than complete sentences. If your audiences are busy reading your slide, they are not

4
going to be paying attention to you. Or they may not read the slide at all, which renders your
Power Point presentation useless. So, make sure to leave some white space around the main
content on your slide. This helps to focus the reader’s attention on the key information.

5
 5. OVERALL GUIDELINE

In this section, general guidelines that students, advisors, examiners and project committee
members must follow are specified.

5.1. Evaluation Guideline

The evaluation guideline is proposed to help students, advisors, examiners and project
committee work together so that there will be transparent, honest and fair evaluation process
during the project undertaking. This part is divided into three main components

5.1.1. Advisor Contact

Since each advisor assumes 0.5 credit hours for a single group, groups should contact their
advisor at least 30 minutes a week. There is a weekly contact monitoring form that will be
submitted by the group advisor to the project committee.

Apart from its usefulness as a tool to evaluate students’ individual efficiency on the project,
this procedure helps students do their project continuously in a progressive manner.

5.1.2. Project Deliverables

The second method of evaluation is based on the project deliverables that students should
produce at different stages of the project. Students are expected to submit the deliverables
below based on the schedule prepared by the project committee.

 Project proposal
 Project documentation
 Document presentation
 Implementation
 Demonstration

Note that:

 The quality in terms of content, format, English grammar and punctuation mark
usages are considered.

6
  Delivery time is another parameter that is considered in this part. For each delayed
day students will be penalized by certain points set by the project committee from
the total mark of that particular deliverable.

5.1.3. Presentation and Demonstration

This is the third component that students are evaluated with. Here

 Dressing protocol, confidence while presenting the work, quality of presentation slide
and appropriate time usage are considered.
 Proper presentation of your work is one of the most important skills that you are
expected to develop during your stay in campus. Here some students assume that they
have to say something even if it does not answer the question they are asked while
others think that they have to defend everything. Here you will be evaluated based on
how correctly and well you defended your work, and your honesty on accepting your
weaknesses and limitations that are beyond your control.
 Concerning your demonstration, you should be able to map your implementation to
the problem statement you started with, the requirements (both functional and non-
functional) that you promised to deliver and the solution you proposed and designed
in the design phase. Your implementation must be traceable to the documents you
have produced.
 Your implementation source code will be checked for its originality and readability
(e.g. Use of comments, following best coding practices) parameters.

5.2. Plagiarism

Any form of plagiarism will result into a severe measure. Students can use the work of others
that they found helpful without committing plagiarism. Use proper citation to acknowledge
work of others. Stealing information through direct copy - paste will result into an automatic
F leading to a complete rework of the entire project.

5.3. Grade Decision

As it has been noticed in the previous years; one of the major problems facing students and
instructors is grading decision. The grade of the project work will be decided by the advisor,
examiner and project committee.

7
5.4. Group Effort Evaluation

Your effort as a team will be evaluated through comments and result given by advisors and
examiners based on your punctuality to meetings and deadlines, willingness to accept and
correct feedbacks, team spirit, and time management during presentations.

Students can exert their effort on their particular area according to their interest and skill. But
they should have a significant role and participation in every piece of the project work. They
should know what every deliverable is and how it is produced.

5.5. Approaches, Methodologies and Tools

The recommended approach for doing your project is Object Oriented Software
Development approach. But by discussing with their advisors, students can select any
modern software development approach available. You can select, again by discussing with
your advisors, any appropriate software and tools that can assist you achieve your project’s
objective.

8
 6. CONTENT OF THE PROJECT DOCUMENT

This part of the document is prepared by using the IEEE Std 830-1998, IEEE Std 1016-2009
and the book “Object Oriented Software Engineering: Using UML, Patterns, and Java (3rd
Edition)”.

6.1. Preliminary Sections

 Topic/Title Page: Giving the logo and name of the institution, title of the project, the
name and identification number of the student(s), and the name of the supervisor. The
exact format is given in Appendix II as a sample page.
o Remember: you should be able to pick a title which is relevant enough in
solving real world problem(s) and improving your problem solving skills.
 Certificate: a certificate as per the format shown in Appendix IV to be signed by the
supervisor.
 Acknowledgment: acknowledge guidance/advice/help received from people you have
interacted with during the course of your project, restricting it to technical discussions
associated with the contents of the project.
 Table of Contents: (Microsoft word can generate this automatically)
 List of Tables [If any]: giving figure number, figure title, and page number (Microsoft
word can generate this automatically).
 List of Figures [If any]: giving table number, table title, and page number. If there are
very few figures and tables, then the list of figures and list of tables may be put on the
same page. Otherwise they may be put on different pages (Microsoft word can
generate this automatically)
 Acronyms [If any]: all acronyms and symbols used in the report must be defined here.
Order should be alphabetically ascending.

6.2. Project Proposal (Chapter one of Your Document)

6.2.1. Introduction

Reasons for studying the problem selected should be listed. Works already done in that area
should be mentioned. In here, you need to discuss about the significance of your focus area.
Besides, the problem area and motivation to the need for your project work is described.
9
Moreover, if your focus area leans on a specific organization you need to say so about the
organization.

6.2.2. Statement of the Problem and Justification

Here you are expected to describe specifically what the problem is and the problem that you
intend to solve. It should convey the project's importance, benefits, and justification.

6.2.3. Project Objective

Objectives to be achieved by the study should be discussed.

6.2.3.1. General Objective of the System

6.2.3.2. Specific Objective of the System

6.2.4. Scope of the Project

Here you need to define specific boundaries of your project in terms of what the project does
and what the project doesn’t.

6.2.5. System Development Methodology

This is an explanation of the theory related to the mathematical tools and techniques used and
understanding of the concept involved. Relevance and source of the data used (if any) would
make part of it. Innovation related to coding and testing strategies used (if any coding is done)
will be cited.

6.2.5.1. Investigation (Fact-Finding) Methods

6.2.5.2. System Development Tools

6.2.6. Significance of Project

The societal and technological importance of your project should be discussed in this part.

6.2.7. Beneficiaries

Who will benefit from the Software?

6.2.8. Time Schedule

Using the Gant chart, pert chart or any other tool

10
6.3. Requirement Analysis

6.3.1. Introduction

Purpose of the system

6.3.2. Current System

6.3.2.1. Major Function of the Current System/ Current System Description

6.3.2.2. Problem of the Existing System

6.3.3. Requirement Gathering

6.3.3.1. Requirement Gathering Methodologies

6.3.3.2. Results Found

6.3.4. Proposed System

6.3.4.1. Overview

6.3.4.2. Functional Requirements

Here document high level functionality of the system.

6.3.4.3. Non-Functional Requirements

6.3.4.3.1. User Interface and Human Factors

What kind of interface should the system provide? What is the level of expertise of the users?

6.3.4.3.2. Documentation

What level of document is required? Should only user documentation be provided? Should
there be technical documentation for maintainers? Should the development process be
documented?

6.3.4.3.3. Hardware Consideration

Are there hardware compatibility requirements? Will the system interact with other hardware
system?

11
 6.3.4.3.4. Performance Characteristics

How responsive should the system be? How many concurrent users should it support? What
is a typical or extreme load?

6.3.4.3.5. Error Handling and Extreme Conditions

How should the system handle exceptions? Which exceptions should the system handle? What
is the worse environment in which the system is expected to perform? Are there safety
requirements on the system?

6.3.4.3.6. Quality Issues

How reliable/available/robust should the system be? What is the client’s involvement in
assessing the quality of the system or the development process?

6.3.4.3.7. System Modifications

What is the anticipated scope of future changes? Who will perform the changes?

6.3.4.3.8. Physical Environment

Where will the system be deployed? Are there external factors such as weather conditions
that the system should withstand?

6.3.4.3.9. Security Issues

Should the system be protected against external intrusions or against malicious users? To
what level?

6.3.4.3.10. Resource Issues

What are the constraints on the resources consumed by the system?

6.3.5. System Model

6.3.5.1. Scenario

Scenarios are an instance of a use case explaining a concrete major set of action. Scenario or
use case realizations are just a graphical sequence of events or an instance of a use case.
These realizations are depicted as either sequence or collaboration diagram.

12
 6.3.5.2. Use Case Model

6.3.5.2.1. Use Case Diagram

6.3.5.2.2. Description of Use-Case Model

6.3.5.3. Sequence Diagram

6.3.5.4. Activity Diagram

6.3.5.5. State Chart Diagram

6.3.5.6. Object Model

6.3.5.6.1. Data Dictionary

Document attributes of objects identified.

6.3.5.6.2. Class Modeling

Show the relationship among objects identified using class diagram.

6.3.5.6.3. Dynamic Modeling

Document the behavior of the object model, in terms of state chart diagrams, interaction
diagram (sequence diagrams and/or communication diagram).

6.3.5.7. User Interface

In this section describe navigational paths and screen mock-ups.

6.4. System Design

6.4.1. Introduction

In this section provide a brief overview of the software architecture and the design goals
(Subsystem decomposition, Hardware/software mapping, Persistent data management and
Access control and security). You should also provide traceability information (e.g. how the
design is related to the requirement analysis done in the previous chapter, constraints
impacting the software architecture).

6.4.2. Current Software Architecture (if any)

Current software architecture describes the architecture of the system being replaced.

13
6.4.3. Proposed Software Architecture

6.4.3.1. Overview

This section presents a bird’s-eye view of the software architecture and briefly describes the
assignment of functionality to each subsystem.

6.4.3.2. Subsystem Decomposition

Subsystem decomposition describes the decomposition into subsystems and the

responsibilities of each. This is the main product of system design. Here, use UML
component diagram to diagrammatically depict your components.

6.4.3.3. Hardware/Software Mapping

Hardware/software mapping describes how subsystems are assigned to hardware and off-the-
shelf components (if any). Here, use UML deployment diagram to diagrammatically depict
the hardware/software mapping.

6.4.3.4. Persistent Data Management

Persistent data management describes the persistent data stored by the system and the data
management infrastructure required for it. This section typically includes the description of
data schemes, the selection of database, and the description of the encapsulation of the
database. Here, use E-R diagram if you are using relational database or Object diagram if you
are using object database.

6.4.3.5. Access Control and Security

Access control and security describes the user model of the system in terms of an access
privilege. You can use tables to show the privilege assigned to each users of the system. This
section also describes security issues, such as the selection of an authentication mechanism,
the use of encryption, and the management of keys.

6.4.3.6. Subsystem Services

This section describes the services provided by each subsystem

14
6.4.4. Detailed Class Diagram

In this section,

 Identify missing attributes and operations. During this activity, you need to examine
each subsystem service and each analysis object. You need to identify missing
operations and attributes that are needed to realize the subsystem service.
 Specify visibility and signatures. During this activity, you need to decide which
operations are available to other objects and subsystems, and which are used only
within the subsystem. You need to also specify the return type of each operation as
well as the number and type of its parameters.
 Specify contracts. During this activity, we describe in terms of constraints the behavior
of the operations provided by each object. In particular, for each operation, we
describe the conditions that must be met before the operation is invoked and a
specification of the result after the operation returns.

Here, you can use the UML class diagram to specify attributes and operations with their
visibility information.

6.4.5. Packages

This section describes the decomposition of subsystems into packages and the file
organization of the code. This includes an overview of each package, its dependencies with
other packages, and its expected usage.

Here, use UML package diagram to diagrammatically depict your packages.

6.5. Implementation

6.5.1. Mapping Models to Code

In this section,

 Mapping associations,
o Unidirectional one-to-one associations
o Bidirectional one-to-one associations
o One-to-many associations
o Many-to-many associations

15
  Mapping operation contracts to exceptions,
 Mapping the class model to a storage schema is performed.

6.5.2. Source Codes of Major Classes, Packages or Interfaces

6.5.3. Screen Images

6.6. Conclusion and Recommendation

Matching of the conclusions with the objectives framed and fulfillment of the objectives are
taken into consideration in this part. Further scope and further enhancement of the work done
also indicated here.

6.7. Reference

List all papers, books, monographs, URLs of Internet archives or of permanent information
sources, strictly as per the specific format given above. The references should be ordered in a
convenient way. You should use consistent referencing style such as (Vancouver, Harvard,
Chicago, etc.).

Note: the examples given above follows the IEEE referencing style

6.8. Glossary

Note:

Since most of the project content parts in section 6 are taken from the first book listed in the
reference section, students, advisors and examiners can use the book together with the IEEE
standards to have detailed information about the area they want more clarification.

16
 7. REFERENCE

1. B. Bruegge, A. H. Dutoit, Object-Oriented Software Engineering Using UML,

Patterns, and Jav, Third Edition. 2010.
2. IEEE Computer Society, IEEE Standard for Information Technology—Systems
Design—Software Design Descriptions(IEEE Std 1016™-2009). 2009
3. IEEE Computer Society. IEEE Recommended Practice for Software Requirements
Specification (IEEE Std 830-1998). 1998.

17
 8. APPENDICES

Appendix I: Sample Weekly Contact Monitoring Form

Group Number: _______________ Date __________________

Attendance

Student ID Student Name Present(P) or Absent (A)

Brief Summary of Agenda Discussed

Brief Summary of Decisions Made

Assignments given until next meeting

18
Appendix II: Sample Cover Page

ADDIS ABABA UNIVERSITY

FACULTY OF NATURAL AND COMPUTATIONAL
SCIENCES
DEPARTMENT OF COMPUTER SCIENCE
<<Times New Roman, 18>>

<TITLE OF THE PROJECT>

<<Times New Roman, 18 [Bold]>>

COMP XXXX: FINAL PROJECT

BY
NAME OF THE STUDENTS IDNO
<<Times New Roman, 16>>

PROJECT ADVISOR: <ADVISOR’S NAME>

<<Times New Roman, 16>>

MONTH YEAR
<<Times New Roman, 16>>
19
Appendix III: Sample Declaration

DECLARATION

This is to declare that this project work which is done under the supervision of <<Your
Advisor Here>> and having the title <<Your Title Here>> is the sole contribution of:

<<Group Members Here>>

No part of the project work has been reproduced illegally (copy and paste) which can be
considered as Plagiarism. All referenced parts have been used to argue the idea and have
been cited properly. We will be responsible and liable for any consequence if violation of this
declaration is proven.

Date: _____________________

Group Members:

Full Name Signature

___________________________________ ________________________________

20
Appendix IV: Sample Certificate

CERTIFICATE

I certify that this BSc final project report entitled <<your title here>> by:

<<list your name here>>

is approved by me for submission. I certify further that, to the best of my knowledge, the
report represents work carried out by the students.

_________________________ ____________________________________
Date Name and Signature of Supervisor

21
Appendix V: Minimum Standards

This appendix tries to put the minimum requirements that your project must include. For the
purpose of this section we classify projects into three broad categories:

1. Website Development
2. Mobile Development
3. Other Software Systems

Website Development

Your website should be client/server based. The client part should be developed using
HTML/HTML5, CSS, JavaScript, Ajax and other similar technologies. The server part
should be developed using server side scripting languages like PHP, Perl, ASP, and other
similar technologies. On the server side you need to implement your database using database
server such as MySQL, Microsoft SQL, Oracle and other relational or object oriented
databases.

Concerning your webpages, there must be

 Login page at least for website administrators

 Feedback page for collecting user comments and suggestions

Mobile Development

If you are designing software for mobile devices, your application should meet requirements
of good mobile application development guidelines such as using screen, battery, storage,
computing and other resources efficiently.

You can develop standalone application or an application that work in collaboration with
other mobile devices, sensors or websites like Facebook, Google, and Twitter.

For developing your mobile application you can use technologies Android, IOS, and
Microsoft phone.

Other Systems

Any other software system that can solve real world problems can come under this category.
Your software under this category can be an application that follows client/server

22
architecture, peer-to-peer architecture, or it can be standalone software. You can use C#,
Java, Python, Ruby or any other programming language to develop your software. Use of
IDE such as Microsoft Visual Studio, Net beans, Eclipse, or any other Software development
environment that will assist you in accomplishing your task is highly recommended.

You are expected to provide setup file or deployment mechanism for your system.

For all of your systems

 Appropriate user interface which apply the major user interface design principles is
expected.
 Input validation and exception handling components are expected to be included
 Appropriate login and logout mechanisms must be there.
 In your database there must be at least three related tables
 All your database tables should have appropriate field names, primary key, foreign
key and indexes.
 All relational databases must be normalized

23