Project Writing Guideline

Wollo University
Kombolcha Institute of Technology
College of Informatics

Final year Project Writing Guideline

Prepared by Committee:-
1. FeyisaGemechu -----------------Chairman and Member
2. Ashenafi Workie ----------------Secretary and Member
3. Amare Kebede ------------------Member
4. Tibebu Legesse-------------------Member

1
 Project Writing Guideline

Front/Title Page
The front (title) page must be as follows:

University LOGO

Wollo University

Kombolcha Institute of Technology

College of Informatics
Department of ___________________________

Title: - _____________________________________________________

PREPARED BY: 1. _______________________________

2. _______________________________
3. _______________________________
4. _______________________________

Advisor’s name: - _____________________________________

Kombolcha, Wollo, Ethiopia

January 2018

2
 Project Writing Guideline

Real life project is an essential part of the university curriculum for the students of [Link]
in Information Systems, Computer Science, Information Technology and Software
Engineering. Following guidelines are designed for the graduate students of Informatics
college for their final year project work. It will serve for uniformity and consistency in
project proposals and main project writing by the target students.
1. Format or writing style in Final Year “ Senior Project”
Paper size and margins
- Use A-4 paper (8 1/2 x 11”) and 2.5 cm for all margins of the manuscripts
Line and paragraph spacing
- Use 1.5 spacing for the body of the text, except for tables and references, where
you need to use single line spacing. Do not indent paragraphs but use block typing
and no need of background effects. Alignment of the text is essential.
Font type and font size
- Capitalize only the first letter of each word, excluding common words in the title
and make its font 16 and Bold. The common words are prepositions, conjunctions
or connectives (such as: of, in, a, and, or, etc.)
Example 1: Title & Font size

Your Title of The Project (write the title here)

- Capitalize only the first letter of the main heading and make its font size 16 and
bold as above.
Example 2: Subheading and Font size
Chapter One
Introduction
- Capitalize only the first letter of the subheading and make its font size 14 and
bold as above.
Example 3: Sub-subheading
- If there is a sub-subheading, capitalize only the first letter and make it italic with a
font size of 12 without bolding as above.

3
 Project Writing Guideline

Content of the project and Their Description

o PART ONE: Introduction
 Overview and Background
 This section should provide background and context, clearly identifying the topic
area. For a project, it should show how the proposed project fits into what is
already known and contributes to knowledge and the production of new products,
services, methods or techniques in the subject area.
 Describe the background of the problem, giving a measure of its magnitude (how
widespread and important it is). For a project, clearly identify the project goals.
Give summary of the objectives of the proposed project, its significance, how the
data (if any) will be collected, how it will be analyzed, and what results (possible
outcomes) are expected.
 While this section is the first presented, it is better to write it after completing the
rest of the proposal since most of the text for this section emanates from the rest
of the sections.

 You should describe the general information what we want to develop in our
systems, because it is very important to know our system

 It also describe the project area you are working on. For example, if you are
working on a title called “Online Banking for X Company”, then you should write
about Online banking in general.

 Also, write about the organization for which you are developing the system. It
should summaries the background information to the problem to be studied and
the context within which it will be studied. It shows also the significance of the
study, research idea etc.
 Problem/Opportunity Statement
 This section should consist of a brief summary of the problem that is proposed to
be investigated, what question/hypothesis is intended to be addressed, and how
the student envisions doing it. It should provide a clear and concise description of
the central problem to be investigated and the questions to be answered.

4
 Project Writing Guideline

 At this line you list the main problem that is why you want to develop the system
(i.e. if the system is already developed you can identify the problem by which
types of feature needed to expand and advance it b/c still you look the developed
system needs some additional change or modification. )
 In the statement of the problem, you identify the problems that exist in the current
system the organization uses and list them down. In addition, you have discuss
about the effects of the problems on the company’s operations.
 Objectives of the Project
 Clearly outline the general and specific objectives of the thesis research or
project. List the general objective, describing the ultimate goal of the research,
and the specific objectives. The objectives should be specific and realistic in
terms of capacity, resources, and time. During the actual work, it is possible that
these objectives may be modified.
 Significance of the Project
 Outline the probable application of results and who will benefit from your
results and how.
 Scope of the Proposed System
 Limitations that may be beyond the control of the researcher and restrict
