ADDIS ABABA INSTITUTE OF

TECHNOLOGY
CENTER OF INFORMATION TECHNOLOGY AND
SCIENTIFIC COMPUTING
DEPARTMENT OF SOFTWARE ENGINEERING OR IT [choose one]

<Project Name>

Team Members
Name – Id
Name – Id
Name – Id

Advisor: Name of Advisor

February 2017
 Addis Ababa Institute of Technology
Information Technology and Scientific Computing

<Title of Project>

This Project documentation submitted in partial fulfillment of the requirements for the Degree of
Bachelor of Science in Software Engineering or IT[choose one].

Project Advised by:

Advisor Name

Name and signature of Members of the examining board:

Name Title Signature Date

1. __________________ Advisor _____________ _____________

2. __________________ Chairperson _____________ _____________

3. __________________ Examiner _____________ _____________

4. __________________ Examiner _____________ _____________

5. __________________ Examiner _____________ _____________

February 2017

i
 Declaration of Originality

We declare that this project is our original work and has not been presented for a degree in any
other university.

Name Signature Date

1. Name of Student 1 __________________ __________________

2. Name of Student 2 __________________ __________________

3. Name of Student 3 __________________ __________________

4. Name of Student 4 __________________ __________________

This project documentation has been submitted for examination with my approval as university
advisor:

Advisoir Name _________________________

February 2017

ii
 ACKNOWLEDGEMENT

//write the acknowledgment

iii
ABSTRACT

iv
 Table of Contents
List of Figures.................................................................................................................................ix

List of Tables...................................................................................................................................x

ACRONYMS..................................................................................................................................xi

Chapter 1: INTRODUCTION.........................................................................................................1

1.1 Background............................................................................................................................1

1.2 The Existing System..............................................................................................................1

1.3 Statement of the Problem.......................................................................................................1

1.4 Objective of the Project.........................................................................................................2

1.4.1 General Objective......................................................................................................2

1.4.2 Specific Objective......................................................................................................2

1.5 Proposed System....................................................................................................................2

1.6 Feasibility Study....................................................................................................................2

1.6.1 Economic Feasibility......................................................................................................2

1.6.2 Technical Feasibility.......................................................................................................2

1.6.3 Schedule Feasibility........................................................................................................2

1.7 Scope......................................................................................................................................3

1.8 Methodology..........................................................................................................................3

1.9 Project Management plan......................................................................................................4

1.9.1. Time Management plan.................................................................................................4

1.9 .2 Quality Management Plan.............................................................................................4

1.9 .3. Communication Management Plan...............................................................................5

Chapter 2: LITRATURE REVIEW.................................................................................................6

2.1 Introduction............................................................................................................................6

2.2 Reviewed System...................................................................................................................6

v
 2.3 Summary of the review..........................................................................................................6

Chapter 3: Requirement Analysis....................................................................................................7

3.1 Introduction............................................................................................................................7

3.2 General Description...............................................................................................................7

3.3 Product Perspective...............................................................................................................7

3.4 Product Functions..................................................................................................................7

3.5 User Characteristics...............................................................................................................7

3.6 General Constraints...............................................................................................................7

3.7 Assumptions and Dependencies............................................................................................8

3.8 External Interface Requirements...........................................................................................8

3.8.1 User Interfaces................................................................................................................8

3.8.2 Hardware Interfaces........................................................................................................8

3.8.3 Software Interfaces.........................................................................................................9

3.8.4 Communications Interfaces..........................................................................................10

3.9 Functional Requirements.....................................................................................................10

3.9.1 <Functional Requirement or Feature #1>.....................................................................10

3.9.2 <Functional Requirement or Feature #2>.....................................................................10

3.10 Use Cases...........................................................................................................................10

3.10.1 Use Case #1................................................................................................................10

3.10.2 Use Case #2................................................................................................................10

3.11 Non-Functional Requirements...........................................................................................10

3.11.1 Performance................................................................................................................11

3.11.2 Reliability...................................................................................................................11

3.11.3 Availability.................................................................................................................11

3.11.4 Security.......................................................................................................................11

vi
 3.11.5 Maintainability............................................................................................................11

