Kombolcha Institute of Technology

College of Informatics
Department of Software Engineering

We here by Submitted a project in <Title >in partial fulfilment of bachelor’s

Degree in Software Engineering
Submitted to the departments of <department>

Group Members:

No. Name ID Number

1. ……………….. …….
2. ……………….. ……..
3. ……………….. ………
4. ……………….. ………

Advisor’s Name: _______________________ Signature_________________

DD/MM/YYYY
Discriminary
We hereby declare that our project in titled <your title here> is original and not
submitted/Published by any individual/ Organization.

Group members
S.N. Name List ID Number date ----/----/2022 sign:
1.
2.
3.
4.

Advisor’s
Name: Date: ---------/----/2022 Sign:
Acknowledgement

This is optional, although most reports include a brief statement of thanks in recognition of
special assistance and guidance given by individuals, institutions or government bodies.
 03/04/2022
Table of contents

The titles of sections, chapters and their principal subdivisions along with the page numbers on
which they appear should be listed in the Table of Contents. Titles should be worded exactly as
they appear in the text of the report. Reports with many subdivisions should use a hierarchical
numbering system for headings and sub-headings (e.g., 3.1). Such a numbering system combined
with the judicious use of upper and lower case, indentations and italics should provide a
summary of the relationships between the sections of the report. The table of contents should be
generated automatically. The following is a recommended content structure.
Lists of Tables, Figures/Illustrations, Plates/Photographs

These lists consist of the exact titles (including numbering) of all tables, figures and plates that
appear in the report. All tables, figures and plates should be numbered consecutively throughout
the text.
List of Abbreviations, Symbols, Specialized Nomenclature

This list is optional, depending on the subject of the report. All scientific symbols and
nomenclature should follow the standard SI-system.

Abstract
An abstract in both Amharic and English are required. The English version must include the title
written in English for a report written in Amharic, and vice versa. The abstract is a summary of
the entire report. It should briefly outline the research problems addressed by the report, the
findings, and the significance of the work in the context of the field of study. The abstract should
not exceed one typewritten single-spaced page of text (c. 300-400 words) with the font size of 12
points. Abstracts in English should be in italic.

Chapter One: Introduction

1.1Introduction
This chapter is concerned with similar concerns to the abstract and should provide an overview
of the report with more detail. The methodology should be stated and describe here as different
section. The contribution of the student should be stated precisely and in detail. The structure of
the report should be given detailing where each chapter fits within the overall and what each
contributes; it may be useful to provide a diagram showing dependencies and relationships
between chapters.
Chapter 1: Is often the last chapter to be written, and to be checked carefully before submission.
It is a key chapter, which the external examiner may read when making his assessment as
illustrated below.
1.1.1 Background of the organization
This sub topic is concerned the selected organization’s target goal in line with the proposed
project under development. More specifically, it addresses the point of organizational vision,
mission and core values in associated to the project.
1.1.2 Existing System of the project
Under this subtitle students should mention what existing system is, how it is functioning, is that
manual? Automated? Semi-automated? Or considered as continuing as it is, has a tendency to do
projects and opportunities? Or even proceeded as legacy system. So that students must mention
the details about the existing system merits and demerits in comparation to the proposed system.
1.1.3 Statement of the problem
Under this section, students clearly elaborate the existed problems in detail. Even students must
mention why the problem raised. At the same time, the proposed system should entails what are
the positive and negative consequences in the way forwarded to solving the mentioned problem.
The existed problem must be explained in a manner to be counted whether it is properly solved
or not. Keep in mind that each problem must be stated not listed.
1.1.4 Proposed System
Once the problem mentioned and the existing system identified, here students are required to
proposed the alternative solutions against or in complementary to the existing system.
1.2Objective
1.2.1 General Objectives
The general objective is the overall objective while properly developed and deployed the
project.
 1.2.2 Specific Objectives