the research’s conclusions should be indicated here. The restrictions that may
be placed on the research by the student and that may affect conclusions need
to be specified. The proposed work could be one that tries to achieve part of a
bigger problem. In this case, the scope has to be limited based on time and
other resources. The remaining part can be proposed as future work later in
writing the thesis/project report which can be done by the researcher
himself/herself or by others.
 Methodology
 Usually, this section lists the list of activities to be carried out in order to achieve
the objectives. Describe in general terms the methods to be employed to achieve
the objectives of the project including data sources, collection, different approach
for system documentations and tools and software's for implementation.
 Show how each specific objective will be achieved, with enough detail to enable
an independent and informed assessment.

5
 Project Writing Guideline

Data Gathering Method:- As you know to develop one system you need an
information, so to get it you want to ask the manager that hotel (experts) by
preparing question, brainstorming, Interview and observation.
System Analysis and Design Approach:- Describe the way of designing approach
like OOSAD or SSAD, but the best one is OOSAD b/c it helps reusability,
extensibility and inheritance of code and others.
Implementation Methodology:- Hardware tools required and Software tools
required. Example, write the software tools you had to use, if assume you are using
xampp or wampp, window 10 OS, notepad++, sublime editor etc.
 Feasibility Analysis
 Feasibility study is used to investigate the proposed system is in a multiple
dimensions. It will be used to indicate whether the system you are going to do is
feasible or not. The proposed system can be seen according to the following lists.
Operational feasibility:- Write down that your system will be operationally
feasible to achieve the specified objective, User friendly and interactive with the
environment. Answer the question that, Will the solution or the project you are
going to develop fulfill the users’ requirements?
Technical feasibility: - Technical feasibility is the measure of practicality of the
specific technical solution and the availability of technical resources and expertise.
Answer the question that, Is the solution or your project is technically practical?
Economic feasibility:- Economic feasibility is the process of identifying the
financial benefits and costs associated with the project being developed. Answer the
question that , Is the solution or your project is cost-effective?
Schedule feasibility:- Can the project be accomplished in a reasonable period?
Project management critical path scheduling can help answer this concern.

6
 Project Writing Guideline

o PART TWO: Description of the Existing System and Requirement

Gathering
 Determining system requirements
 Detail overview of the existing system using Requirement gathering techniques
 Problems encountered by the existing system
 Introduction of Existing System
An important part in software development is to explore requirements for your system.
Usage modeling explores how people works with a system, vital information that you
require if you are going to successfully build something that meets their actual needs.
You cannot successfully build a system if you do not know what it should do, and a
critical aspect of this is exploring how people will actually use the system
The existing system description describes the current system of the organization as it is.
This could be describing the activities they perform, how they handle information, and
the drawbacks of the system.
Supplementary Requirements
Business Rules
Write the rules used by the organization currently. In the case of online banking, this
could be the interest rate allowed for saving account, the maximum amount of money that
someone can withdraw at a time, interest rate for loan etc. Generally, they are the rules by
which the business is governed.
Constraints
Constraints are effectively global requirements, such as limited development resources or
a decision by senior management that restricts the way you develop a system. Constraints
can be economic, political, technical, or environmental and pertain to your project
resources, schedule, target environment, or to the system itself. The followings are some
examples:
Organization structure (if any) :- Draw the organizational structure to know about
every flow of activities in the current system.
Users of Existing System:- List and describe the player of the existing system are
Major functions of the Current System:- Write down the main function of current
working style of your system.
Existing System Workflow Structure:- Write the work flow as you want or design for
more clarity of your system development.
7
 Project Writing Guideline

Report generated in the existing system (if any):- Write the way how the existing
system can generate reports with diagram or description as you wish both are the best to
show the flow of reports.
Forms and other documents of the existing systems (if any):- If you have the form that
means existing system form and other important documents you can put.
Bottlenecks of the existing system (using for example PIECES frame Work):- It refers to
problems or you can say the challenges you look as the following angles:-
Input (Inaccurate/redundant/flexible) and Output (Inaccurate):- Based on input of
some data it may be disorder.
Security and Controls:- Based on security you can explain it Efficiency
Software requirement specification (SRS):- The purpose of the SRS is to do the
following:
Functional Requirements
 Define the Functional Requirements: Describe the functional requirements of
the system. What functionalities does the system have? Then proceed to show it
using use case diagram under the next topic use case diagram.
 Identify the boundaries of the system
 Identify the users of the system
 Describe the interactions between the system and the external users
 Establish a common language between the client and the program team for