3.11.6 Portability...................................................................................................................11

3.12 Inverse Requirements........................................................................................................11

3.13 Design Constraints.............................................................................................................11

3.14 Logical Database Requirements........................................................................................11

3.15 Other Requirements...........................................................................................................11

3.16 Change Management Process............................................................................................11

Chapter 4: SYSTEM DESIGN......................................................................................................12

4.1 General Overview................................................................................................................12

4.2 Development Methods & Contingencies.............................................................................12

4.3 System Architecture.............................................................................................................12

4.3.1 Subsystem decomposition............................................................................................12

4.3.2 Hardware/software mapping.........................................................................................12

4.4 Object Model.......................................................................................................................13

4.4.1 Class Diagram...............................................................................................................13

4.4.2 Sequence Diagram........................................................................................................14

4.4.2 State chart Diagram (optional element)........................................................................14

4.5 Detailed Design...................................................................................................................15

Chapter 5: Testing..........................................................................................................................17

5.1 Introduction..........................................................................................................................17

5.2 Features to be tested/not to be tested...................................................................................17

5.2.1 Features to be tested......................................................................................................17

5.2.2 Features not to be tested...............................................................................................17

5.3. Pass/Fail criteria..................................................................................................................17

5.4. Approach/Strategy..............................................................................................................17

vii
 5.5 Test cases with specifications..............................................................................................18

Chapter 6: User Manual.................................................................................................................19

6.1 scope....................................................................................................................................19

6.2 Installation and configuration..............................................................................................19

6.3 How to Operate the system..................................................................................................19

Chapter 7: CONCLUSION AND RECOMMENDATION...........................................................20

7.1 Conclusion...........................................................................................................................20

7.2 Recommendation.................................................................................................................20

BIBLIOGRAPHY..........................................................................................................................21

APPENDIX....................................................................................................................................22

viii
 List of Figures

//automatically generated list of figures

ix
 List of Tables

//automatically generated list of figures

x
 ACRONYMS

This subsection should provide the definitions of all terms, acronyms, and abbreviations required
to properly interpret the document

xi
 Chapter 1: INTRODUCTION

1.1 Background
This section Provide essential information like
 What the motivation for this project is (e.g. to fill a gap in the product portfolio)
 Who the customer is
 What the project will deliver. Is it a new product or an extension of an existing one?
 What it will cost
 How long it will take
 Which organizations are involved
 Which other projects depend on the project result
 Which other projects contribute with their results

1.2 The Existing System

[Identify what type of methods and techniques are currently used to do the job which leads
to view the gap and creating a problem the you are initiated to solve]
1.3 Statement of the Problem
Identify the needs or problems to be addressed. Include the target population and any
statistical information that you may have. Ideas for information to include here are:

• Length of time needs/problems have existed

• Whether problem has ever been addressed before, and what the outcome was
• Impact of problem to target population
• Impact of problem to surrounding populations

Element Description
The problem of ... Describe the problem
Affects ... Identify stakeholders affected by the problem
And results in ... Describe the impact of this problem on stakeholders and business activity
Benefits of a solution ... Indicate the proposed solution and list a few key benefits

1
1.4 Objective of the Project
[Identify changes desired to be seen upon completion of effort.]
1.4.1 General Objective

1.4.2 Specific Objective

1.5 Proposed System

[Identify and describe what the solution of the problem you are targeting briefly]
1.6 Feasibility Study
1.6.1 Economic Feasibility
1.6.1.1 Developmental cost
1.6.1.2 Operational Cost
1.6.2 Technical Feasibility
1.6.3 Schedule Feasibility

2
1.7 Scope
Clarify what the project will (and will not) deliver, in order to avoid future shifts in the level of ambition.

