Wollo University

Kombolcha Institute of Technology

College of Informatics
Department of Information Technology

Final Year Project Documentation Guideline

___________________________________________________________________

Compiled by:

 Abdulhamid Yesuf
 Mulatu Dagnachew
 Tadele Asitatikie

November, 2012 E.C.

Front/Title Page

1
 The front (title) page must be as follows:

University LOGO

Wollo University

Kombolcha Institute of Technology

College of Informatics

Department of Information Technology

Title: - _____________________________________________________

Prepared By: - 1. _______________________________

2. ___________________________

3. _______________________________

4. _______________________________

5.___________________________________

Advisor’s name: - _____________________________________

Kombolcha, Wollo, Ethiopia

{ Month, year}

2
Declaration

This is to declare that this project titled {project title goes here} is done by 4 th year Information
Technology students for partial fulfillment of BSc in Information technology. It is submitted to
Department of Information Technology.

Approval sheet

Examining committee members Signature Date

1. Examiner 1
2. Examiner 2
3. Examiner 3
4. Examiner 4

Advisor’s name Signature Date

Group members Signature Date

1.
2.
3.
4.
5.

3
 Formatting style
Paper size and margins

- Use A-4 paper

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.
- Font size of title should be 16 and Bold.
- The font size of sub tittles is 14 and bold.
- The font size of the sub title of the sub title is 12 and bold.
- The font type for your entire document should be Times New Roman.
- Use the same /consistent formatting style for all contents throughout your document.

4
 Contents
University LOGO........................................................................................................................................2
Wollo University.........................................................................................................................................2
Approval sheet............................................................................................................................................3
Executive Summary.....................................................................................................................................6
Chapter One: Introduction...........................................................................................................................8
1.1 Background of the study...............................................................................................................8
1.2 Statement of the Problem..............................................................................................................8
1.3 Objective.........................................................................................................................................9
1.4 Related projects.............................................................................................................................9
1.5 Methodology.................................................................................................................................10
1.6 Feasibility.....................................................................................................................................11
1.7 Risks and Assumptions................................................................................................................14
1.8 Scope and limitation of the project.............................................................................................14
1.9 Significance of the project...........................................................................................................15
1.10 Time-line of the Project...............................................................................................................15
1.11 Budget of the Project...................................................................................................................15
1.12 Organization of the project.........................................................................................................15
Chapter Two: Analysis..............................................................................................................................16
2.1 Introduction.................................................................................................................................16
2.2 Existing System............................................................................................................................16
2.2.1 Description of Existing System...............................................................................................16
2.2.2 Requirement gathering............................................................................................................16
2.2.3 Supplementary Requirements................................................................................................17
2.3 Proposed System..........................................................................................................................18
2.3.1 Software requirement specification (SRS).............................................................................18
2.3.2 Existing System Modeling.......................................................................................................19
Essential Use Case modeling...................................................................................................................19
2.3.3 System Modeling......................................................................................................................20
2.3.3.1 System Use case documentation..............................................................................................20
2.3.4 Key abstraction with CRC analysis........................................................................................21
2.3.5 Sequence diagram....................................................................................................................22
2.3.6 Activity diagram......................................................................................................................23

5
2.3.7 Conceptual modeling: Class diagram.....................................................................................24
2.3.8 User Interface Prototyping......................................................................................................24
2.3.9 Identifying change cases..........................................................................................................25
Chapter Three: Design...............................................................................................................................26
3.1 Purpose and goals of design........................................................................................................26
3.2 Class Modeling diagram..............................................................................................................26
3.3 Current software architecture....................................................................................................27
3.4 Proposed software architecture..................................................................................................27
3.4.1 Subsystem Decomposition.......................................................................................................27
3.4.2 Component diagram................................................................................................................28
3.4.3 Deployment diagram...............................................................................................................28
3.4.4 Persistence Modeling for object oriented database...............................................................29
3.4.5 Access control and security.....................................................................................................30
3.4.6 Boundary conditions and Exception Handling......................................................................31
3.4.6.1 Boundary Conditions...............................................................................................................31
3.4.6.2 Exception Handling.................................................................................................................32
3.5 User-Interface Design..................................................................................................................33
Chapter Four: Implementation and Testing...............................................................................................34
4.1 Implementation............................................................................................................................34
4.2 Choose Your Test Approach.......................................................................................................34
4.3 Functional Test Specifications....................................................................................................34
Chapter Five: Conclusion and Recommendation.......................................................................................37
5.1 Conclusion...........................................................................................................................................37
5.2 Recommendation.................................................................................................................................37
Reference...................................................................................................................................................38
Annex 1.....................................................................................................................................................38
Annex 2.....................................................................................................................................................38
Annex 3.....................................................................................................................................................38
Annex 4.....................................................................................................................................................38