Under this section, students must list the questions to be answered by the project in parallel to the
already stated problems. In fact, here students must solve the entire aforementioned problem in
the statement of the problems with the proposed solutions. Since stated problems are counted, the
specific objectives are also counted and formatted in a form to be check listed.
1.3Scope and limitation of the project
1.3.1 Scope
The scope of the project precisely states the mandate areas where the project is deployed, the
system requirements satisfied under this project or not to be covered. Please states the boundary
of the project. in what level you will address the projects domain.
1.3.2 Limitations
The limitation is all about the underdevelopment systems compatibility, portability,
maintainability and other related limitations as viewed from users and technological
perspectives. The system functionality that you didn't address in this version of project due to
constraints is said to be Limitation. do not mix limitation with
1.4Methodology for the project
The project methodology entails, the software and hardware tools used in realizing the proposed
project and the rationales behind each selection. It also required mentioning the project
development approaches, paradigms in detail reasoning to help fact-finding techniques.
1.4.1 Data collection and fact-finding techniques
In this section member of the project explains the extent source of data for the proposed project.
It also illustrates the requirement elicitation approaches through which method of data collection
they can found the exact data /Source of Information including the type of Information source
either from primarily, secondary and from others.
1.4.2 System analysis and design approach
1.4.3 Technology requirements
Software requirements
Hardware requirements
1.5Feasibility Study
Here, students must explain the proposed systems technical, operational, economic, legal, and
political feasibility. It is clearly stated the improvements now and in the long run in all
perspectives.
1.5.1 Technical Feasibility
1.5.2 Operational Feasibility
1.5.3 Economic Feasibility
1.5.4 Legal Feasibility
1.5.5 Political Feasibility
1.6Risk assessment strategy
Students should mention what are the possibly expected risks in developing the proposed project.
This is evaluated, in line with completing the project within the scheduled time. In case external
barrios are suggested, list out the recommended contingency management alternatives.
1.7Significance of the project
Highlights the value that the project outcomes may provide in the field or real-world practice.
This section highlights the positive contribution of completing the study or project
1.7.1 Beneficiary of the project
Detail explanation the beneficiary of the project
For Clients (project owner)
For System users
For developer (for you)
1.8Schedule of the project
using the already available sheduling tools such as giant chart and others, proporely, scheduled
for each project components.
1.9Project Budget break-down and cost analysis
The budget of the project is clearly explained. Under this section students should do some
preliminary investigation what hardware and software tools used to do the project and metric
those all in cash. Furthermore, the budget analysis encompasses the situations leading cost not
only for the project developers but also for the deployment Organizations including all other
contingency management plan.
1.10 Team composition of the project
Under this section, students must show who is a focal person identified componets of the project
as per the scheduling guideline. But make sure that each member of the project
underconstruction must know in depth abou the entire projects component and contribute for the
entire project’s quality perimetrs by providing multiple alternatives and choosing the rationale
among alternative aspects.

Chapter Two System Requirement Specification

2.1 Background (Overview)
This chapter should first present the background to the area of investigation and establishing the
context of the problem. Understanding the problem domain in detail should be the first step and
it is a foundation for the rest of the project work. Often this background consists of a survey and
review of literature/documents associated with the problem context. Sometimes on site
observation might be necessary.
The literature should not simply be represented but critically analyzed by the student. All
sources used should be precisely cited in the text, i.e. in a way that enables the reader to access
the source. If material is copied directly then it should be placed in quotes and the reference
given quoted. In general, copying of this type should be avoided. If a diagram is copied then the
caption should give the reference.
The major concern of this chapter is establishing the detailed requirements specification for the
work. The nature of these requirements depends on the type of project being investigated. These
requirements could be obtained from a number of sources (many of which may have been
discussed in detail in the background). The chapter should indicate the ways in which the
requirements have been obtained. Once obtained the requirements should be expressed,
prioritized and detailed in an appropriate form. As much as possible the requirements should be
measurable and quantified so that it can be determined if they have been met.
Requirements should be classified as functional and non-functional requirements. You should
follow and apply Software Engineering practices for user requirements elicitation and
engineering.
Please refer your Software Engineering course on requirements elicitation and engineering.
Details are explained below.
 1.10.1Scope
Show the exact part of project planning that involves determining and documenting a list of
specific project goals, deliverables, tasks, cost and deadlines. The Project Scope pertains to the
work necessary to deliver a product

1.10.2Purpose
Identify the product whose software requirements are specified in this document, including the
revision or release number. Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a single subsystem

It is where you state the purpose of the project in line with the requirements specification.
1.10.3Document Convention
Describe any standards or typographical conventions that were followed when writing the SRS,
such as fonts or highlighting that have special significance. For example, state whether priorities
for higher-level requirements are assumed to be inherited by detailed requirements, or whether
every requirement statement is to have its own priority. Use your report convention