1.8 Methodology
Describe what you will do during the upcoming months that you spend on the project.
This requires real thinking ahead. This section needs to answer the big question: “HOW
DO YOU PLAN TO SOLVE THE PROBLEM?”. In the previous semesters students
were saying they will use “waterflow” or X methodology. Yes! Waterflow is a
methodology and it defines the next steps as requirements, design, implementation and
testing. But name-dropping a generic methodology doesn’t mean it is going to work for
you. You need to tell us the specifics of a methodology.
We need you to really think about how you plan to define the requirements. Are you
going to interview people? If so, who and when? How many people do you need to
interview or distribute questioners for until you clearly have the picture of the problem
that you are working with. You need to convince us that in the coming X weeks you are
going to have a clearly defined requirement by following this clearly defined
methodology.
The same goes for design. Answer questions such as: When and how am I going to
define the project’s constraints? Does it need to be easy to use? Is performance what is
expected of me? It is maintainability that I worry about? Do I need to review and
compare some alternate design strategies? How do you plan to make sure that your
constraints (what ever they are) are reflected in your project? [MAIN POINT: Review
your software engineering’s design lectures and convince us that you are going to do
your project design well. Show us that you know what you are getting into. BUT DON’T
DO THE DESIGN JUST YET.]
The “Implementation methodology” also needs to be defined. What are the tools that you
plan to use to solve change your design to implementation? Do you plan to review
alternate implementations? Are you planning to use any libraries or frameworks? …
Convince your audience that you know how you plan to implement your project.
Testing is also important. How do you plan to test the product? Are you planning to use
actual customers to test if it really makes their life easier? How do you plan to assess

3
 success of the product? Do I need system testing, or user testing, or integration testing?
Why do I use them? How do I plan to do them? Reviewing your software engineering
lectures course notes may help.

1.9 Project Management plan

1.9.1. Time Management plan
Describe the entire project schedule using gant chart and additional tabular description if
necessary

Figure 1

1.9 .2 Quality Management Plan

[Describe the potential risks related to the software quality. Provide the project
management plan to enable quality. Describe the salient, planned testing
considerations.]
[OPTIONAL CONTENT: Include any analysis plan for usability and acceptance
testing.]

1.9 .3. Communication Management Plan

State the principles for reporting and distributing information within the project for the different
groups of internal and external stakeholders. Include, for example, how often the
reporting will take place, the type of reports or information, the type of media in which it
is presented, and the type of meetings that will take place.

4
a) Internal communication and reporting: ensure that all information is available to
those who need it.
– Plan project meetings, how often they take place, and who will participate
– Define how project information will made available to the internal stakeholders
(e.g. project library)
– Define how and how often sub-projects and sub-contractors report to the project
manager
– Define who participates milestone meetings
– Define how events will be communicated
b) External communication and reporting:
– Define what information will be provided to which stakeholders
– Define how and how often information will be provided to which
stakeholders often (e.g. project report)
– Plan regular meetings with external stakeholders (e.g. SteCo meetings)
Example:

Type of Method / Tool Frequency Information Participants /

Communication /Schedule Responsibles
Internal Communication:
Project Meetings Teleconference Weekly and Project status, problems, Project Mgr
on event risks, changed Project Team
requirements
Sharing of project Shared Project When All project documentation Project Mgr(s)
data Server available and reports Project Team
Members

Milestone Teleconference Before Project status (progess) Project Mgr

Meetings milestones Sub-project Mgr
Final Project Teleconference M6 Wrap-up Project Mgr
Meeting Experiences Project Team
External Communication and Reporting:
Project Report Excel sheet Monthly Project status Project Manager
- progress Sub-Project
- forecast Managers
- risks
SteCo Meetings Teleconference Monthly Project
Manager, SteCo

5
 Chapter 2: LITRATURE REVIEW

2.1 Introduction
2.2 Reviewed System
2.3 Summary of the review

[This is optional since write this content if only the group members have done it so far]

6
 Chapter 3: Requirement Analysis

3.1 Introduction
The introduction to the Software Requirement Specification
3.2 General Description
This section of the SRS should describe the general factors that affect 'the product and its
requirements. It should be made clear that this section does not state specific requirements; it
only makes those requirements easier to understand.

3.3 Product Perspective

This subsection of the SRS puts the product into perspective with other related products or

projects. (See the IEEE Guide to SRS for more details).

3.4 Product Functions

This subsection of the SRS should provide a summary of the functions that the software will
perform.
3.5 User Characteristics
This subsection of the SRS should describe those general characteristics of the eventual users of
the product that will affect the specific requirements. (See the IEEE Guide to SRS for more
details).
3.6 General Constraints
This subsection of the SRS should provide a general description of any other items that will