6
 Executive Summary
It will help students to provide essential information about the project to the decision makers in
both the granting organization and the beneficiary areas.

7
 Chapter One: Introduction
1.1 Background of the study
 Write about the organization for which you are developing a system. It should
summarize the background information to the problem to be studied and the context
within which it will be studied.
 Describe the project area you are working on. For example, if you are working on a title
called “Online Banking for ABC Company”, then you write about Online banking in
general.
 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.
1.2 Statement of the Problem
In the statement of the problem, you identify the problems that exist in the current system the
organization uses and clearly describe the problems as much as possible as anyone can
understand.

At this line you list the main problem that shoes why you want to develop the system.

If other researchers already develop the system before this time, you can identify the problem of
the developed system and identify what additional features can be adding to expand the system
to advance.

If the current system is manual, you should discuss the problem of the manual system clearly,
and what types of problems the company faced because of the manual system operation.

Finally, be sure that your problem statement can fully address an existing knowledge gap
between what is existed and what should the system be.

8
1.3 Objective
What is/are the key objective(s) of the research? What is it that you plan to accomplish?

 General objective

General objective is the term that tells what you want to achieve at the end of the project. The
general objective of the project is almost the same as your project tittle. The only difference is
that when you write objective, you should use the terms like: - to….., in order to….., the general
objective of the project is to……….., the general objective of the study is to……

 Specific objective

Specific objectives are tasks that you work on in order to achieve the general objective of the
project.

Here each steps of the project that you will pass through should be clearly identified. Nothing
you will do which is not specified in the specific objective.

Note that: - most of the students cannot identify the difference between specific objective and
significance of the project. Significance outlines what benefits the system have for the users, the
company, customers and any other stakeholders. Significance is all about what type of functions
the system will do. Whereas specific objectives are simply the lists of tasks that you do to
achieve the general objective /to develop the system/.

1.4 Related projects

The researcher should examine all available literatures that are done before this time to get him
acquainted with the selected problem.Review as much Literature as possible to avoid duplication
and to increase your understanding on identifying the research gap. If no literature is reviewed,
no one is sure that whether the selected project is done or not. Without related literature, you
cannot understand the knowledge gap.

Extensive review is required to know: -

 What others have done in the area?

 How the problem is solved (methodology)?
 What were the research variables?
 How were the variables measured?

9
  What were the constraints?
 What could possibly be modified?

After the literature review, the students can easily understand what types of features will be
modified and it is easy to make the update. Unless if there is no update it is better to change the
project area.

1.5 Methodology

A methodology is a formalized approach to implementing the system development life cycle

(i.e., it is a list of steps and deliverables).

Here you are expected to describe the main methods and techniques to be used and specify the
system methodology use in the project. Show how each specific objective can be employed with
enough detail to enable an independent and informed assessment. Under this tittle the following
sub-topics should be included.

 Requirement gathering methods

In order to develop one system, you need have enough information about the problem occurred
in the company or in any of the area that you have selected. If there is no any problem in the area
you cannot do anything. So before doing anything you should be sure that the problem is really
existed in the company or in the area. To understand the real problem, you should contact the
manager of the company, the expert or any stakeholder that have enough information about the
problem. To conduct this requirement gathering you may require to prepare questions in the form
of interview, questionnaire, or you may conduct observation, document analysis etc. the ways
that you used to gather any data from the stakeholders are called Requirement gathering
methods. So in your project you are expected to select one or more data requirement gathering
methods. All methods do not have the same usage, and are different on the types of the data that
you collect, and the selection also depends on the type of the stakeholder from whom you elicit
the information. So you should reason out why you select the appropriate method during
requirement gathering method selection.

 System methodology