describing the system.
 Provide the basis for modeling use cases.

To produce the SRS, you interview the business owners and the end users of the system.
The goals of these interviews are to clearly document the business processes involved
and establish the system’s scope. The outcome of this process is a formal document (the
SRS) detailing the functional requirements of the system. A formal document helps to
ensure agreement between the customers and the software developers. The SRS also
provides a basis for resolving any disagreements over “perceived” system scope as
development proceeds.

8
 Project Writing Guideline

Nonfunctional Requirements
Define the Non-functional Requirements and Constraints: Describe the non-functional
requirements of the system like security, performance, reliability, etc.
Describe the inside part of your system function, it is not tangible or we can’t see with
eye, but still your system performs its function
E.g Speed, reliability, accuracy …etc.

Modeling the existing systems

 Essential Use Case Modeling
 A use case describes something of value to an actor (often a person or organization).
An essential use case is a use case that is technology independent—it describes the
fundamental business task without bringing technological issues into account.
Essential use cases are often used to explore usage-based requirements.
 Essential User Interface Prototyping
 A technology-independent prototype created using paper that can be used to identify
UI requirements.
 Essential User Interface Prototyping flow diagrams
 A diagram that depicts major UI elements and how users transition between them;
used to explore the high-level usability of a system or to overview/ document the user
interface of a system.
 Domain modeling with class responsibility collaborator (CRC)
 A class responsibility collaborator model is a collection of standard index cards that
have been divided into three sections, as depicted in. A class represents a collection of
similar objects, a responsibility is something that a class knows or does, and a
collaborator is another class that a class interacts with to fulfill its responsibilities.
 There are three different types of classes: Business, Actor and User Interface classes.
 So to create CRC models? Iteratively perform it by finding classes, responsibilities
and collaborators.

9
 Project Writing Guideline

o PART THREE: System Analysis

 System models :- You will describe at this chapter the system use case diagrams, the
use case descriptions (scenarios), sequence diagram, and activity diagrams. State
diagram after identifying the actors and use cases, the use cases are developed and
description of use case are stated. The sequence diagram drawn based on the use
cases, which are developed for the proposed system. The activity diagrams will
represent activities.
 System Use Case Modeling
 System use cases are use cases that bring technological concerns into account.
System use cases are the primary requirements artifact for the rational unified
process although they are arguably analysis and perhaps even design artifacts.
 It show the functionality of your system using use case diagram and how the
actors interact with the system. A textual/graphical description of how the system
will behave from the users’ perspective. Users can be humans or other systems.
Also show use case reusability by including <<include>>, <<extend>>, and
<<inherit>> relationships between use cases.
 Use case documentation:- To document the use case we have two ways of use
case documentation, Narrative style and Action response style.
 Sequence Diagrams: From Use Cases to Classes
 UML sequence diagrams model the flow of logic within your system in a visual
manner, enabling you both to document and validate your logic, and are commonly
used for both analysis and design purposes. In fact they are often described as the
bridging technique between analysis artifacts such as system use cases and UML
class diagrams. Sequence diagrams are the most popular UML artifact for
dynamic modeling. Sequence diagrams, along with class diagrams and physical
data models, are in my opinion the most important design-level models for modern
business application development.
 Sequence diagram showing the sequence of interactions among objects and used to
represent or model the flow of messages, events and actions between the objects or
components of a system. Sequence Diagrams are also used primarily to design,
document and validate the architecture and interfaces of the system by describing
the sequence of actions that need to be performed to complete a task or scenario.

10
 Project Writing Guideline

 Conceptual Modeling
 Shows the class, interrelationship (including inheritance, aggregation and
association), and the operations and attributes of the classes. Start by putting the
Domain Model (CRC) as a base. While CRC modeling provides an excellent
overview of a system, it doesn’t provide the details needed to actually build it.
 Activity diagramming
 UML activity diagram are used to document the logic of a single operation/method, a
single use case or the flow of logic of a business process. In many ways, activity
diagrams are OO equivalent of flow charts and data flow diagrams from structured
development. An activity diagram illustrates the dynamic nature of a system by
modeling the flow of control from activity to activity. An activity represents an
operation on some class in the system that results in a change in the state of the
system. Typically, activity diagrams are used to model workflow or business
processes and internal operation. By considering the above expression you can draw
activity diagrams to show the operations/activities performed by use cases to achieve
their functionality. Activity diagrams draw for each use case, but it is not mandatory
to draw all. An Aactivity diagram is essentially a flowchart, showing flow of control
from activity to activity it involves. If assume you want to do activity diagram for
login like this, but before doing it you know about how to draw the AD
 User interface prototyping

 UI prototyping is an iterative analysis technique in which users are actively involved