limit the developer’s options for designing the system. (See the IEEE Guide to SRS for a partial
list of possible general constraints).

Provide a general description of any other items that will limit the developer's options. These
can include:

(1) Regulatory policies

(2) Hardware limitations (for example, signal timing requirements)
(3) Interface to other applications
(4) Parallel operation
(5) Audit functions
(6) Control functions
(7) Higher-order language requirements
(8) Signal handshake protocols (for example, XON-XOFF, ACK-NACK)
(9) Reliability requirements

7
 (10) Criticality of the application
(11) Safety and security considerations

This section captures non-functional requirements in the customer’s language. A more formal
presentation of these will occur in section 3.

3.7 Assumptions and Dependencies

This subsection of the SRS should list each of the factors that affect the requirements stated in
the SRS. These factors are not design constraints on the software but are, rather, any changes to
them that can affect the requirements in the SRS. For example, an assumption might be that a
specific operating system will be available on the hardware designated for the software product.
If, in fact, the operating system is not available, the SRS would then have to change accordingly.
3.8 External Interface Requirements
3.8.1 User Interfaces
Specify:

(1) The logical characteristics of each interface between the software product and its
users.
(2) All the aspects of optimizing the interface with the person who must use the system

This is a description of how the system will interact with its users. Is there a GUI, a command
line or some other type of interface? Are there special interface requirements? If you are
designing for the general student population for instance, what is the impact of ADA (American
with Disabilities Act) on your interface?

3.8.2 Hardware Interfaces

Specify the logical characteristics of each interface between the software product and the
hardware components of the system. This includes configuration characteristics. It also covers
such matters as what devices are to be supported, how they are to be supported and protocols.
This is not a description of hardware requirements in the sense that “This program must run on
a Mac with 64M of RAM”. This section is for detailing the actual hardware devices your
application will interact with and control. For instance, if you are controlling X10 type home
devices, what is the interface to those devices? Designers should be able to look at this and
know what hardware they need to worry about in the design. Many business type applications

8
will have no hardware interfaces. If none, just state “The system has no hardware interface
requirements” If you just delete sections that are not applicable, then readers do not know if: a.
this does not apply or b. you forgot to include the section in the first place.

3.8.3 Software Interfaces

Specify the use of other required software products and interfaces with other application
systems. For each required software product, include:

(1) Name
(2) Mnemonic
(3) Specification number
(4) Version number
(5) Source

For each interface, provide:

(1) Discussion of the purpose of the interfacing software as related to this software
product
(2) Definition of the interface in terms of message content and format

Here we document the APIs, versions of software that we do not have to write, but that our
system has to use. For instance if your customer uses SQL Server 7 and you are required to use
that, then you need to specify i.e.

2.1.4.1 Microsoft SQL Server 7. The system must use SQL Server as its database component.
Communication with the DB is through ODBC connections. The system must provide SQL data
table definintions to be provided to the company DBA for setup.

A key point to remember is that you do NOT want to specify software here that you think would
be good to use. This is only for customer-specified systems that you have to interact with.
Choosing SQL Server 7 as a DB without a customer requirement is a Design choice, not a
requirement. This is a subtle but important point to writing good requirements and not over-
constraining the design.

9
 3.8.4 Communications Interfaces
Specify the various interfaces to communications such as local network protocols, etc. These are
protocols you will need to directly interact with. If you happen to use web services transparently
to your application then do not list it here. If you are using a custom protocol to communicate
between systems, then document that protocol here so designers know what to design. If it is a
standard protocol, you can reference an existing document or RFC.

3.9 Functional Requirements

This section describes specific features of the software project. If desired, some requirements
may be specified in the use-case format and listed in the Use Cases Section.
3.9.1 <Functional Requirement or Feature #1>
Introduction

Inputs

Processing

Outputs

Error Handling

3.9.2 <Functional Requirement or Feature #2>

…

3.10 Use Cases

3.10.1 Use Case #1
3.10.2 Use Case #2
…

3.11 Non-Functional Requirements