10
Describe the way of designing approach like OOSAD or SSAD, here also you should specify
your reason why you have select the appropriate methodology. But most of the time the best one
is OOSAD b/c it helps reusability, extensibility and inheritance of code and others.

 Tools used for implementation

Hardware tools 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.

Specify the database type you use, the programming language you use, the UML modeling tools,
etc. Successful applications must be carefully planned and developed before any meaningful
coding takes place.

1.6 Feasibility
Feasibility analysis identifies the important risks associated with the project that must be
managed if the project in the system development process. Feasibility is 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.
 Economic feasibility:

Economic feasibility is determined by identifying costs and benefits associated with the system,
assigning values to them, calculating future cash flows, and measuring the financial worthiness
of the project. As a result of this analysis, the financial opportunities and risks of the project can
be understood. Keep in mind that organizations have limited capital resources and multiple
projects will be competing for funding. The more expensive the project, the more rigorous and
detailed the analysis should be. Economic feasibility answers the question“Is the solution or your
project is cost-effective”?

Economic feasibility involves an initial investment that produces a stream of benefits over time,
along with some ongoing support costs. Therefore, the value of the project must be measured
over time. Cash flows, both inflows and outflows, are estimated over some future period.
Then, these cash flows are evaluated using several techniques to judge whether the projected
benefits justify incurring the costs.

11
To determine economic feasibility, you should construct cost-benefit analysis table that identify
all the financial benefits and costs associated with a project. Tangible vs. intangible benefits,
tangible vs. intangible costs and one-time vs. recurring costs.

The costs and benefits can be broken down into four categories:

o Development Costs,

Are those tangible expenses that are incurred during the creation of the system, such as salaries
for the project team, hardware and software expenses, consultant fees, training, and office
space and equipment?

o Operational Costs,

Are those tangible costs that are required to operate the system such as the salaries for operations
staff, software licensing fees, equipment upgrades, and communications charges.

o Tangible Benefits, and

Include revenue that the system enables the organization to collect, such as increased sales. In
addition, the system may enable the organization to avoid certain costs, leading to another type
of tangible benefit: cost savings.

For example, if the system produces error reduction, it is possible to estimate in terms of money.
a reduction in required inventory levels due to the new system produces lower inventory costs. In
these examples, the reduction in costs is a tangible benefit of the new system.

o Intangible Benefits

Intangible costs and benefits are more difficult to incorporate into the economic feasibility
analysis because they are based on intuition and belief rather than on “hard numbers.”
Nonetheless, they should be listed in the spreadsheet along with the tangible items. Refer the
following table for further information.

You can see the following example for your cost-benefit analysis.

After you have identified all costs and any expected benefits, you should make a comparison
between the cost and the benefits. If the total benefit is greater than the total cost, then you can
conclude that your system is economically feasible, unless it is not.

12
  Technical feasibility

Technical feasibility can be checked based on the following points.

1. Familiarity with application: Less familiarity generates more risk.: When analysts are
unfamiliar with the business application area, they have a greater chance of
misunderstanding the users or missing opportunities for improvement. So you should
check your familiarity on the project that have proposed to develop.

2. Familiarity with technology: Less familiarity generates more risk. When a system will
use technology that has not been used before within the organization, there is a greater
chance that problems and delays will occur because of the need to learn how to use the
technology. Risk increases dramatically when the technology itself is new. So based on
the types of technology that is used for the system development should be familiar for the
developers and the users. Here the if the users are unfamiliar with the technologies, you
will have training for them, so familiarity on the users’ side does not have much negative
implication on the technical feasibility.

3. Compatibility: Finally, project teams need to consider the compatibility of the new
system with the technology that already existed in the organization. New technology and
applications need to be able to integrate with the existing environment for many
reasons:-

 They may rely on data from existing systems,

 They may produce data that feed other applications, and
 They may have to use the company’s existing communications infrastructure.