in the mocking-up of the UI for a system. UI prototypes have several purposes:

 As an analysis artifact that enables you to explore the problem space with your
stakeholders;
 As a design artifact that enables you to explore the solution space of your system;
 As a vehicle for you to communicate the possible UI design(s) of your system; and
 As a potential foundation from which to continue developing the system (if you
intend to throw the prototype away and start over from scratch then you do not need
to invest the time writing quality code for your prototype)

11
 Project Writing Guideline

o PART FOUR: Systems Design

 Class Modeling
 Used to model the static part of the systems. The design class model will reflect the
wide variety of technology decisions you make. Focus is on the solution domain not
on the problem domain. Introduce change to your class model based on
implementation technologies. On design class diagrams, indicate the visibility, name,
parameters, return value, and stereotype of methods. Names of parameters, as
well as their types and default values should be indicated for each methods. Scope of
a method, weather it is a static method that works on the class or an instance
method, that works on instances of the class.
 State chart modeling
 Objects have both behavior and state or, in other words, they do things and they know
things. Some objects do and know more things, or at least more complicated things,
than other objects. Some objects are incredibly complicated, so complex that
developers can have difficulty understanding them. To understand complex classes
better, particularly those that act in different manners depending on their state, you
should develop one or more UML state machine diagrams.
 Collaboration Modeling

 Classes often need to work together to fulfill their responsibilities. Actually, it is

typically the objects and the instances of the classes that are working together.
Collaboration occurs between objects when one object asks another for information
or to do something. For example, an airplane collaborates with its engines to fly. For
the plane to go faster, the engines must go faster. When the plane needs to slow
down, the engines must slow down. If the airplane did not collaborate with its
engines, it would be unable to fly.

 Component Modeling
 Component-based development (CBD) and object-oriented development go hand-in-
hand, and it is generally recognized that object technology is the preferred foundation
from which to build components. I typically use UML component diagrams as an
architecture-level artifact, either to model the business software architecture, the
technical software architecture, or more often than not both of these architectural

12
 Project Writing Guideline

aspects. Physical architecture issues, in particular hardware issues, are better

addressed via UML deployment diagrams.
 Deployment Modeling

 A UML 2 deployment diagram depicts a static view of the run-time configuration of

processing nodes and the components that run on those nodes. In other words,
deployment diagrams show the hardware for your system, the software installed on
that hardware, and the middleware used to connect the disparate machines to one
another. You want to create a deployment diagram for applications deployed to
several machines, for example, a point-of-sales application running on a thin-client
network computer that interacts with several internal servers behind your corporate
firewall or a customer service system deployed using a Web services architecture
such as Microsoft'[Link]. Deployment diagrams can also be created to explore the
architecture of embedded systems, showing how the hardware and software
components work together. In short, you may want to consider creating a deployment
diagram for all but the most trivial of systems.

 Relational Persistence Modeling

 Also called data modeling; persistence models are used to communicate the design of
database, usually relational database, with the user and other developers. This is basically the
entity relation in database application. Persistent modeling is used to depict the design of the
database. The team is going to use the relational database since it is the most used data base
system recently. The persistent classes are used to store most important and permanent
information of the system. In persistent modeling we will perform the following activities.
 Identifying keys:
 Primary: Identifies unique instance of an entity.
 Foreign: This will help us to show the relationship between two tables
or classes.
 Identifying entities: Entities which are the persistent classes will be stated with
their attributes.
 The methods of the classes will be used.
 Multiplicity and optionally as well as visibility of the attributes will be
included
 Inheritances will be included and if there is any associations exist they will also
be included.

13
 Project Writing Guideline
 The attributes will be given data type and initial sizes.

 User Interface Design

 As you develop the user interface of your system you should be aware of basic UI
design issues. UI design is a complex task, one that requires a wide range of skills to
be successful. Most decisions regarding the design of your system's UI, or affecting
its usability, are made by ordinary developers. Therefore it is important that all
developers have an understanding of the basics of UI design.
o PART FIVE: Conclusion and Recommendation
 Conclusion & Recommendation