Indicators Most common and recommended

Alignment Justified
Margin Left=3cm, right=2.5, top=2.5, bottm=2.5
Title font size /heading 1 e.g 16pt ,bold

Chapter One
Sub Title font size /heading 2 e.g 14pt
1.1Introduction
Sub Title font size /heading 3 e.g 12pt
1.1.1 Introduction
Whole document / Normal text Font size 12
Font style Regular
Font type Time New Roman
Page Color White
Language English
 Line between 1.5
Correction with fluid Not allowed
Typing machine Computer
Crossing out words Not allowed
Printing quality Laser or later quality
Font color Black

1.10.4Intended Audience and Suggested Readings

Describe the different types of reader that the document is intended for, such as developers,
project managers, marketing staff, users, testers, and documentation writers. Describe what the
rest of this SRS contains and how it is organized. Suggest a sequence for reading the document,
beginning with the overview sections and proceeding through the sections that are most pertinent
to each reader type

1.1.1 List of Acronyms, Abbreviations and Definitions

Describe all used abbreviated terms, symbols, and definition wise aspects in your documentation.
1.2Overall Description of Software Requirements
Put the rationale behind requirement specifications in relation to your working environment. So
as to assure, your competitive advantage in all cost, quality and timing dimensionality, your
requirement specification must be tightly elaborated.

1.2.1 Product Perspectives

Describe the context and origin of the product being specified in this SRS. For example, state
whether this product is a follow-on member of a product family, a replacement for certain
existing systems, or a new, self-contained product. If the SRS defines a component of a larger
system, relate the requirements of the larger system to the functionality of this software and
identify interfaces between the two. A simple diagram that shows the major components of the
overall system, subsystem interconnections, and external interfaces can be helpful.>2.2.2.
Product Features/Functions

List out and elaborate the required functional requirements from the users’ perspectives.
 1.2.2 User characteristics
Identify the various user classes that you anticipate will use this product. User classes may be
differentiated based on frequency of use, subset of product functions used, technical expertise,
security or privilege levels, educational level, or experience. Describe the pertinent
characteristics of each user class. Certain requirements may pertain only to certain user classes.
Distinguish the most important user classes for this product from those who are less important to
satisfy.

1.3General Constraints
Here you have to mention the overall hardware and software Constraints while developing and
deploying the proposed project.

1.3.1 Software constraints

Describe the Operating Environment that the product is intended to run on. Specify Design and
Implementation Constraints. Describe any issues that will limit the options available to the
developers. These might include corporate or regulatory policies, hardware limitations and so on.

1.3.2 Hardware Constraints

It is optional that, if you propose a new and cross discipline project you may fail comfort in
accessing required hardware apparatus. But it does not mean a problem in the long run as far as
the project is feasible.

1.3.3 Assumptions and Dependencies

List any assumptions that could affect the requirements stated in this SRS. Third party or
commercial components that you plan to use or issues around the development. These
requirements are affected if these assumptions are not shared, are incorrect or change.
1.3.4 User Documentations
You describe how you are going to distribute your documentation to your customer and product
users in a part.
1.4Specific Requirements
In order for your development team to meet the requirements properly, we MUST include as
much detail as possible. This can feel overwhelming but becomes easier as you break down your
requirements into categories.
1.4.1 User requirements
Describes the business needs for what users require from the system. User Requirements
Specifications are written early in the validation process, typically before the system is created.
They are written by the system owner and end-users, with input from Quality Assurance.
1.4.2 Functional Requirements
Itemize the detailed functional requirements associated with this feature. These are the software
capabilities that must be present in order for the user to carry out the services provided by the
feature, or to execute the use case. Include how the product should respond to anticipated error
conditions or invalid inputs. Requirements should be concise, complete, unambiguous,
verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary information is
not yet available
Indicate what a software system must do and how it must function; they are product features that
focus on user needs. Each requirement should be uniquely identified with a sequence number or
a meaningful tag of some kind
1.4.3 Non-Functional Requirements
States that a requirement that specifies criteria that can be used to judge the operation of a
system, rather than specific behaviors. These includes performance, safety, security etc.
1.5External Interface requirements
1.5.1 User Interfaces
Describe the logical characteristics of each interface between the software product and the users.
This may include sample screen images, any graphical user Interfaces standards or product family
style guides that are to be followed.
1.5.2 Hardware Interfaces
Instead, describe the logical and physical characteristics of each interface between the software
product and the hardware components of the system.
 1.5.3 Software Interfaces