4. Project size: Large projects have more risk. Project size determines the time it takes to
complete, the number of distinct features of the system. Larger projects present more risk,
because they are more complicated to manage and because there is a greater chance that
some important system requirements will be overlooked or misunderstood. The extent to
which the project is highly integrated with other systems (which is typical of large
systems) can cause problems, because complexity is increased when many systems must
work together. So you should check the size of your project based on the capacity of the
system developers.

13
  Operational feasibility

Check howwell the system ultimately will be accepted by its users and incorporated into the
ongoing operations of the organization. Operational feasibility checks whether the proposed
system is in line with the problems that exist in the company. If the solution able to solve the
problem, the project can be operationally feasible. In essence, an organizational feasibility
analysis attempts to answer the question “If we build it, will they come?”. Operational
feasibility should be also in-line with the objective of the system that you set before.

 Schedule feasibility

Can the project be accomplished in a reasonable period? Project management critical path
scheduling can help answer this concern.

 Political Feasibility
 Will the project have user and management support?
 Will there be resistance?
1.7 Risks and Assumptions
No Risk Impact Probability Mitigation
1
2

1.8 Scope and limitation of the project

Scope shows about how much of the organization is affected by the system. The functionalities
are covered by your system. Show to what extent your proposed system solves the problem of
the organization. Generally, the services, the deliverability you have to accomplish in the given
time.Scope should be stated based on two perspectives.
• In-scope
In-scope means the functionalities that are covered by your system. Therefore, you should
indicate any problem that can be solved by your system.
• Out-scope
The problem of one company /any system/ cannot fully addressed by one system. Because since
one system can have many other sub-systems, it is not possible to cover everything within a

14
single proposed system. So using out-scope you should specify lists of functionalities that you do
not include in your system because of different factors.
• Limitation of the project
Limitation of the project is about factors that hinder the researchers /the developers/ not to
proceed further to develop an efficient system.
Note that some students cannot clearly identify the difference between limitation and out-scope
of the project. They consider the two terms simultaneously. The difference is out-scope are part
of the system which can be include in the system but excluded from the system because of
different factors. If you can concentrate and work further, it is possible to include out-scopes as
the in-scope of the system. Whereas limitations are external factors that cannot be solved by the
project teams if you can take any measurements, these are out of your capacity. So, you should
clearly set terms independently.
1.9 Significance of the project
Specify the significance of your project. Significance discuss about what are the effects of the
project on the company or other company’s in general. What is its contribution to the project
area? Outline the probable application of results of your system and who will benefit from your
results and how.
1.10 Time-line of the Project
Show the project’s schedule that is divided by the project tasks. It is recommended to depict the
time-line of the project using Ghant chart.

1.11 Budget of the Project

This is the financial plan for development and implementation of the project. It should be clear,
realistic and reasonable (affordable).

1.12 Organization of the project

This project documentation is organized into five chapters. The first chapter….. . The second
chapter….. The third chapter covers about …. The fourth chapter deals the data analysis and
finding of the results. The fifth chapter encompasses the conclusion and recommendation for
future studies.

15
 Chapter Two: Analysis
2.1 Introduction
An important part in software development is to explore requirements for your system. Usage
modeling explores how people work 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

2.2 Existing System

2.2.1 Description of Existing 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. The description should be made based on the information that you elicit from the
organization. The description should show any processes and any relate problems that takes
place in the company as it is without any opinion from you. So avoid doing any description
without contacting the stakeholders.
The basic process of analysis involves three steps:

 Understand the existing situation (the as-is system).

 Identify improvements.

 Define requirements for the new system (the to-be system).

Note that the as-is system is not emphasized in the following condition: -

1. No current system exists,

2. If the existing system and processes are irrelevant to the future system
3. If the project team is using a RAD or agile development methodology.
2.2.2 Requirement gathering
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

16
 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.
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.
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
2.2.3 Supplementary Requirements
1. 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.

2. 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:
 The system will work on our existing technical infrastructure—no new technologies
will be introduced.

 The system shall be available 99.99 percent of the time for any 24-hour period.

17
2.3 Proposed System
2.3.1 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.

Non-Functional requirements

 Define the Non-functional Requirements of the system like security, performance,

reliability, etc.
 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

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.