14
 Project Writing Guideline

Content Layout
Preliminary pages

I. Title page (See its format)

II. Approval sheet
III. Dedication (optional)
IV. Acknowledgements
V. Table of contents
VI. List of figures
VII. List of Tables
VIII. Abstract
IX. Abbreviations
X. Patents Information (optional)
Chapter One: Introduction
1. Introduction
1.1 Background of the Organization
1.2 Background of the project
1.3 Statement of the problem
1.4 Objective of the project
1.4.1. General Objective
1.4.2. Specific objective
1.5 Feasibility Analysis
1.5.1 Operational feasibility
1.5.2 Technical feasibility
1.5.3 Economic feasibility
 Cost Benefit Analysis
 Cost of the project
1.5.4 Behavioral/Political feasibility
1.5.5 Schedule feasibility
1.6 Scope and significance of the project
1.7 Methodology for the project
1.8. Communication Plan
1.9. Team composition
Chapter Two: Description of the Existing System and Requirement Gathering
2.1 Introduction of Existing System
2.2 Players in the existing system
2.3 Major functions/activities in the existing system like inputs, processes &
15
 Project Writing Guideline

outputs
2.4 Business rules
2.5 Report generated in the existing system
2.6 Bottlenecks of the existing system (using for example PIECES frame Work).
2.6.1 Performance (Response time)
2.6.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate)
2.6.3 Security and Controls
2.6.4 Efficiency
2.7 Proposed solution for the new system
2.8. Requirements of the Proposed System
2.8.1 Functional requirements
 Performance requirements
 Process requirements
 Input related requirements
 Output related requirements
 Storage related requirements
2.8.2 Non functional requirements
 Performance
 User Interface
 Security and Access permissions
 Backup and Recovery
2.9 Modeling the existing systems
2.9.1. Essential Use Case Modeling
2.9.2. Essential User Interface Prototyping
2.9.3. Essential User Interface Prototyping flow diagrams
2.9.4. Domain modeling with class responsibility collaborator (CRC)
Chapter Three: System Analysis (Modeling the Proposed System )
3.1 Introduction
3.2 Modeling proposed systems
3.2.1 System use case diagrams
3.2.2 Use case documentation (for each use case identified)
3.2.3 Sequence diagram
3.2.4 Activity Diagram
16
 Project Writing Guideline

3.2.5 Analysis level class diagram (conceptual modeling)

3.2.6 User Interface Prototyping
Chapter Four: System Design
4.1 Introduction
4.2 Class type architecture
 User interface layer
 Controller/process layer
 Business/Domain layer
 Persistence layer
 System layer
4.3 Class modeling
4.4 State chart modeling
4.5 Collaboration Modeling
4.6 Component Modeling
4.7 Deployment modeling
4.8 Persistence modeling
4.9 User Interface design
Chapter Five: Implementation and Testing
5.1 Introduction
5.2 Final Testing of the system
5.3 Hardware software acquisitions
5.4 User manual preparation
5.5 Training
5.6 Installation Process
5.7 Start-up strategy
Chapter Six: Conclusions and Recommandation
6.1 Conclusions
6.2 Recommandations

 Appendix
 Références

17
 Project Writing Guideline

Final form deliverables:

 Documentations, both in hard copy and softcopy
 Software (on CD)

Project Presentation & Demonstration

As part of the assessment, students will be required to make a presentation and
demonstration of their project to their assessment team/examiners.
Each presentation will be timetabled for between “time allowed” (to be announced)
including questions and answers. Second marker will be part of the team but you should
bear in mind that the majority of the panel will not be familiar with your project; you
should take this into account when planning your presentation. Your advisors will help
you to structure your talk and will be willing to go through it with you beforehand. The
presentation and demonstration are assessed separately and compulsory component of the
project. The assessment team will not allocate a mark for a project unless there had been
a formal presentation and demonstration based on the schedule for each. The objective of
the presentation is to find out exactly what you have done and to ensure that you get an
accurate mark that is consistent with other projects - it is not designed as an opportunity
to shoot you down!

Prize
The top projects recommended by examiners will be reviewed shortly after the
presentations and a list of prize candidates will be drawn up. These “prize finalists” will
be invited to re-present their work at a special celebration event open to the university. At
the end of the day there will be a vote for a “Best Presentation” award and the
departmental project prizes will be decided some time afterwards on the basis of the
university wide presentations, reports and assessment team comments.

18