Non-functional requirements may exist for the following attributes. Often these requirements
must be achieved at a system-wide level rather than at a unit level. State the requirements in the
following sections in measurable terms (e.g., 95% of transaction shall be processed in less than
a second, system downtime may not exceed 1 minute per day, > 30 day MTBF value, etc).

10
3.11.1 Performance
3.11.2 Reliability
3.11.3 Availability
3.11.4 Security
3.11.5 Maintainability
3.11.6 Portability
3.12 Inverse Requirements
State any *useful* inverse requirements.
what the application does not do
3.13 Design Constraints
Specify design constrains imposed by other standards, company policies, hardware limitation,
etc. that will impact this software project.
3.14 Logical Database Requirements
Will a database be used? If so, what logical requirements exist for data formats, storage
capabilities, data retention, data integrity, etc.
3.15 Other Requirements
Catchall section for any additional requirements:
Training-related Requirements

If there is any specific training that should be necessary for a user to begin using this application.

Packaging Requirements

How the system is packed (folder with code or in exe format or……) if there is any file for the purpose of help
(README file) and Any If the is makefile for recompilation

Legal Requirements

Copyright laws and license agreements

3.16 Change Management Process

Identify and describe the process that will be used to update the SRS, as needed, when project
scope or requirements change. Who can submit changes and by what means, and how will these
changes be approved.

11
 Chapter 4: SYSTEM DESIGN

4.1 General Overview

Instructions: Briefly introduce the system context and the basic design approach or organization.
Provide a brief overview of the system and software architectures and the design goals. Include
the high-level context diagram(s) for the system and subsystems previously provided in the
High-Level Technical Design Concept/Alternatives and/or Requirements Document, updated as
necessary to reflect any changes that have been made based on more current information or
understanding. If the high-level context diagram has been updated, identify the changes that were
made and why.

4.2 Development Methods & Contingencies

Instructions: Briefly describe the method or approach used for the system and software design
(e.g., structured, object-oriented, prototyping, J2EE, UML, XML, etc.). If one or more formal/
published methods were adopted or adapted, then include a reference to a more detailed
description of these methods. If several methods were seriously considered, then each such
method should be mentioned, along with a brief explanation of why all or part of it was used or
not used. Describe any contingencies that might arise in the design of the system and software
that may change the development direction. Possibilities include lack of interface agreements
with outside agencies or unstable architectures at the time the SDD is prepared. Address any
possible workarounds or alternative plans.

4.3 System Architecture

4.3.1 Subsystem decomposition
UML Component Diagram (show at least three level of the system decomposition)

4.3.2 Hardware/software mapping

UML Deployment diagram

12
4.4 Object Model
4.4.1 Class Diagram
Provide a Unified Modeling Language (UML) based type of static structure diagram that
describes the structure of a system by showing the system's classes, their attributes, operations
(or methods), and the relationships among the classes.

The following points should be remembered while drawing a class diagram:

 The name of the class diagram should be meaningful to describe the aspect of the
system.
 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be clearly identified.
 For each class minimum number of properties should be specified. Because unnecessary
properties will make the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram. Because at the end
of the drawing it should be understandable to the developer/coder.
 Finally, before making the final version, the diagram should be drawn on plain paper and
rework as many times as possible to make it correct.

Now the following diagram is an example of an Order System of an

application. So it describes a particular aspect of the entire application.

 First of all Order and Customer are identified as the two elements of the system
and they have a one to many relationship because a customer can have
multiple orders.
 We would keep Order class is an abstract class and it has two concrete classes
(inheritance relationship) SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as the Order class. In addition
they have additional functions like dispatch () and receive ().

So the following class diagram has been drawn considering all the points
mentioned above:

13
 4.4.2 Sequence Diagram
Show how processes operate with one another and in what order. Depict the objects and classes
involved in the scenario and the sequence of messages exchanged between the objects needed to
carry out the functionality of the scenario.
4.4.2 State chart Diagram (optional element)
UML State chart diagram (If you have an object that can be in many states only)

14
4.5 Detailed Design
Here show the identified class in detail for example: -Assume a system has a Mobile Client Class
then describe about the class in the following manner.