Let us see library system as an example: -after interviewing the group’s members and officers,
you have developed an SRS document that includes the following functional requirements:
 Only members of the user group can borrow items.
 Books can be borrowed for four weeks.
 Movies and games can be borrowed for one week.
 Items can be renewed if no one is waiting to borrow them.
 Members can borrow up to a maximum of four items at the same time.
 A reminder is e-mailed to members when an item becomes overdue.

18
  A fine is charged for overdue items.
 Members with outstanding overdue items or fines cannot borrow new items.
 A secretary is in charge of maintaining item inventory and purchasing items to add to the
inventory.
 A librarian has been appointed to track lending and send overdue notices.
 The librarian is also responsible for collecting fines and updating fine information; after
listing all SRS the next step is to analyze the SRS to identify the actors and use cases.
2.3.2 Existing System Modeling

Essential Use Case modeling

It helps you to show the general overview of the existing system. It helps you to identify the
functions of the existing system and anything or anyone that interacts with the system.A use case
describes something of value to an actor (often a person, organization, system).it describes the
fundamental business task without bringing technological issues into account.

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

19
 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.

2.3.3 System Modeling

System Use case diagram

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.

2.3.3.1 System Use case documentation

This is a step-by-step description of the actions performed by each use case. It should contain
preconditions, post conditions, main course of action, and alternate course of action as it is
shown in the following table:

20
Section Purpose
Name The name of the use case. The name should implicitly express the user's
intent or purpose of the use case.
Identifier A unique identifier used by other artifacts to reference this use case.
Description Several sentences summarizing the use case.
Goal The goal of this use case, i.e., the thing of measurable value that will be
realized at its completion. If you cannot identify the goal you probably
do not have a use case.
Preconditions A list of the conditions, if any, that must be met before a use case may
be invoked.
Post conditions A list of the conditions, if any, that will be true once the use case
finishes successfully.
Basic course of The main path of logic an actor follows through a use case. Often
action referred to as the "happy path," the "main success scenario," or the
"main path" because it describes how the use case works when
everything works as it normally should.
Alternate courses The infrequently used path(s) of logic in a use case, paths that are the
of action result of an alternate way to work, an exception, or an error condition.
Sometimes called an extension.

2.3.4 Key abstraction with CRC analysis

A collection of CRC cards that model all or part of a system. A CRC card is a standard index
card that has been divided into three sections, one indicating the name of the class the card
represents, one listing the responsibilities of the class, and the third listing the names of the other
classes that this one collaborates with to fulfill its responsibilities.

Identify the concepts and things that are important for the system and draw CRC card for them.
This helps to identify objects that the system deals with and how they collaborate/interact/ with
each other. This evolves into a class diagram of your system when you create a class diagram for
the new system.

Student

21
 Student number Seminar
Name
Address
Phone number
Enroll in a seminar
Drop a seminar
Request transcripts

2.3.5 Sequence diagram

Sequence diagram will have prepared for each use case to show how different objects interact
with each other to achieve the functionality of the use case. A sequence diagram models how the
classes of objects interact with each other over time as the system runs.

Key parts of a sequence diagrams

 participant: an object or entity that acts in the sequence diagram
o sequence diagram starts with an unattached "found message" arrow
 message: communication between participant objects
 the axes in a sequence diagram:
o horizontal: which object/participant is acting
o vertical: time (down -> forward in time)
The following g diagram shows a generic sequence diagram.

An example of sequence diagram: -

22
2.3.6 Activity diagram
Draw activity diagrams to show the operations/activities performed by use cases to achieve their
functionality. Activity diagrams draw for each use case.

An Aactivity diagram is essentially a flowchart, showing flow of control from activity to activity
it involves.
 Modelling the sequential (and possibly concurrent) steps in a computational process
 Modelling the flow of an object as it moves from state to state at different points in the
flow of control.

23
2.3.7 Conceptual modeling: Class diagram
Class diagram will be the building block the system you will develop. Class diagrams should
show the objects the system is comprised of and how they are interrelated.
Class models contain a wealth of information; it can be used for both the analysis and design of
systems. To create and evolve a class model, you need to model these items:
 Classes;
 Responsibilities;
 Associations;
 Dependencies;
 Inheritance relationships;
 Composition associations; and
 Association classes.