Are the connections between this product and other specific software components (name and
version), including databases, operating systems, tools, libraries, and integrated commercial
components.
1.5.4 Communication Interfaces
Describe in this part the requirements associated with any communications functions required by
this product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on.
1.6System requirements Modeling
It is all about a document or set of documentation that describes the features and behavior of a
system or software application. It is all about a technical representation of the system. It acts
as a link between system description and design model. In Analysis Modelling, information,
behavior, and functions of the system are defined and translated into the architecture,
component, and interface level design in the design modeling.
1.7Essential use case Diagrams
You must entail a structured narrative, expressed in. the language of the application domain
and of users, comprising a simplified, generalized, abstract, technology free and implementation
independent description of one task or interaction that is complete, meaningful, and well defined
You have to describe the functionality provided by a system in terms of actors, their goals
represented as use cases, and any dependencies among those use cases. Here you have also
elaborate the use case descriptions as represented in the system use case diagram without
compromising their dependencies and their definiteness.
 Chapter Three Requirement Analysis Modeling
3.1Overview of Analysis Model
Requirements analysis is an elaboration of the basic requirements established during requirement
elicitation. This is the first technical representation of the proposed system using a series of
requirements modeling approaches like,
Once you identify your system requirements in chapter 2, you should elaborate it using the above
requirements modeling approaches. This chapter is a basis for the design phase.

A model captures aspects important for some application while omitting (or abstracting) the rest.
A model in the context of software development can be graphical, textual, mathematical, or
program code-based. Models are very useful in documenting the design and analysis results.
Models also facilitate the analysis and design procedures themselves. Graphical models are very
popular because they are easy to understand and construct.
Rationales behind need for a model: An important reason behind constructing a model is that it
helps manage complexity. Once models of a system have been constructed, these can be used for
a variety of purposes during software development, including Analysis, Specification, Code
generation, Design, Visualize and understand the problem and the working of a system and
Testing,
3.2System use case Diagram
You have to describe the functionality provided by a system in terms of actors, their goals
represented as use cases, and any dependencies among those use cases. Here you have also
elaborate the use case descriptions as represented in the system use case diagram without
compromising their dependencies and their definiteness.
 3.2.1 Scenario
Describes the situation in which a limited consideration for each and suggested requirements are
failed to meet customers’ or systems requirements. So as consider alternative approaches, a list
of possibly considered situations are predetermined with a list of possible solutions.
3.2.2 Use case Model
The use case model for any system consists of a set of “use cases”. Intuitively, use cases
represent the different ways in which a system can be used by the users. A simple way to find all
the use cases of a system is to ask the question: “What the users can do using the system?”
3.2.3 Use case Description
Each ellipse on the use case diagram should be accompanied by a text description. The text
description should define the details of the interaction between the user and the computer and
other aspects of the use case. It should include all the behavior associated with the use case in
terms of the mainline sequence, different variations to the normal behavior, the system responses
associated with the use case, the exceptional conditions that may occur in the behavior, etc. The
behavior description is often written in a conversational style describing the interactions between
the actor and the system. The text description may be informal, but some structuring is
recommended.

3.3 Sequence Diagram

Here shows object interactions arranged in time sequence in the field of software engineering. It
depicts the objects involved in the scenario and the sequence of messages exchanged between
the objects needed to carry out the functionality of scenario.
A sequence diagram shows interaction among objects as a two-dimensional chart. The chart is
read
from top to bottom. The objects participating in the interaction are shown at the top of the chart
as
boxes attached to a vertical dashed line. Inside the box, the name of the object is written with a
colon separating it from the name of the class and both the name of the object and the class are
underlined.
 3.4Activity Diagrams
Visually presents a series of actions or flow of control in a system similar to a flowchart or a data
flow diagram. Activity diagrams are often used in business process modeling. They can also
describe the steps in a use case diagram. Activities modeled can be sequential and concurrent.