The classes represented here are the ones identified on your class diagram. But you must add the
methods and classes identified in sequence and state chart diagram.

Table: x Mobile Client class

Mobile Client
+Name:String
+ PhoneNumber:Integer
+Address:String
-Email:String
-ID:String
s+fillPersonal ()
+Beggar’sInfo ()
+SubmitInfo ()

Table: x Attributes description for Mobile Client class

Attribute Type Visibility Invariant

Name: String Public Name <> NULL and must contain first, middle and last name
and shouldn’t contain special characters and integers.
PhoneNumber Integer Public PhoneNumber <> NULL must be 10 digits and must start by
+251/09
Address String Public Address <>NULL and it must be between 12 to 20 characters

15
Email String Private Email <> NULL
 Must contain @
 Must contain. (dot)
 Position of @ >1
 Position of (dot)>position of @ + 2
 Position of (dot)+3<= total length of email address and
the total character of the Email is at least 5 characters
Table: 7 Operation description for Mobile Client class

Operation Visibility Return Argument Pre-Condition Post Condition

type
RegisterPersonalInfo Public void . The clients personal The clients
information personal
shouldn’t exist information
should exist
RegisterBeggar’sInfo Public void . The Beggar’s The Beggar’s
information information
shouldn’t exist should exist
SubmitInfo Public void - Both the client’s and Both the client’s
Beggar’s and Beggar’s
information information
shouldn’t exist should exist

16
 Chapter 5: Testing

5.1 Introduction

Introduction about the testing

5.2 Features to be tested/not to be tested
5.2.1 Features to be tested

//Describe the system features to be tested [from functional and non-functional requirement].

5.2.2 Features not to be tested

//function that need not to be tested and the reason why they don’t need to be tested
5.3. Pass/Fail criteria
//What are the success /fail criteria?
5.4. Approach/Strategy
//What are the approach/strategy for testing the system [ unit testing, integration testing and
system testing]?

17
5.5 Test cases with specifications
//A test case is a set of input data and expected results that exercises a component with the
purpose of causing failures and detecting faults. [look the following example]

Table 1: Test case specification for Login

Name: Login for web portal

Purpose: to verify that only authorized users gain access to the required page or access
Test Data= User Name(Invalid, Valid, Empty)
Password(Invalid, Valid, Empty)
Input Expected result Data Actual output Pass/fail
Empty user name “Invalid account Any valid password and “Invalid account Fail
Valid password information!” Empty user name information!”
Invalid username “Invalid account Any valid password and “Invalid account Fail
valid password information!” any Invalid username information!”
Invalid Username “Invalid account Any Invalid Username “Invalid account Fail
empty password information!” and empty password information!”

Valid username “Invalid account Any valid username and “Invalid account Fail
Invalid password information!” Any invalid Password information!”
Empty Username “Invalid account Empty Username and “Invalid account Fail
Empty Password information!” Empty Password information!”

Valid Username The user is redirected Any Valid Username and The user is redirected Pass
Valid Password to home valid Password to home
page(admin/manager) page(admin/manager)

18
 Chapter 6: User Manual

6.1 scope
//what does the manual cover [list them] example:

The manual covers the following:

 How to How to start the system

 How to create, update and delete user account
 ……etc.

6.2 Installation and configuration

//list the pre-requirement to install the system

//show the installation procedure [supported with screenshots]

//show the configuration procedure if any [supported with screenshots]

6.3 How to Operate the system

// only try to show the most important part of the system not all

A. How to start the system

//describe the procedure with screenshot

Example:

1. First do this … screenshot followed

2 then do this … screenshot followed

B. How to create user account

//describe the procedure with screenshot

Example:

1. First do this … screenshot followed

2 then do this … screenshot followed

19
 Chapter 7: CONCLUSION AND RECOMMENDATION

7.1 Conclusion
7.2 Recommendation

20
 BIBLIOGRAPHY

[1] http://www.mio.com/technology-history-of-gps.htm , access date: 08/11/2015

[2]

Sommerville, I., 2011. Software Engineering. 9th ed. s.l.:Pearson

Education Inc, as Addison-Wesley.

21
APPENDIX

22