2.3.8 User Interface Prototyping

Create a user interface prototype and include in the analysis document. This may help to gather
more requirements from users or show how the system works. You can create the prototype
using UI prototyping tools. If you build an ineffective user-interface (UI) to your system, then it
really does not matter how good the rest of your system is: your users are going to hate what you
have built for them. Therefore, Effective developers understand this and participates user of the
system in developing UI. While developing UI you will be expected to perform the following
tasks:
Artifact Description
Essential UI A technology-independent prototype created using paper that can will used to
prototype identify UI requirements.
Screen/report A hand-drawn sketch depicting the layout of a major UI element such as a
sketch screen, HTML page, or report; typically used to explore the layout of the UI
element.
UI flow A diagram that depicts major UI elements and how users transition between
diagram them; used to explore the high-level usability of a system or to overview/
document the user interface of a system.

24
2.3.9 Identifying change cases
Change cases will used to describe potential modifications requirements to the system. You
describe the potential change to your existing requirements, indicate the likeliness of that change
occurring, and indicate the potential impact of that change.

25
 Chapter Three: Design
3.1 Purpose and goals of design

A well-organized approach to system design is essential when developing modern enterprise

level object-oriented programs. The design phase is one of the most important in the software
development cycle. You can trace many of the problems associated with failed software projects
to poor upfront design and inadequate communication between the system’s developers and the
system’s consumers. Design is the how or the solution phase. The OOA results willplace here
directly. Certain modifications willmade based on implementation-specific criteria.

Investing time in the design process will achieve the following:

• Create realistic project scopes and timelines for completion
• Provide a basis for determining the software testing requirements
• Reduce the cost and time required to implement the software solution

Explain the purpose and design goals of the system by using different criteria, like Performance,
Dependability, end user…etc.For example. You can state the design goal in the following way

Design Goals describe the qualities of the system that developers should optimize. Such goals
are derived from the non-functional requirements of the system that are laid in the analysis
document. The design of the project is aimed at improving the
 Performance…
 Dependability …………….
 Cost …………….
 Maintenance………..
3.2 Class Modeling diagram
During design, you should consider indicating these items:
1. Visibility (optional):it is the level of access in which external objects have access to a
method or not.

2. Name. Strategies for naming methods.

3. Parameters (optional). The names of parameters, and optionally their types and default
values (if any), should indicated for each method.

26
 4. Return value type (optional). The type of the return value, if any, should indicated.
5. Scope. Whether a method is a static method that works on the class or an instance
method that works on instances of the class should also indicated. Static methods are
underlined; instance methods are not
Let us see the following diagram:

3.3 Current software architecture

Try to illustrate the current software architecture of your system if any. For example, if there is
no system in the organization you can state as

The existing system of the x company is manual system and hence there is no
current software architecture that will be considered. As a result, we only
describe the software architecture of the newly proposed system.

3.4 Proposed software architecture

3.4.1 Subsystem Decomposition

Subsystem diagram shows the service it provides or it accepts from other subsystems, and the
coupling and the coherence between them. For example, in this On-line Book Center system, we
have the following subsystems, which extracted from the functional requirement that already
described in the previous document.
 Registration Subsystem
 Order Subsystem

27
  Payment subsystem
 Report Sub system

3.4.2 Component diagram

Systems maybe built from components in component-based architecture. Component diagram

shows how objects (classes) in your system will grouped together and form components. The
components interact with each other either in giving service to other components or requesting
service from other component. Component diagrams are particularly useful with larger teams.

3.4.3 Deployment diagram

Deployment diagram show how the system will have deployed on computers. In other words, it
shows which component of the software will have installed on which machine and how they
communicate with each other if they are on different machines. Deployment diagrams can also
be created to explore the architecture of embedded systems, showing how the hardware and
software components work together. You want to create a deployment diagram for applications
deployed to several machines.

It is used to show the relationship among run-time components and hardware nodes. It is
representing the allocation of components to different nodes and the dependencies among
components. The developed system has layers: presentation layer, business layer and the
database server. For example, the first layer, presentation layer, is used to clients that enable

