INDEX
Topic No.
Topic Name
Page No.
1.1 Introduction
2.
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
3.
Identification Of Need
Preliminary Investigation
Feasibility Study
Project Planning
Scheduling
Software Requirement Specifications
Software Engineering Paradigm Applied
Data Models
SYSTEM DESIGN
3.1 Modularization Details
3.2 Database Design
3.3 User Interface Design
4.
CODING
4.1
4.2
4.3
5.
TESTING
Testing Techniques And Testing Strategies Used
6.
7.
8.
REPORT
9.
10.
11.
CONCLUSION
BIBLIOGRAPHY
Page 1
Processing system.
Maintaining information of customers, Service providers and services.
Keeping records of Service calls information.
Allowing customers to get registered online and request for services.
Allowing sorting of various services based on categories.
Keeping records of pay bills for each service provided and their
reports.
PROBLEM DEFINITION:
Page 3
2. SYSTEM ANALYSIS
2.1 IDENTIFICATION OF NEED
The system aims to provide a solution for multiple services needs faced
by people in urban as well as rural areas. In areas where there are
inadequate service providers or there is no knowledge of available service
providers, the system provides a unique solution. The system registers
various service providers throughout the city.
Page 5
Page 6
Call
Processing
System,
commonly
available
technologies
Page 7
our
proposed
system,
the
development
cost
is
optimized.
The
2.3.3
Legal Feasibility
The Service Call Processing System follows all the rules and regulations
governed by the law. Also the system doesnt conflict with legal
requirements. Thus the Service Call Processing System is legally feasible.
Page 8
Page 10
The phases and sub-phases of the tasks those were carried out while
implementing the project is tabulated below:
2. SYSTEM ANALYSIS
3. SYSTEM DESIGN
4. CODING
5. TESTING
System Testing
6. IMPLEMETATION AND MAINTENANCE
2.5.1 Gantt chart: A Gantt chart is a type of bar chart that illustrates
a schedule. It illustrates the start and finish dates of the terminal elements
and summary elements of a project.
Weeks
1. INTRODUCTION
TABLE OF INDEX
1.1 Purpose
Page 13
any actual design or development work .SRS meets IEEE-830 standards and
is exclusive requirements document to be used in development of SERVICE
CALL PROCESSING SYSTEM by the developers of this system.
1.2 Project Scope
This project is developed for providing solution to various problems of
customers and providing them appropriate solution. The System can be
employed in urban cities as a boon but has limitation in rural areas where
service providing may take time. There is no facility of keeping record of time
within service provided and the measure of quality of the service provided.
The customer response for the service provided is not recorded.
1.3 Document Conventions
This document is written in general English like language. Some figures are
used for displaying input/output formats.
1.4 Intended Audience and Reading Suggestions
Developers, Project Managers, Users like Customer, college faculties,
Network admin, students, testers, and documentation writers are the
different types of readers that the SERVICE CALL PROCESSING SYSTEM
is intended to use.
Page 15
For more information, the brief study of network is done and the
same information is used to prepare this SRS. For subsequent information,
interview with IT professionals and students was conducted and their
requirements were also analyzed.
2. Overall Description
2.1 Product Perspective
This project is a new, self contained product. This SRS defines a component
of large system. As any college or an organization is a quite a big
organization, it should depict the whole system behavior. The program will
run on a 3 tier client/Server architecture, which means, we have 3 tiers (i.e.
Client, Server and Database Server) for execution of the system. Client can
also be called as a browser through which the user interacts with the
system, Server is the system which runs our dynamic script and all the data
related to project is saved on Database server which runs a RDBMS
program.
2.2 Product Features
The major features that this project exhibits are represented in this Data
Flow Diagram
Page 17
Page 18
An instruction manual will be provided to help End User. Along with this,
proper error messages are also provided while using the system.
2.6 Design and Implementation Constraints
The user has to register for the web application. The users of the
system have to remember his username and password and use the
same before each login. Until the user logs in, he is not able to access
all the rights but he can be a inactive user for the web application and
can only view the content but cannot interact with it.
Page 19
Raw data inserted into the system are permanently stored in tables; hence
processor having free space will be useful for faster storage and retrieval of
data.
HARDWARE REQUIREMENT
Hardware specification
Processor
RAM
Hard Disk
Monitor
15 Color monitor
Key Board
122 Keys
Front End : ASP. Net (Frame work Version 3.5) With c#.
Back End
Operating System
Front End:
DOT NET:
.NET is framework an API for programming on the windows platform.
Along with the .NET, VB is a language that has been designed from scratch
to work with .NET as well as to take advantage of all the progress in
developer environments and in our understanding of objects oriented
programming principles that have taken place over the past 20 years.
We should make it clear that backward compatibility has not been lost
in the process. Existing programs will continue to work, and .NET was
designed with the ability to work with existing software. Presently,
communication between software components on windows almost entirely
takes place using COM. Taking account of this; .NET does have the ability to
provide wrappers around existing COM components.
Advantages of .NET:
1) Object-Oriented Programming: Both the .NET Framework and VB are entirely based on objectoriented principles right from the start.
2) Good Design: A base class library, which is designed from the ground up in a
highly intuitive way.
3) Language Independence:-
Page 21
With .NET all of the languages Visual Basic .NET, C#, J#, and
managed C++ compiled to a common Intermediate Language. This
means that languages are Interoperable in a way that has not been
seen before.
4) Better Support for Dynamic Web Pages: While ASP offered a lot of flexibility, it was also inefficient
because of its use of Interpreted scripting languages, and the lack of
object-oriented design often resulted in messy ASP code .NET offers
an integrated support for web pages.
5) Efficient Data Access: A set of .NET components, collectively known as ADO.NET,
provides access to relational databases and a variety of data sources.
6) Code Sharing: .NET has completely revamped the way that code is shared
between applications, introducing the concept of the assembly, which
replaces the traditional DLL. Assemblies have formal facilities for
versioning and different versions of assemblies can exist side by side.
7) Improved Security: Each assembly can also contain built-in security information.
8) Zero Impact Installation: There are two types of assembly: shared and private. Shared
assemblies are common libraries available to all software. Private
assemblies are intended only for use with particular software.
9) Support for Web Services: Page 22
ADO.NET:
Page 23
4. Functional Requirements
In functional requirement, the description of the each function required to
solve a problem is presented. Functional requirements may be calculations,
technical details, data manipulation and processing and other specific
functionality that define what a system is supposed to accomplish.
Functional requirements are supported by nonfunctional requirements (also
Page 25
Page 26
Page 27
Analysis,
Design,
Construction,
Testing,
Production/
Page 28
The unmodified "waterfall model, Progress flows from the top to the
bottom, like a waterfall.
System Analysis
System Design
Coding
Testing
Implementation
and
Maintenance
Page 29
Here, in this stage, the requirements which the software is going to satisfy
are listed and detailed. For this purpose interview with insurance firm
professionals and faculties/agents of the company was conducted. And also
during the preliminary investigation, visits were made to organizations to
study the need. Feasibility study of the SERVICE CALL PROCESSING
SYSTEM project was made using the TELOS model to find out the Technical
feasibility, Economic feasibility, Legal feasibility, Operational feasibility, and
Schedule feasibility.
2. System Analysis
At the system analysis phase, first the detailed requirements of SERVICE
CALL PROCESSING SYSTEM were worked out. These included the external
interface requirements, input and output formats, hardware and software
requirements, logical database requirements and data dictionary, various
constraints, functional and non functional requirements. At the end of the
requirement gathering, a software requirement specification (SRS) document
was created s per IEEE 830 recommendations.
Next with reference to the requirements gathered the project planning
including cost, effort and budget estimates were made , the scheduling was
done using PERT and Gantt charts, the software to be applied in
development of SERVICE CALL PROCESSING SYSTEM was worked out and
detailed data flow diagram and entity relationship diagrams were created.
3. System design
At the system design phase, the modules of SERVICE CALL PROCESSING
SYSTEM were determined and logical relationships were worked out.
Following this, the database design was undertaken and the underlying
Page 30
tables,
attributes,
constraints,
keys,
attribute
types
etc,
were
also
actual coding of
SERVICE
CALL
PROCESSING
SYSTEM
was
undertaken in this stage. The coding was done module-wise as the modules
were more or less independent of each other. After the coding for all modules
were completed, the actual feedback variables were used to revise the
modules, and completed the coding. After the preliminary coding was
completed, efforts were made to include extensive error checking and
validation checks in critical places of the code and comments and
descriptions were added.
5. Testing
The SERVICE CALL PROCESSING SYSTEM was subjected to extensive
testing using the unit testing, integration testing and system testing
approach. Elaborate test cases were designed for each phase before the
testing. During the unit testing phase, the text boxes, combo/drop down
menus, buttons were tested. During the integration testing, the interoperability of the modules was tested and specifically it was tried to
ascertain whether data generated in one phase/module were available in the
next module. In the system testing phase, the system was tested as a whole
to find out whether all the functional requirements of SERVICE CALL
PROCESSING SYSTEM as mentioned in the SRS were satisfied.
Page 31
2.8.1 DFD
A data flow diagram (DFD) is a graphical representation of the "flow" of data
through an information system, modeling its process aspects. It is a
modeling technique for analyzing and constructing information processes. It
illustrates how data is processed by a system in terms of inputs and
outputs.
Following are the notations used in a Data Flow Diagram.
Table 2.2 DFD Notations
SYMBOL
MEANING
Page 32
PROCESS
INPUT/OUTPUT
DATASTORE
DATAFLOW
2.8.1.1 Context diagram: The top level diagram often called as context
diagram it contains single process but it plays important role in studying
the current system. Input -Process-Output.
Login Information:
SERVICE
CALL
PROCESSING
Website
System
User
User
(Admin)
CUSTOMER
SERVICE
CALL
PROCESSI
NG
DETAILS OF SERVICE PROVIDER AND
MANAGER
CUSTOMERS
0.
RECEIVE
PROVIDE
GENERATE
BILL
SERVICE
BILL
AND
GIVE
REQUEST
FOR
SERVICE
ACCEPT
REQUEST
REQUEST
REGISTRATION
FOR
OF
SERVICE
SYSTEM
SERVICE
PROVIDER
Page 33
MANAGER
REQUEST
FOR
REQUIRED
ACCEPT
PROVIDE
PAY REGISTRATION
PROVIDE
SERVICE
SERVICE
REQUEST
SERVICE
CALL
SERVICE
2.8.1.3 Level-1 DFD :The next stage is to create the Level 1 Data Flow Diagram. This highlights
the main functions carried out by the system. It describes the following:
Shows all the processes that comprise a single process on the level 0
diagram.
Shows how information moves from and to each of these processes.
Shows in more detail the content of higher level process.
Following is the level 1 DFD for Service Call Processing System.
Page 34
Page 35
Provide Information
SERVICE CALL
ENQUER
Y
SERVICE CALL
2.0
Request For
Registration
Accept
Request
CUSTOMER
REGISTRATIO
ON
CUSTOMER
CUSTOMER
3.0
Types of Services
Types of Services
SERVICES
SERVICES
Services Info.
CATEGORY MASTER
SERVICES MASTER
4.0
Request For
Registration
Accept
SERVICE
Complaint Call
Provide
Request for service
Requirement of service
SERVICE
PROVIDER
REGISTRATIO
ON
Register
Service
Provider Info
SERVICE PROVIDER
5.0
COMPLAINT
PROCESSING
Provide service
Customer Complaints
Provider Serv. Provd.
Complaint Solution
COMPLAINTS
SERVICE TO
COMPLAINT SOLUTION
A
Page 36
CUSTOMER
6.0
Give Bill To Customer
Received Bill From
Generate Service Call
Bill
CUSTOMER
BILL
PROCESSING
Bill Receipt
RECEIPT
MANAGER
7.0
Deduct Charges and Pay
Service Bill
Give Service Provided
Pay Service Provided Bill
SERVICEP
ROVIDERS
BILL
PROCESSING
PAYMENTS
SERVICE
SERVICE CALL
SERVICE CALL
8.0
SERVICE CALL
SERVICE CALL
REPORTS
SERVICE CALL
SERVICE CALL
SERVICE CALL
SERVICE CALL
SERVICE CALL
SERVICE CALL
CUSTOMER LIST
CUSTOMER LIST
LIST OF COMPLAINTS
LIST OF COMPLAINTS
SERVICEPROVIDER
SERVICEPROVIDER
LIST
LIST
SERVICE TO COMPLAINT
SERVICE TO COMPLAINT
DATEWISE
DATEWISE
COMPLAINT SOLUTION
COMPLAINT SOLUTION
SERVICES LIST
SERVICES LIST
SERVICE TO
SERVICE TO
COMPLAINT
COMPLAINT
DATEWISE
DATEWISE
DATEWISE
DATEWISE
COMPLAINT
COMPLAINT
SOLUTION
SOLUTION
CASH RECEIVED
CASH RECEIVED
SERVICE PROVIDER
SERVICE
PROVIDER
HISTORYDATEWISE
HISTORYDATEWISE
CUSTOMER HISTORY
CUSTOMER HISTORY
DATEWISE
DATEWISE
SERVICE CALL
SERVICE CALL
Page 37
Page 38
2.8.3 ERD
An ERD is a model that identifies the concepts or entities that exist in a
system and the relationships between those entities. Entity Relationship
Diagrams (ERDs) illustrate the logical structure of databases.
Entity Relationship Diagrams (ERDs) illustrate the logical structure of
databases.
There are three basic elements in ER models:
MEANING
ENTITY
RELATIONSHIP
ATTRIBUTE
KEY ATTRIBUTE
DERIVED
ATTRIBUTE
Page 39
CARDINALITY
MULTIVALUE
ATTRIBUTE
Page 40
ER Diagram:
Page 41
Page 42
SYSTEM DESIGN
System design is one of the very important phases of System
Page 43
which are used daily. The Services are Education, Engineering, Retail,
Health-Care, House-Hold and many more.
User Module:
Every user will be given a username and password by the administrator,
using which should log-in the System to register the complaint.If username
and password is not provided or if the password is wrong then the user is
not allowed to proceed.
Administrator Module:
In this module the administrator has a privilege to create the category,
Services, Service provider, update and delete also, the administrator can
also view the reports of all details to see the customer who have made the
complaints.
3.3 DATABASE DESIGN
The SERVICE CALL PROCESSING SYSTEM project database consists
of tables. Appropriate primary keys, foreign keys have been set up in the
database. The various tables in the database are described below:
This Software requires a windows platform like any one of WIN98/WIN
2000/ WIN XP .It needs VB.NET as front end and SQL SERVER back end.
Page 44
The data base of the table fields are not kept null. Because every field
constraints are not null.
DATABASE STRUCTURE
Column Name
Data type
Length
CtID (PK)
Numeric
CtName
Varchar
50
Description
Primary key for Category.
This field gives information about
Category Name.
Column Name
Data type
Length
SrID (PK)
Numeric
SrName
Varchar
50
CtID
(ref:
CategoryMaster)
Numeric
Charges
Numeric
UserID
Numeric
Description
Primary key for Services.
This field gives information about
Service Name.
This field references CtID in
Category Master.
This field gives information about
Charges of service.
This field references UserID in
UserMaster.
Page 45
Column Name
Data type
Length
SrpID (PK)
Numeric
SrpName
Varchar
100
SrpAddress
Varchar
200
SrpPhone1
Varchar
15
SrpPhone2
Varchar
10
Numeric
Numeric
Numeric
6
7
8
CtID
(ref:
CategoryMaster)
SrID
(ref: ServiceMaster)
UserID
Description
Primary key for ServiceProviders.
This field gives information about
Service Provider Name.
This field gives information about
Service Providers Address.
This field gives information about
Phone number 1.
This field gives information about
Phone number 2.
This field references CtID in
Category Master.
This field references SrID in Service
Master.
This field references UserID in
UserMaster.
Column Name
Data type
Length
CutID
Numeric
CustName
Varchar
100
CustAddress
Varchar
200
CustMbNo
Varchar
10
CustPhNo
Varchar
15
UserID
Numeric
Description
Primary key for Customer.
This field gives information about
Customer Name.
This field gives information about
Customer Address.
This field gives information about
Customers Mobile number 1.
This field gives information about
Customers Phone number 2.
This field references UserID in
UserMaster.
Column Name
CompID
Data type
Numeric
Length
9
Description
Primary key for Customer.
Page 46
CompDate
DateTime
CompTime
Varchar
Numeric
Numeric
4
5
CustID
(ref:
CustomerMaster)
SrID
(ref: ServiceMaster)
Stat
Varchar
15
UserID
Numeric
Column Name
Data type
Length
STCID
Numeric
STCDate
DateTime
STCTime
Varchar
Numeric
Numeric
Numeric
4
5
6
CompID
(ref: Complaints)
SrpID
(ref: ServiceMaster)
UserID
Description
Primary key for
ServiceToComplaint.
This field gives information about
Date of Service Provided for
Complaint.
This field gives information about
Time of Service Provided for
Complaint..
This field references CompID in
Complaints.
This field references SrpID in
ServiceProviderMaster.
This field references UserID in
UserMaster.
Column Name
Data type
Length
SolID
Numeric
SolDate
DateTime
Numeric
Numeric
3
4
CompID
(ref: Complaints)
STCID
(ref:
ServiceToComplaints)
Description
Primary key for
SolutionToComplaint.
This field gives information about
Date of Solution Date for the
Complaint.
This field references CompID in
Complaint.
This field references STCID in
ServiceToComplaints.
Page 47
Problem
Varchar
200
Solution
Varchar
200
Charges
Numeric
UserID
Numeric
Column Name
Data type
Length
CallID
Numeric
CallDate
DateTime
CallTime
Varchar
Varchar
100
Numeric
4
5
EnqName
(ref: CustomerMaster)
SrID
(ref: ServiceMaster)
Stat
Varchar
15
UserID
Numeric
Description
Primary key for Customer.
This field gives information about
Customer Name.
This field gives information about
Customer Address.
This field references CustID in
CustomerMaster.
This field references SrID in
ServiceMaster.
This field gives the status of the
complaint
This field references UserID in
UserMaster.
Column Name
Data type
Length
Description
CallID
Numeric
SrpID
(ref:
ServiceProviderMaster)
Numeric
Column Name
Data type
Length
Description
RctID
Numeric
RctDate
DateTime
Page 48
SolID
(ref:
ComplaintSolution)
SrID
(ref: ServicesMaster)
Numeric
Numeric
SrTax
Numeric
9(18,2)
Other
Numeric
9(18,2)
UserID
Numeric
PayID
Numeric
PayDate
DateTime
Numeric
Numeric
3
4
CompID
(ref: Complaints)
SrpID
(ref:
ServiceProviderMaster)
Charges
Numeric
UserID
Numeric
Column Name
Data
type
Length
UserID
Numeric
UserName
Varchar
15
Password
Varchar
15
Description
Primary key for User.
This field gives information about
Users Name.
This field gives information about
Password
Page 49
Page 50
Various Services:
Page 51
Service Introduction:-
Page 52
Register Form;-
Page 53
Login to Website:-
Page 54
User Home:-
Page 55
Services List:-
Page 56
Page 57
Send Complaint:-
Page 58
Page 59
Admin Home:-
Page 60