28
them to communicate with the second layer that is the business layer. It is shown as a client
application, which is found under the client machine. The business layer contains a number of
functionality supported by the system. For example, the Registrar Server as shown in the
deployment diagram incorporates those components. The database is developed using Oracle
DBMS i.e. Oracle server. It stores the data persistently. The presentation layer communicates
with the business layer using TCP connection that makes it to invoke methods remote. JDBC is
used as a protocol for the communication of the business layer and the Oracle server.

3.4.4 Persistence Modeling for object oriented database

If you use object oriented databases for your system instead of relational databases, instead of
designing E-R diagram, design persistence models. Show the mappings and the relations of the
tables. Consider the following example:

Persistent data of the Online System of Universal Book Center would be stored in a Microsoft
SQL Server Database Management System. The purpose of persistence modeling is which
objects in the system design are required to be stored persistently. Clearly, in a database driven
application like this one, almost all system interactions have deal with persistent data.

Information related to customer,book,order, payment and account are persistent data, which
should be stored in the Database Management System. This allows the programs that operate on
these data to do consistently. Moreover, storing data in a database enables the system to perform
complex queries on a large data set.

29
  Mapping

In order to store information persistently we map objects into tables and the attributes into fields
to the specific table based on the objects found on the system. Therefore, we identified five
major tables that will be implemented on the selected DBMS. For this reason, the mapping of
objects to tables is displayed as follows

 Relationships among Tables

This part is to describe and show the necessary relationships among the tables, which are
selected to store the data persistently in the system. There are three types of relationships in this
system.
 One-to-One Relationships
 Many-to-Many Relationship
 One-to-Many relationship
3.4.5 Access control and security

30
In the systems, different actors have access to different functionality and data. Define the access
controls for your system. Various actors, for example, connect to the Online Book Center
system. These are the Customer, who are responsible to fill registration form, search, select and
order books and then pays for the ordered books. The management is responsible to get and
print detail reports. The system administrator has all access including creating and deleting
users.
 The Customer: - represents an authenticated user. It is used by Login subsystems to
remember keys such as the password and user name associated with the customer.
 The management: - represents an authenticated user. It uses Login subsystems to check
the password and user name and associate with the user. The management actor is also
responsible to generate and view the report.
For example, the following table depicts an access matrix that associates actors with operations
in some of the sub system.
Actors Class Operation

Book BookInfo()
Selected Book Checks()
Customer Order Submit()
Payment Pay()
Account CheckPass()
Account CheckPass()
CalctotalBooks()
Management Report CalctotalSales()
CalcRemainBooks()
The system uses User Name and Password mechanisms to authenticate eligible users in order to
get the required services from the system.

3.4.6 Boundary conditions and Exception Handling

3.4.6.1 Boundary Conditions

Here it will try to describe some of the objects that act as a boundary object and exception
handling mechanisms.

31
The System Administrator initiates the web server using the appropriate administrator account
that enables him/her to add, modify and/or remove data available on the system such as, the
customer data, account, book information, orders, payment and others. It also enables to take the
necessary backups from it for recovery and other essential purposes in case of system crash. Of
course, the server side is giving 24/7 service unless it gets some problem that makes it down.

Any customer initiates the system to get a connection with the web server using his/her web
browser available on the client side. As a result, the home page will be displayed as a boundary
object to provide different services and access the pages available there. Based on the
functionality the customer is interested, there are a number of boundary objects found there so as
to facilitate the connection between the customer, the management and the system administrator
tasks. In addition to the Home page, the following are some of the boundary objects found in this
specific system. Register Page, Book Page, Selected Book Page, Invoice page, Delivery page,
Login page and Report Page.

The System is a Client–Server architecture and allows a remote access. The following
requirements are mandatory on both Client and Server side. For example:
Client slide
 Internet connection should be available on the client side
 Web browser is demanding to connect with the web server of the system
 The customer should be legitimate and having an account provided by the system
 It should give the URL (Uniform Resource Locator) address of the web site.
 The customer communicates the different hyperlinks/pages using the homepage.
 The Customer can get different service from viewing the available books up to
ordering and making payment.
Server Side
 The system administrator/Web Master initiates and updates the system using
his/her preferred privileges
 The server side should be registered on the local or any other service provider.
 It should have Internet connection and database driven-website for remote access.
 It automatically saves the changes and take backups.

3.4.6.2 Exception Handling

32
You are expected to write the exceptions of your project, for example, see the following
example

 The system will display messages if it is tried to access using wrong/invalid account
by checking against the account table.
 The Customer can’t order books that are not available in the system.
 If the customer enters random credit card number or bank account, it checks and
gives a message.
 It uses two hard disks in order to prevent data lose in case of system crashes.
 There will be a recovery mechanism so as to save temporary states in the case of
network link failure.
3.5 User-Interface Design
It is important that all developers have an understanding of the basics of UI design. Constantine
and Lockwood (1999) describe a collection of principles for improving the quality of your UI
design. These principles are
 The structure principle  The feedback principle
 The simplicity principle  The tolerance principle
 The visibility principle  The reuse principle

33
 Chapter Four: Implementation and Testing

4.1 Implementation

Writing the code based on the design of the system, you have created in design phase. You can
use any programming language. However, if the system were designed in Object Oriented
methodology, the implementation should be object oriented programming language.

Include comments inside the code to add readability.

4.2 Choose Your Test Approach

Testing and evaluation of the system gives different benefits for the system development team. It
helps the team to find defects and builds confidence. Therefore, the team should select
appropriate testing approach based on the project area. You may use the following testing
approaches

 Black box testing. Black-box testing, also called interface testing, is a technique in
which you create test cases based only on the expected functionality of a method, class,
or application without any knowledge of its internal workings. One way to define black
box testing is that given defined input A you should obtain the expected results B.
 White-box testing. The basic concept is you look at your code, and then create test cases
that exercise it.
 Boundary-value testing: itis based on the knowledge that you need to test your code to
ensure it can handle unusual and extreme situations. E.g. February 29th of a leap year.
 Unit testing. This is the testing of an item, such as an operation, in isolation.
 Integration testing. This is the testing of a collection of items to validate that they work
together

4.3 Functional Test Specifications

The specification will be described according to the test types that will be done on the system.
The tests that are done are as follow:
 Test_Register Customers
 Test_Login

34
  Test_Search Books
 Test_Select Books
 Test_Order Books
 Test_Report generate

Consider the following example

Test_Login Customer

Test name: Login Customer

Test Description: The login test is used to check whether any one access the system or only
those registered customers have an access to the system

Actions Test Procedure Input Expected test Pass /fail

result
The customer should click Customer’s The page that Pass-the customer
Test login button appropriate user Id enables the can search, select
login Log-in Page screen is and password. customer to and order books.
system displayed search, select and
Customer enters his/her order books is
user name and password. displayed.

Incorrect user Id “Please Enter Pass- Customer

and password correct username can’t access the
and password “ pages.
message display,
Test case Name: Login
Purpose of test: authorization test

Testing objects: Login checking

Test focus: correct User Id and Password validation

35
 Test Process

1. Starting condition

o The customer should click login button

o The login Page screen is shown.
2. Input

o Customer enters his/her personal user Id and password

o Then clicks sign-in.
3. Expected result

o At the time of sign-in, if the user Id and password are valid search page will
be displayed and accessible to the customer.
4. Failure Condition

o If customer enters random user Id and password, write the correct once. If
password is not enters, please enter your password message will be displayed.

Chapter Five: Conclusion and Recommendation

5.1 Conclusion
 Write the concluding remark about your project. About why you do? How you do? What
output you get? Etc.

5.2 Recommendation
 Draw your recommendation for future projects.

36
Reference
List all your references used while doing your projects.

For example:

 Daniel R. Clark, Beginning Object-Oriented Programming with VB 2005: From Novice

to Professional, ISBN (pub): 1-59059-576-9

Annex 1
 Attached documents used for data collection, if any. For example questionnaire, guided
interview questions etc.

Annex 2
 Attach forms and relevant documents collected from the organization. For example, is it
registrar system attach Add and Drop form, Registration Form, Clearance Form etc.
which is relevant for developing the application.

Annex 3
 Attach sample code from your implementation. It should be advanced code, for example,
database connectivity code etc.

Annex 4
 Attach declaration Form

37