Customer Relationship Management System (Aamer1)

Software Requirement Specifications (SRS)
In the name of Allah, Most Gracious, Most Merciful.
UCP Application Development Project Standards 1


PROJECT TITLE
CUSTOMER RELATIONSHIP MANAGEMENT SYSTEM
CRMS
MEMBERS
AAMER QAYYUM KHAN
BBIT (HONS)
IQRA UNIVERSITY,
LAHORE CAMPUS
ADVISOR
PROF: DR. ADNAN

DEDICATION
I dedicate my work to my parents, without whom encouragement nothing
would have been possible. Thank you for your love and support.
Last but not the least I would like to dedicate this work to the Great of asset of
our country “PAKISTAN ARMY” who are the defenders of our borders. I am
feeling extremely proud for dedicating my work to the brave & valiant soldiers of
our beloved country who are holding the motto for the nation that
“If I don’t come back, tell them,

I have sacrificed my today for their tomorrow”


Acknowledgement
Praise to Allah the most beneficent and the most merciful, gave me the power
of knowledge to overcome this task. I would like to thank my parents and my
Advisor Dr. Adnan for his support, cooperation and his faith in me. I would also
like to thank my colleagues for their support and ideas.



Software Requirement Specification
Chapter 1
Section 1: Vision Statement
The need for this system arose in order to overcome the limitations of previously working
software this product would abide by the latest conventions and standards to ensure better
conformity and to compete with existing software’s of its nature.
1.1 Software Purpose
Name CRM FOR MOBILE PHONE COMPANY

Release No. 1
Version No. 1.0
System Subsystem Revision

Description
The proposed system would assist customer relationship management for a
mobile phone company via website.
1. 2 Software Scope
The software will facilitate customer relationship management the current systems is
telephone based CRM system and the customer does not get the required information in a
straightforward manner the purposed system being online would provide the client with
all the information in plain and efficient manner all the billing and supplementary
transactions with the customer will be carry out online.
Customers (client) have much importance in any organization the goal of this software is
to provide the customer with all the required information regarding their valued
investments and to keep the good will of the customers.
This software will be much more efficient compared to telephone based CRM system and
will be mutually beneficial for both company and the customers.
1. 3 Software Perspective
There are many companies that are providing mobile services and this number increases
day by day. In these competitive circumstances, there is a serious concern for these
companies to pay attention towards maintaining strong relationship with its customers.
The relationship with the customers should be strong enough to hold them to the
particular cellular network. The system that is being developed aims to provide support
and services to the customers through a consistent channel, this is how the thought of
developing this system emerged.

This proposed product would be linked to official website of MOBILINK but would be
completely stand alone in its functionality it would be a self contained product and would
only require raw data and some feedback as an input, although there are certain similar
products already in application at certain organization yet it is the first member (1st
version) of its family. The product would be developed according to latest standards and
therefore would hopefully be competitive enough to replace its current counter parts.
1.4 Document conventions and definitions
HEADING FONT
TYPE: Times New Roman SIZE: 12 BOLD
OVERALL FONT
TYPE: Times New Roman SIZE: 12
SUBHEADING FONT
TYPE: Times New Roman SIZE: 12 BOLD
1. 5 Intended audience and reading suggestions

In order to understand the SRS document it is very important that the project scope as
well as the nature of project is completely understood and there are no doubts in the mind
of intended reader, with these two issues handled we believe that it would be
straightforward and understandable.
The intended readers would be the following along with all other stakeholders that are
directly related to the system.
1. Project Manager.
2. Client Engineers.
3. Client Manager.
4. System Developers.

Chapter 2
Section 1: Overall Description
1.1 Introduction
The system is basically a Customer Relationship Management System in which the
backend would be in SQL SERVER and the database would be interpreted by SQL
queries. As an on-line system, It will act as an information source about the organization
and will manage the information of customers for them, As it is a CRM system so it
would provide services related to sales and marketing i.e. online payments, billing, query
management system requests for blocking a sim and much more.
Who the system is being developed for?

Besides the organization, customers mostly young people (age: 18 to 30) and including
businessmen, government officials etc. Gender could be male/female. The users could be
any one who uses a mobile phone.
The end users of the system being developed are also the people (employees) working in
the organization because the system is directly related to the employees, as they are the
one who would be using it along with the customers. But eventually the system will serve
the customers and will provide the basic services offered by the organization and needed
by the customers.
Why is such a system required?

Customers (client) have a much importance in any organization. These are the people
for whom many organizations work to serve and attract these people to them. To serve
and hold customers to an organization , that organization needs to maintain strong
relationship with its customer. So a system is required which could help the organization
in this regard.
There are many customers related to the mobile service providers and this number
increases day by day. In situation like this, they had to pay serious attention towards
maintaining strong relationship with its customers. The relationship with the customers
should be strong enough to hold them to the particular cellular network. The system that
is being developed aims to provide support and services to the customers through a
consistent channel.
What will be the main challenge for you in building the system?
In building a CRM system the main challenge is that of research and learning of new
tools and technologies along with their implementation using methods and techniques as
required by the task. Research is a main challenge as the technologies that are not known
would be required to be learned and the ones that are already known would be researched
further to increase the functionality and effectiveness of the system.
For developing a CRM system for a cellular network and implementing that system in a
real world environment needs comprehensive research in the particular business. One
needs to know the process and policies of the concerned business. The different theories

related to CRM have to be studied and implemented in the system to provide the CRM
services to the customer.
What new ideas and theory will you need to learn to build the system?
In building a CRM system following would have to be learned:
Languages:
 Any of .NET framework (ASP, ASP.NET, VB.NET)
 Structured Query Language (SQL)
 Hyper Text Markup Language (HTML)
Tools:
 Microsoft Visaul Studio.Net
 SQL SERVER
 Microsoft IIS 5
 Macromedia Dream weaver 4 or higher
 Macromedia Flash 5
 Macromedia Swish 2.0
Brief description of the resources needed by the proposal:

(I.e. hardware, software, access to information/expertise, user involvement etc.)
The minimum system requirement would include standard PC running Windows

95/98/2000/NT operating system. 75 MHZ Pentium or faster (or compatible). 64 MB
RAM (Random Access Memory), VGA or Higher Resolution Monitor (SVGA
Recommended).
Software:
Microsoft Visual Studio.NET (Enterprise Edition)
SQL SERVER
Microsoft IIS 5
Macromedia Dream weaver 4 or higher
Macromedia Flash MX, Swish 2.0
Microsoft Visio
Adobe Photoshop 7.0
Hardware:
Standard PC with modem (for accessing the internet)
Books and research papers are the main source of references for theories on Customer
Relationship Management. Web sites also prove to be another useful resource for
learning technologies such as ASP.NET and SQL SERVER.
For requirements gathering we interviewed the sales manager for problem relating to
sales, marketing manager for their targeted market, users, and problems in marketing.
People Interviewed:
Sales Manager

Marketing Manager
Programming techniques / packages:
The system would be developed using the latest technologies and techniques that are in
use nowadays. In programming, Object Orientated Techniques would be used for
increased functionality, reusability and efficiency. For the front end, ASP .NET would be
used to create dynamic web pages using client side and server side scripting technologies.
For the backend, database would be developed in SQL server. A comprehensive research
on learning these technologies needs to be done to deliver a successful system. For the
research, web sites offering tutorials, support centers, how to articles, code samples,
books and related teachers would be helpful.
Brief description of the development plan for the proposed project:

(I.e. which software methodology and why, the major areas or functions to be
developed and the order in which they will be developed)
Two software methodologies would be used namely Object Oriented Software

Development (OOSD) and Prototyping. Prototyping is being used because it aims to
involve the users in the development of the system. Each time a prototype (function) of
the system will be will be completed, it will be assessed by some users and necessary
changes would be done accordingly.
The system is divided in 4 major development areas which are a follows;
Interface Design:
This area includes the development of the interface of the system. The contents would be
identified along with their arrangement. This will also incorporate the navigational
system by which the user will navigate through the system. For these tasks storyboarding
would be used and HCI considerations would be looked after.
Database Design:
This development area will include designing of the central database in which all the
necessary data will be stored. In this stage, the data will be identified that is to be stored,
entities, attributes along with their relationships with each other.
Coding:
This is the major development area which includes coding of the system in the stated
languages. All the major functions would be developed and testing side by side. After
development, integration of all the units would be done and tested to see the functionality
after integration.
Installation and Configuration:

This stage will include the installation of the system along with the configuration. The
configuration would include the configuration of the Microsoft IIS 5 server which will
host the system.

Brief description of the evaluation and test plan for the proposed project:
Testing of the system would be considered as an ongoing process which would be

conducted after development of every function and at the integration of these functions.
Some of the major testing areas include;
Data Validation Test:

This test would be done throughout the development and finally after the development
i.e. integration. The will include preparation of test data and entering that data valid or
intentionally invalid in the system to check that the system accepts no garbage data in the
database.
Security Test:
This test will ensure that no unauthorized user is able to enter the system as administrator
and make any updation to the system.
Dot Net Framework and ASP.Net
As the CRMS would be maintaining an online database to store information so Microsoft

Dot Net Framework (ASP.Net) was chosen for the development of the system. ASP.Net
is a new powerful server side technology for creating dynamic web pages. The Dot Net
Framework is a collection of technologies to provide the developer with a wide range
object to use. It consists of a number of different libraries, classes and assemblies that
could be used by the developer to provide the functionality as desired. The components
of the framework include firstly a MS Intermediate Language (MSIL) which is the form
that ordinary code is transformed into after compilation. All languages used in the
framework i.e. VB.Net, C#, Jscript.Net are the same in this Common Language of Dot
Net. Secondly a Common Language Runtime (CLR) which is responsible for the
execution of the MSIL code on the computer and also proves to be an interface between
the application and operating system and web server. Thirdly Framework Class Libraries
which are code libraries that contain a large collection of functionalities (code) that the
developer can use as desired by the requirements. Lastly ASP.Net which can be seen as
the element to use the Dot Net Framework over the web. The IIS is used to host ASP.Net
web pages that are compiled to full Dot Net programs which are used to generate html
that is sent to the user who requested them.
Justification of Choice
ASP.Net has been chosen the technology for the development of the CRMS instead of
classic ASP. ASP.Net was preferred over ASP, as the chosen one provides certain
benefits when compared. Firstly ASP is restricted to use only VBScript/JavaScript which
are not complete programming languages to add processing logic to the web page while
ASP.Net offers a variety of programming languages like VB.Net, C#, Jscript.Net for the
development of the system. Moreover it separates the code from html by providing two
file in a web page. One being the html file that has relevant formatting instruction while

the other code behind file that contains the server side code. Then ASP object support
consists of six main objects which are components that make web development dynamic.
The objects are interface based, not object based so are often called components. Object
usage could be extended with COM objects or COM+ (including transactions) that can
interact with ASP objects. It supports default interface COM programming, not multiple
interfaces. COM and COM+ objects tend to need GUI tools that automate their creation.
ASP.Net can also consume COM and COM+ objects and can be used to create objects
that support interfaces and inheritance. Languages can inherit and override methods of
objects created in different languages. These can be built with text editors and GUIs are a
convenience not a necessity. The components could be transformed into SOAP listeners
and proxies with trivial amounts of work by just setting a few attributes. Classic ASP has
Database support via ADO which communicates with ODBC and OLEDB databases.
Most database display is done through record sets and loops. Most database manipulation
requires code coupled to back-end database that may fail if drivers are switched and
needs to be written while ASP.Net supports data access via ADO.net which
communicates with ODBC and OLEDB databases, XML Streams, Binary Streams but is
loosely coupled so differences between database vendors do not affect the programming
model. Moreover database display never involves loops. Templates, grouped controls,
Grids and many other structures eliminate need for loops and flexibility is provided so
programmer can control all interaction between these objects. ASP is a browser neutral
technology but ASP. Net’s validators and built-in components use detection to render
GUIs that behave consistently on a variety of browsers. ASP.net has lots of facilities so
that controls can detects the browser and renders the GUI very differently depending on
what browser requests the page without having to expose this sensing to higher level call.

Section 2: System features
2.1 System Features of an Administrator
2.1.1Login:
This is executed when administrator wants to use the services provided by the
website, administrator enters his login and password and if authenticated by the
system the user is allowed to enter the website.
2.1.2Add connection:
This is executed when administrator wants to add connections in the inventory list,
the administrator presses the add connections link on the main page and enters the
serial number the system saves this information in the database and a connection is
added.
2.1.3Add bills:
This is executed when administrator wants to add bills of customers in order to
process their requests to pay bills the administrator presses the add bill link on the
main page system show the customer name and submits the form the user also enters
the customer information. This request goes to the system and if there is no problem
the bill is added.
2.1.4 Add sub administrator:

This is executed when administrator wants too create sub-administrator who can
perform all the functions of the administrator except creating sub-administrator the
administrator presses the create sub-admin link on the main page the user enters the
sub-administrator information and submits the form, the request is processed by the
system and a sub-administrator is created.
2.1.5 Block sim:

This is executed when administrator wants to block some ones sim. The administrator
enters the block connections link on the main page the system shows the unblock
connections and sim status the user blocks the connection in sequence or by searching
a specific customer.
2.1.6 Online payment request:

This is executed when administrator wants to view and process on line payment
requests the administratorpresses the online payment request link on the man page the
system shows the number of pending requests the user either views the customer
profiles or presses the add to online link which changes the status to online request
from seen to unseen and the information is stored in database.

2.1.7 Roaming request:

This is executed when administrator wants to view and process roaming requests by
customers the administrator presses the international roaming request link on the
main page the system shows the number of pending requests, the user start viewing
the requests and will also switch their international roaming on if there is no problem
with the customer information
2.1.8 View feedback:
This is executed when administrator wants to view feedback of some customer this
system show the feedbacks pending the user views the feedbacks and the system
removes that particular feedback from the list that has been seen by the administrator.
2.1.9 View queries:

This is executed when administrator wants to view feedback of some customer this
system show the feedbacks pending the user views the feedbacks and the system
removes that particular feedback from the list that has been seen by the administrator.
2.1.10 View customer profile:

This is executed when administrator wants to view profile of some customer. The
administrator presses the view profile link on the main page the system shows a
search bar to search for certain customer, the system shows the customer profile.
2.1.11 Update profile:
This is executed when administrator wants to update his profile, the administrator
presses the update profile link on the main page he/she views its profile and updates it
and submits it which is saved over his/her previous profile
2.1.12 Connection information:
This is executed when administrator wants to view connections information, the
administrator presses the connections information link on the main page the system
displays complete information about all the connections sold and available in the
inventory list.
2.1.13 Payment information:

This is executed when administrator wants to view payments information, the
administrator presses the payments information link on the main page the system
displays complete information about all the payments made i.e. bills paid or
connections sold.
2.1.14 Change password:

This is executed when administrator wants to change his/her password the
administrator presses the change password link on the main page the system displays
him a form a form the user enters his password information which if validated, his
profile is changed with the new password .
2.1.15 Logoff:
This is executed when administrator wants to stop using the services provided by the
site. The administrator presses the log off link on the man page and his connection is
blocked from the site he cannot interact with the site any more.

2.2 System Features of the Customer
2.2.1 Register user

This is executed when user want to register him/her self for the first time the user presses
the register user link on the main site, system opens a form user fills the form and submit
if the information has no problem the user is given his/password and username.
2.2.2 Login
This is executed when user wants to use the services provided by the website so he/she
logs in the system, user enters his login and password and if authenticated by the system
the user is allowed to enter the website.
2.2.3 Pay bills

This is executed when user wants to pay his pending bills online. They user presses the
pay bill link on the user main, the system shows him his pending bills he adds his credit
card details the system verifies his card and if the card is verified his bill is paid online
2.2.4 Connection status

This is executed when user wants to by his connection online. The user presses purchase
connection link on the purchase connection page, the system displays him the availability
of connections the user enters his references and card information which is verified form
the system and if valid he gets a serial number which he can take to the nearest branch of
Mobilink to get his connection.
2.2.5 Query
This is executed, when user wants some information from the system. User writes the
query on the query window and sends it through the website to the CRMS system where
his query is studied and replied later.
2.2.6 Feedback
This is executed when user wants to give some feedback about the system or about its
some feature. The user presses feedback link on the main page he/she enters its feedback
which is send to CRMS centre for further processing and is used to make system more
useful and user friendly
2.2.7 Request online payment

This is executed when user wants to convert his billing to online from offline, user
presses the request for online payment link on the main page system shows the customer
his/her profile and mobile number if the information is correct the user submits it this
request is processed by the system and if there is no problem the billing of customer is
switched from offline to online
2.2.8 Block sim

This is executed when customer wants to block his connection online, the user presses the
block connection link on the main page he/she views its profile and mobile number and if

the profile is ok and the number is the same as the customer wants to block then he sends
the request which is processed by the system and if there is no problem his sim is
blocked.
2.2.9 International roaming
This is executed when user wants to switch on his international roaming through internet,
the user presses the international roaming link on the main page he/she views its profile
and sends request which is processed by the system and it there is no problem roaming is
switched on for the particular customer.
2.2.10 Update profile

This is executed when user wants to update his profile, the customer presses the update
customer profile link on the main page he/she views its profile and updates it and submits
it which is saved over customer’s old profile.
2.2.11Change password
This is executed when user wants to change his/her password the user presses the change
password link on the main page the system displays him a form a form the user enters his
password information which if validated, his profile is changed with the new password .
2.2.12 Logout
This is executed when user wants to stop using the services provided by the site. The user
presses the log off link on the man page and his connection is blocked from the site he
cannot interact with the site any more.

Chapter 3
Section 1: Analysis and Design
1. 1 Overview of Analysis
The analysis phase holds much importance in the development process of a system as the
outputs of this phase helps in understanding the underlying nature of the system. At this
time the functional and other requirements are gathered that clarifies different features of
the system. Above all, the user requirements are collected. These requirements are
gathered by letting people to fill a questionnaire and by interviewing people related to the
particular business as they are serving the customers and know much about their needs
and problems. The requirements that have been gathered are then examined carefully to
formulate use cases. The development of use cases is a good approach in determining the
user requirements and hence the functionality of the system. UML is used to make the
use cases. The use cases describe what the system has to do and not how it would be
done. Besides, user requirements regarding the interface of the system are collected
which helps in designing of the first prototype that could be evaluated and necessary
amendments could be made to the prototype.
1.2 Requirement Specifications
1.2.1 The Problem

The need for a CRM system for the company arose from entering of many cellular
networks in the market in turn increasing the competition among the companies day by
day. Besides this, customer un-satisfaction resulted in low sales in the region was the
primary cause of developing the system. The network is being upgraded to increase its
performance along with the CRM system is being develop to maintain the relationship
with the customers.
The traditional service solution for the company and other cellular networks has been the
call center where the telephone accounts for the majority of interactions. However, call
centers are not a service model that can best address the customer and enterprise
requirements for several reasons. Call centers are inbound, reactive service environments,
requiring costly agent intervention to resolve every issue. Call centers typically suffer
from a lack of access to relevant information, as agents cannot review past interactions
nor gain access to customer data outside the call center database. Without this
information, agents have little understanding of the customer’s behavior or interactions
with other parts of the enterprise.
Customers want a business relationship with the enterprise that delivers firstly more and
more efficient interactions. They demand communication channel choice and around-the-
clock interactions. In addition, as workloads accelerate, they seek higher productivity

through automated interactions that eliminate the need for human intervention to
complete tasks. Secondly greater information and process access. The Internet has made
the possibility of information access and process participation a reality, and customers
want to take advantage of this transparency to gain insight into what is taking place inside
the enterprise related to them. So the proposed web based system aims to relate the
customers directly to the system, which would prove to be an effective way of solving
their problems as described by them. As the customer would be using the system, so the
system should be very user friendly in which the user finds no difficulty in using the
system effectively to satisfy its needs/solve his/her problems.
1. 2. 2 Alternative Solutions to the Problem

There are other CRM software available in the market for use but besides, they are
expensive, they would also not specifically cater the business requirements of
organization. The call center is a way of providing support to the customers but is less
value adding. Instead, a web based CRM system for the subscribers is the best solution to
the problem as it is being developed specifically according to the business requirements
of the company.
1. 2. 3 The Proposed Product

The proposed system is a web based Customer Relationship Management (CRM)
System. The software would maintain an SQL SERVER database for storing relevant
data captured during the interaction with the customer. Structured Query Language
(SQL) would be used for storing and retrieving data. The SQL queries could also be
embedded in any of .NET Framework environments. The system would be developed
using ASP.NET which would be used as a server side as well as client side technology to
create dynamic web pages. The ASP.NET engine would parse the code to regenerate
HTML and Microsoft IIS 5 would provide the engine that can be used as a web server to
work with ASP.NET.
The CRM system will also act as an e-commerce web project. The basic aim of the
system is to facilitate the mobile service for the customers to build an everlasting
relationship with its customers. The system would be a part of the official website of the
company so combined these will act as a CRM system as well as a source of information
and marketing for the new users.
As a CRM system, it will facilitate online payments and registration for the purchase of
new connections, on line payments for monthly billings, query management system,
which would allow customers to send their queries about a problem and receive the
solution, knowledge acquisition for market research with feedback forms, pre and post
transactional information, user manuals, online sales, services to acquire the market.
Besides this, there would be special logins for the employees of the company as
administrators of the system with full authority to the system. These people could make
all the necessary changes and updation to the system and database.

1. 2. 4 The Customers/Users
Besides the organization, customers mostly young people (age: 15 to 30) and including
businessmen, government officials etc. Gender could be male/female. The users could be
any one who uses a mobile phone. A large number of users (i.e. approx. 1,000,000)
would be using the system. Most of them would be computer literate who just know how
to operate a computer or at least know to use the Internet. These people are currently
provided support from call centers but with new system, not much time of the user will
be wasted and he/she would be provided with value added services to support them.
The end users of the system being developed are also the people (employees) working in
the organization because the system is directly related to the employees, as they are the
one who would be using it along with the customers. But eventually the system will serve
the customers. As the organization is a mobile service provider so the customers who
have any queries would be using the system.
1. 2. 5 The Environment
The implementation of the new system would result in changing of some of the
environmental factors of the company because the proposed system aims to computerize
most of the operations that are manually done by the company. For instance, the online
sales of new connections will be done through the system (Internet). This will involve in
modification of some of the business processes.
1. 2. 6 Functional Requirements
1. 2. 6. 1 Business and Customer Requirements

The new system is based on specific requirement of business as well as customer to
facilitate both. Following are the requirements compared with the functionalities of the
system.
As mobile service provider, the company operates for a large number of subscribers.
Providing a group of people at the call center for their support is not enough. Instead,
subscribers should be involved in the Customer Service Processes i.e. through the system.
Time is an issue for most of the businesses in the world. Company needs to facilitate the
process of order filling and fulfillment to deliver quality products and services within an
acceptable time frame that suits the customer. In this regard, the system aims to provide
online sales and services round the clock for its customers.
Moreover the system shall provide online bill payment facility for its customers who can
pay their monthly bills through the system using a credit card.

In order to provide support for the company’s customers, a query management system is
added with the system to incorporate the queries and their solutions to and for the
customers.
The customers want to be a part of the business process that involves them and a web
based CRMS is the best way of involving them from their home to the company (system).
1. 2. 7 Non Functional Requirements
1. 2. 7. 1 Interface Requirements
The system would be used by a large number of users who have different behavior. Some
would have high computer knowledge while others have limited knowledge. Some
people have different perception than others. So the proposed system requires being user
friendly so that any user who logs on to the system could easily navigate through the
system and would find no difficulty in solving his/her problems through the system.
1. 2. 7. 2 Performance Requirements
The system shall be up to the mark when performance is challenged. The system will take
not more than 15 seconds to load in normal circumstances relating to internet speed and
system usage. The response time for any request to the system would be minimum.
1. 2. 7. 3 Quality Requirements
The CRMS needs to up to the quality standards. This means that the system should be
able to complete the tasks that it is designed for with no errors and faults. This requires
extra amount of work during the testing of the system so that all the modules and
functions are thoroughly tested to identify errors and faults and that must be corrected
immediately
1. 2. 7. 4 System/Hardware Requirements
The proposed system requires a standard PC running Windows 95/98/2000/NT operating
system. 75 MHZ Pentium or faster (or compatible). 64 MB RAM (Random Access
Memory), VGA or Higher Resolution Monitor (SVGA Recommended), a 56k modem to
connect to Internet. Besides, high speed Internet connection is required which could
provide high data rate for transporting the information to and from the system. Monitor
resolution would be incorporated after development.
1. 2. 7. 5 Security Requirements
The business requires security of its systems as well as information. So the system
requires security and integrity of the information that is stored by the system. No
unauthorized individual either in the company or out side the company would be able to

use the system to crash it or retrieve any useful information from the system. Only people
who are authorized by the company would be able to use the system according to their
right privileges.

Section 2: Architectural Design
The CRMS is based on the client server model of web applications. The system would be
maintaining an SQL SERVER database at the backend. This would be a central database
which would be maintaining records of all the persistence entities namely customer,
administrator, billings, sales, inventory, queries etc. The diagram shows a high level
architecture of the CRMS. Every operation that has to be done by the system is in form of
a request made to the web server. Every request is of a certain web page that is designed
to perform some operation. The user PC (personal computer) or browser forwards the
request made by the user to the web server. The web server could be thought of as a big
storage space where all the web pages of the application are stored. It locates the pages
and examines the extension as if found; it forwards it to the ASP.Net engine which is
responsible for the execution of the code in the page. The code might request a database
operation which is done by the SQL Server. After completion of all the operations
requested by the user, a web pages is generated dynamically which might contain
confirmation of operation or some other information. The generated pages are presented
to the user. All the operations of the CRMS follow the cycle shown in the figure.

Chapter 4
Section 1: Used Cases
Actors
Customer
This actor represents an important role in the current system as it is the main user of the
system. There is constraint for operating the system i.e. the user must be registered to the
system. The customer should be a Mobilink customer to use the system. Almost all the
use cases are directly or indirectly initiated by this actor.
Administrator
This actor is the administrator of the system who has the privileges of modifying the data
in the main database of the system (company). The system on the whole could be
configured and modified as the administrator has all the knowledge necessary for those
operations.
1.1 USECASE DESCRIPTION
Used case no 1: Login
Basic Information
Actors: Administrator, Sub administrator and Customer.
Purpose: This use case is executed, when user wants to login.
Cross References: Nil
Feature: To login.
Typical Course of Events
1. The user presses the login link on the main page.
2. The system displays a login form.
3. The user enters his username and password and submits the form.
4. The system validates the user and if validated it gives him access to website.
Alternate Course of Events
4. The data entered for sub admin is invalid. The system prompts the user invalid
username/Password.

Used case no 2: Log off

Basic Information
Actors: Administrator, Sub administrator and Customer.
Purpose: This use case is executed, when user wants to logoff.
Feature: To log off.
1. The user presses the log off link on the main page.
2. The system displays a log off form with the message logged off.
Used case no 3: Create Sub administrator
Basic Information
Actors: Administrator.
Purpose: This use case is executed, when user wants to create sub administrator.
Feature: To create sub administrator.
1. The user presses the create sub admin link on the main page.
2. The system displays add sub-administrator form.
3. The user enters the sub administrator information and submits the form.
4. The system gives a prompt sub-administrator created and saves the data.
3. The data entered for sub-administrator is invalid. The system prompts the user to fill
again.
4. The data could not be saved in the database due to a run time error. The system will
then perform error handling routines.
Used case no 4: Add Bills
Basic Information
Actors: Administrator and sub administrator.
Purpose: This use case is executed, when user adds bill against billing request
of customers.
Feature: To add bills.
1. The user presses the add bills link on the main page.
2. The system displays a form showing person’s name that has send request to pay bill
online.
3. The user enters the billing information about the customer and submits the form.
4. The system saves the information.


3. The data entered for sub admin is invalid. The system prompts the user to fill again.
Used case no 5: Add Connections
Basic Information
Purpose: This use case is executed, when user add connections in the items list.
Feature: To add connections.
1. The user presses the add connections link on the main page.
2. The system displays a form showing connection type and serial number.
3. The user enters the serial number and submits the form.
4. The system saves the information and prompts connection added.
3. The data entered for sub admin is invalid. The system prompts the user to fill again.
Used case no 6: Block request
Basic Information
Purpose: This use case is executed, when user wants to see the block sim
requests in the items list.
Feature: To block sim.
1. The user presses the block sim request link on the main page.
2. The system displays a form showing number of all unblock connections, customers
username and sim status along with a search text box.
3. The user views the customer profile, his sim status through search or in sequence and
presses the block sim button.
4. The system saves the information and blocks the user sim and reduces the number of
blocked Sims.

Used case no 7: View customer profile
Basic Information
Purpose: This use case is executed, when user wants to view customer profile.
Feature: To view customer profile.
1. The user presses the view customer profile link on the main page.
2. The system displays a form showing a search bar.
3. The user searches the customer.
4. Then the system shows selected customer’s profile.
Nil
Used case no 8: View feedback
Basic Information
Purpose: This use case is executed, when user wants to view feedback.
Feature: To view feedback.
1. The user presses the view feedback link on the main page.
2. The system displays a form showing customer’s feedback along with the number of
feed backs pending.
3. The user will view the feedback
4. System will remove the feedback from the list on form.
Used case no 9: Online payment request
Basic Information
Purpose: This use case is executed, when user wants to view and process
online payment requests.


Feature: To check online request for billing.
1. The user presses the online payment request link on the main page.
2. The system displays a form showing a customer name along with the type of billing
and a list of pending requests.
3. The user will view customer profile and press the button, add to online.
4. System will save the information in the database and the will remove the customer
form the list.
Used case no 10: International roaming
Basic Information
Purpose: This use case is executed, when user wants to view and process
roaming requests.
Feature: To check roaming.
1. The user presses the international roaming link on the main page.
2. The system displays a form showing a customer name along with the number of
roaming requests.
3. The user will view information and then press the commit button
4. System will save the information in the database and will switch on international
roaming for the customer.
Used case no 11: Update Profile
Basic Information
Actors: Administrator and sub-administrator.
Purpose: This use case is executed, when user wants to update his profile.
Feature: To update profile.
1. The user presses the update profile link on the main page.

2. The system displays a form containing user profile without the password field.
3. The user views his profile and presses the update profile button.
4. The system displays a form the user updates the profile and presses the save button.

3. If the customer profile does not match then the customer either updates his profile or
contacts the main office.
Used case no 12: Change password
Basic Information
Actors: Administrator and sub-administrator.
Purpose: This use case is executed, when user wants to change password.
Feature: To change password.
1. The user presses the change password link on the main page.
2. The system displays a form containing with fields old password, new password and
confirm new password.
3. The user enters his password detail and presses submit button.
4. The system saves this information is user’s profile and prompts the user password
changed.

3. If old and new password are not validated than user is prompted to fill again.
Used case no 13: View Query
Basic Information
Purpose: This use case is executed, when user wants to view query.
Feature: To view query.


1. The user presses the view query link on the main page.
2. The system displays a form showing customer’s query along with the number of
queries pending.
3. The user will view the query.
4. System will remove the query from the list on form.
Used case no 14: Pay Bills
Basic Information
Actors: Customer
Purpose: This use case is executed, when user wants to pay his bills online.
Feature: To pay bill.

1. The user presses the pay bill link on the main page.
2. The system displays a form showing billing information and card validation panel.
3. The user views billing information and adds his card details.
4. The system checks for validation of card if validated, bill is paid and information is
saved.

3. The data entered for validation is invalid. The system prompts the user to fill again.
Used case no 15: Query
Basic Information
Actors: Customer
Purpose: This use case is executed, when user wants some information from
the system.
Feature: To ask query.
1. The user presses the query link on the main page.

2. The system displays a form containing space for query.

3. The user writes the query and submits it.
4. The system checks for validation of data and prompts the validation results. If
validated, the data is stored.

Used case no 16: Purchase Connection
Basic Information
Actors: Customer
Purpose: This use case is executed, when user wants to purchase a new
connection.
Feature: To purchase connection.

1. The user presses the purchase connection link on the main page.
2. The system displays a form containing results for available connections.
3. The user presses the proceed button.
4. The system displays the user profile and his references with the send request button.
5. User enters references and presses the request button.
6. Card validation window opens and user enters card information, card is verified and
customer gets the serial number.
3. The proceed button is enabled if connections are available and disabled if no
connections are available in case of former the user cannot buy and connections online.
6. If for some reason card is not verified the user is not allowed to purchase connection
online.
Used case no 17: Feed back
Basic Information
Actors: Customer
Purpose: This use case is executed, when user gives some feed back about the
system.

Feature: To give feed back.

1. The user presses the feed back link on the main page.
2. The system displays a form containing a space for feed back.
3. The user fills that space and submits it.
4. The system checks for validation of data and prompts the validation results. If
validated, the data is stored.

Used case no 18: International Roaming
Basic Information
Actors: Customer
Purpose: This use case is executed, when user wants to open roaming on his
account.
Feature: To open roaming.
1. The user presses the international roaming link on the main page.
2. The system displays a form containing customer profile and a send request button.
3. The user views his profile and presses the send request button.
4. The system prompts the user request send.

Used case no 19: Block Connection
Basic Information
Actors: Customer
Purpose: This use case is executed, when user wants to block his sim.
Feature: To block sim.

1. The user presses the block connection link on the main page.
2. The system displays a form containing customer profile and his number.
3. The user views his profile and presses the send request button.
4. The system prompts the user your connection has been blocked.

Used case no 20: Update Customer Profile
Basic Information
Actors: Customer
Purpose: This use case is executed, when user wants to update his profile.
Feature: To update customer profile.
1. The user presses the update profile link on the main page.
2. The system displays a form containing customer profile without the password field.
3. The user views his profile, updates profile and presses the submit button.
4. The system prompts the user your record has been updated successfully.

Used case no 21: Request for online Payment

Basic Information
Actors: Customer
Purpose: This use case is executed, when user wants to pay his/her bills online.
Feature: Request for online payment.
1. The user presses the Request Online payment link on the main page.
2. The system displays a form containing customer profile with his phone number.
3. The user views his profile and presses submit button.
4. The system prompts the user your billing is online now.

Used case no 22: Change password
Basic Information
Actors: Customer.
Purpose: This use case is executed, when user wants to change password.
Feature: To change password.
1. The user presses the change password link on the main page.
2. The system displays a form containing with fields old password, new password and
confirm new password.
3. The user enters his password detail and presses submit button.
4. The system saves this information is user’s profile and prompts the user password
changed.
3. If old and new password are not validated than user is prompted to fill again.
Used case no 23: Register User
Basic Information
Actors: Customer
Purpose: This use case is executed when a new user (customer) wants to operate
the system for the first time, to register new users.
Feature: To register user.

1. The user presses the register user link on the main site.
2. The system displays a registration form.
3. The user fills and submits the form to the system.
4. The system checks for validation of data. If validated, the data is stored.

Used case no 24: View Connections Information
Basic Information
Purpose: This use case is executed, when user wants to view connections
information.
Feature: To view connections information.
1. The user presses the connections information link on the main page.
2. The system displays a form showing all the connections that are available and that
have been sold.
2. The data could not be retrieved from the database due to a run time error. The system
will then perform error handling routines.
Used case no 25: Payments Information
Basic Information
Purpose: This use case is executed, when user wants to view payments information.
Feature: To view payments information.
1. The user presses the payments information link on the main page.
2. The system displays a form showing information of all the transactions made i.e. bills
paid or connections sold.
2. The data could not be retrieved from the database due to a run time error. The system
will then perform error handling routines.

1.2 Elaborated Used Cases
Login
Use case reference UC_ADMIN_CUST_01
Pre-condition 1. User must be connected to internet
2. User must know website URL.
Step Action Software Reaction
#
1. The user presses the login link 2. The system displays a login form.
on the main page.
3. The user enters his username 4. The system validates the user and if
and password and submits the validated it gives him access to
form. website.
4 a. The data entered for sub admin is invalid. The system prompts the user
invalid Username/Password.
Scenario Notes
This used case is executed when user wants to use the services provided by the
website or wants to handle customer’s requests so he/she logs in the system,
user enters his login and password and if authenticated by the system the user is
allowed to enter the website.
Post Conditions
Step Description
#

Log off
Use case reference UC_ADMIN_CUST_02
Pre-condition 1. User must be connected to internet.
2. User must be logged in.
#
1. The user presses the log off 2. The system displays a log off form
link on the main page. with the message logged off.
.
Scenario Notes
This used case is executed when user wants to stop using the services provided
by the site or when he/she us done using the system. The user presses the log
off link on the man page and his connection is blocked from the site he cannot
interact with the site any more.
Post Conditions
Step Description
#
1. User cannot access or interact with the website through the last
password.

Create Sub-administrator
Use case reference UC_ADMIN_03
3. User must be administrator.
#
1. The user presses the get sub- 2. The system displays a sub-
administrator link on the main administrator form with empty fields
page. and a submit button.
3. The user enters the sub 4. The system saves the data in
administrator information and database with status as sub
submits the form. administrator.
3 a. The data entered for sub-administrator is invalid. The system prompts the
user to fill again.
4 a. The data could not be saved in the database due to a run time error. The
system will then perform error handling routines.
Scenario Notes
This used case is executed when user wants too create sub-administrator who
can perform all the functions of the administrator except creating sub-
administrator the user presses the create sub-admin link on the main page the
user enters the sub-administrator information and submits the form, the request
is processed by the system and a sub-administrator is created.
Post Conditions
Step Description
#
1. The system gives a prompt sub-administrator created

Add Bills
3. User must be administrator or sub administrator.
#
1. The user presses the get add 2. The system displays a form
bills link on the main page. showing person’s name who has send
request to pay bill online and an add
bill button at the bottom.
3. The user enters the 4. The system saves the information.
information about the
customer and presses the add
bill button.
3 a. The data entered for sub admin is invalid. The system prompts the user to
fill again.
Scenario Notes
This used case is executed when user wants to add bills of customers in order to
process their requests to pay bills the user presses the add bill link on the main
page system show the customer name and submits the form the user also enters
the customer information. This request goes to the system and if there is no
problem the bill is added.
Post Conditions
Step Description
#

Add Connections
#
1. The user presses the add 2. The system displays a form
connections link on the main showing connection type and serial
page. number.
3. The user enters the serial 4. The system saves the information.
number and submits the form.
3 a. The data entered for sub admin is invalid. The system prompts the user to
fill again.
Scenario Notes
This used case is executed when user wants to add connections in the inventory
list, the user presses the add connections link on the main page and enters the
serial number the system saves this information in the database and a
connection is added.
Post Conditions
Step Description
#
1. The system prompts the user connection added.

Block request
#
1. The user presses the block sim 2. The system displays a form
request link on the main page. showing number of all unblock
connections, customers username and
sim status along with a search text
box.
3. The user views the customer 4. The system saves the information
profile, his sim status through and blocks the user sim.
search or in sequence and
presses the block sim button.
Scenario Notes
This used case is executed when user wants to block some ones sim the user
enters the block connections link on the main page the system shows the
unblock connections and sim status the user blocks the connection in sequence
or by searching a specific customer.
Post Conditions
Step Description
#
1. The system reduces the number of blocked sims and removes the record
from the form.

View profile
#
1. The user presses the view 2. The system displays a form
customer profile link on the showing a search bar.
main page.
3. The user searches the customer 4. Then the system shows selected
by using either his user name, customer’s profile.
first name or through his
mobile number.
Scenario Notes
This used case is executed when user wants to view profile of some customer
the user presses the view profile link on the main page the system shows a
search bar to search for certain customer, the system shows the customer
profile.
Post Conditions
Step Description
#

View Feedback
#
feedback link on the main showing customer’s feedback along
page. with the number of feed backs
pending.
3. The user will view the 4. System will remove the feedback
feedback from the list on form.
Scenario Notes
This used case is executed when user wants to view feedback of some customer
this system show the feedbacks pending the user views the feedbacks and the
system removes that particular feedback from the list that has been seen by the
administrator.
Post Conditions

Online payment request

#
1. The user presses the online 2. The system displays a form
payment request link on the showing a customer name along with
main page. the type of billing and a list of pending
requests.
3. The user will view customer 4. System will save the information in
profile and press the button, the database and the will remove the
add to online. customer form the list.
Scenario Notes
This used case is executed when user wants to view and process on line
payment requests the user presses the online payment request link on the man
page the system shows the number of pending requests the user either views the
customer profiles or presses the add to online link which changes the status to
online request from seen to unseen and the information is stored in database.
Post Conditions
Step Description
#
1. Form now onwards the billing of the customer will be online.

International roaming
#
1. The user presses the 2. The system displays a form
international roaming link on showing a customer name along with
the main page. the number of roaming requests.
3. The user will view information 4. System will save the information in
and then press the commit the database and will switch on
button international roaming for the
customer.
Scenario Notes
This used case is executed when user wants to view and process roaming
requests by customers the user presses the international roaming request link on
the main page the system shows the number of pending requests, the user start
viewing the requests and will also switch their international roaming on if there
is no problem with the customer information.
Post Conditions
Step Description
#
1. From now onwards international roaming will be on for the customer.

Update Customer Profile

#
1. The user presses the update 2 The system displays a form
profile link on the main page. containing user profile without the
password field.
3. The user views his profile 4 The system displays a form the user
there are two buttons at the updates the profile and presses the
bottom of the form save and save button which is enabled now.
update, save is disabled at the
beginning but update is
enabled so the user first
presses the update profile
button.
3 a. If the customer profile does not match then the customer either updates
his profile or contacts the main office.
Scenario Notes
This used case is executed when user wants to update his profile, the user
presses the update profile link on the main page he/she views its profile and
updates it and submits it which is saved over his/her previous profile.
Post Conditions
Step Description
#

Change password
#
1. The user presses the change 2. The system displays a form
password link on the main containing with fields old password,
page. new password and confirm new
password.
3. The user enters his password 4. The system saves this information
detail and presses submit is user’s profile.
button.
3 a. If old and new password are not validated than user is prompted to fill
again.
Scenario Notes
This used case us executed when user wants to change his/her password the
user presses the change password link on the main page the system displays
him a form a form the user enters his password information which if
validated, his profile is changed with the new password .
Post Conditions
Step Description
#
1. The system prompts the user password changed.

View Query
#
query link on the main page. showing customer’s query along with
the number of queries pending.
3. The user will view the query. 4. System will remove the query from
the list on form.
Scenario Notes
This used case is executed when user wants to view feedback of some customer
this system show the feedbacks pending the user views the feedbacks and the
system removes that particular feedback from the list that has been seen by the
administrator.
Post Conditions
Step Description
#
1. Query replied through the system.

Pay Bills
Use case reference UC_CUST_14
2. User must know website URL
4. User must have pending bills.
5. User already has sent the request to pay online.
#
1. The user presses the pay bill 2. The system displays a form
link on the main page. showing billing information and a
card validation panel at the bottom.
3. The user views billing 4. The system checks for validation of

information about his pending card if validated from bank, bill is
bills and adds his card details paid and information is saved.
in the bottom panel and
submits it.
3 a. The data entered for validation is invalid. The system prompts the user to
fill again.
Scenario Notes
This used case is executed when user wants to pay his pending bills online.
They user presses the pay bill link on the user main, the system shows him his
pending bills he adds his credit card details the system verifies his card and if
the card is verified his bill is paid online.
Post Conditions
Step Description
#
1. The system displays the prompt bill paid.
2. Next time when customer logs in his pending bills column is empty.

Query
3. User must be longed in.
#
1. The user presses the query link 2. The system displays a form
on the main page. containing space for query.
3. The user writes the query and 4. The system checks for validation of
presses the submit button at data and saves the information in the
the bottom of the page. database.
fill again.
Scenario Notes
This use case is executed, when user wants some information from the system.
User writes the query on the query window and sends it through the website to
the CRMS system where his query is studied and replied later.
Post Conditions
Step Description
#
1. The system prompts the user query send.

Purchase Connection
#
1. The user presses the purchase 2. The system displays a form
connection link on the main containing the status of connections,
page. with a proceed button at the bottom.
3. The user presses the proceed 4. The system displays the user profile
button. loaded from customer table and his
references. Their is a send request
button at the bottom of the form..
5. User enters references and 6. Card validation window opens and

presses the request button. user enters card information, card is
verified and customer gets the serial
number.
3 a. The proceed button is enabled if connections are available and disabled if

no connections are available in case of former the user cannot buy and
connections online.
Scenario Notes
This used case is executed when user wants to by his connection online. The
user presses purchase connection link on the purchase connection page, the
system displays him the availability of connections the user enters his
references and card information which is verified form the system and if valid
he gets a serial number which he can take to the nearest branch of mobilink to
get his connection.
Post Conditions
Step Description
#
1. The must take the serial number allotted to him to the nearest branch of
mobilink to get connection.

Feed back
#
1. The user presses the feed back 2. The system displays a form
link on the main page. containing a space for feed back.
3. User fills that space and 4. The system checks for validation of
submits it. data and stores the data.
fill again.
Scenario Notes
This user case is executed when user wants to give some feedback about the
system or about its some feature. The user presses feedback link on the main
page he/she enters its feedback which is send to CRMS centre for further
processing and is used to make system more useful and user friendly.
Post Conditions
Step Description
#
1. They system prompts the user feedback send.

International Roaming
#
1. The user presses the 2. The system displays a form
international roaming link on containing customer profile and a
the main page. send request button.
3. The user views his profile and 4. The system switches on roaming
if there is no problem in it on requested.
he/she presses the send
request button.
Scenario Notes
This used case is executed when user wants to switch on his international
roaming through internet, the user presses the international roaming link on
the main page he/she views its profile and sends request which is processed
by the system and it there is no problem roaming is switched on for the
particular customer.
Post Conditions
Step Description
#
1. The system prompts the user request send.

Block Connection
#
1. The user presses the block 2. The system displays a form
connection link on the main containing customer profile and his
page. number.
3. The user views his profile and

if there is no problem in it and
customer wants to block the
same number as displayed on
the screen then he presses the
send request button.
3 a. If the customer profile does not match and the number displayed is not the
same as the one he wants to block then the customer either updates his profile
or contacts the main office.
Scenario Notes
This used case is executed when customer wants to block his connection
online, the user presses the block connection link on the main page he/she
views its profile and mobile number and if the profile is ok and the number is
the same as the customer wants to block then he sends the request which is
processed by the system and if there is no problem his sim is blocked.
Post Conditions
Step Description
#
1. The system prompts the user your connection has been blocked.

Update Customer Profile

4. User must have current profile.
#
1. The user presses the update 2 The system displays a form
profile link on the main page. containing customer profile without
the password field.
3. The user views his profile,

updates profile and presses
the submit button.
Scenario Notes
This used case is executed when user wants to update his profile, the customer
presses the update customer profile link on the main page he/she views its
profile and updates it and submits it which is saved over customer’s old
profile.
Post Conditions
Step Description
#
1. The system prompts the user your record has been updated
successfully.

Request for online Payment

#
1. The user presses the Request 2. The system displays a form
Online payment link on the containing customer profile with his
main page. mobile number.
3. The user views his profile and

presses submit button.
Scenario Notes
This used case is executed when user wants to convert his billing to online
from offline, user presses the request for online payment link on the main page
system shows the customer his/her profile and mobile number if the
information is correct the user submits it this request is processed by the
system and if there is no problem the billing of customer is switched from
offline to online.
Post Conditions
Step Description
#
1. The system prompts the user your billing is online now.

Change password
#
1. The user presses the change 2. The system displays a form
password link on the main containing with fields old password,
page. new password and confirm new
password.
3. The user enters his password 4. The system saves this information
detail and presses submit is user’s profile.
button.
3 a. If old and new password are not validated than user is prompted to fill
again.
Scenario Notes
This used case us executed when user wants to change his/her password the
user presses the change password link on the main page the system displays
him a form a form the user enters his password information which if validated,
his profile is changed with the new password .
Post Conditions
Step Description
#
1. The system prompts the user password changed.

Register User
#
1. The user presses the register The system displays a registration
user link on the main site. form.
2. The user fills and submits the The system checks for validation of
form to the system. data and prompts the validation
results. If validated, the data is stored
in the database.
fill again.
Scenario Notes
This used case is executed when user want to register him/her self for the first
time the user presses the register user link on the main site, system opens a
form user fills the form and submit if the information has no problem the user is
given his/password and username.
Post Conditions
Step Description
#
The customer is prompted with his user name and password.

View Connections Information

Step# Action Software Reaction
1. The user presses the 2. The system searches for the
connections information link connections information and displays
on the main page. it to the user.
2 a. The data could not be retrieved from the database due to a run time error.
The system will then perform error handling routines.
Scenario Notes
This used case is executed when user wants to view connections information,
the user presses the connections information link on the main page the system
displays complete information about all the connections sold and available in
the inventory list.
Post Conditions
Step# Description
1. The system either displays the connections information or gives the
prompt no connections available or sold.

Payments Information
Step# Action Software Reaction
1. The user presses the payments 2. The system displays a form showing
information link on the main information of all the
page. transactions made i.e. bills
paid or connections sold.
2 a. The data could not be retrieved from the database due to a run time error.
The system will then perform error handling routines.
Scenario Notes
This used case is executed when user wants to view payments information, the
user presses the payments information link on the main page the system
displays complete information about all the payments made i.e. bills paid or
connections sold.
Post Conditions
Step# Description
1. The system either displays the payments information or gives the
prompt no payments made.

Section 2: Sequence Diagrams
2. 1 Sequence Diagrams
These diagrams intends to show the interactions between different objects, which exist
within the system. The interactions are shown as messages sent and received between
objects. These messages cater all types of communications for example procedure calls,
events, signals between flows of execution and hardware interrupts. As the system would
be developed using OOSE which is a use case driven approach, so all the diagrams would
be developed in correspondence to the use cases which showed the functionality of the
system and proved to be very helpful in identifying different objects along with their
interactions. These diagrams show the structure of the system and the flow of execution
which results in completion a process.

ADD BILLS
UC_ADMIN_04

ADD CONNECTIONS
UC_ADMIN_05

BLOCK CONNECTION
UC_ADMIN_06

CHECK FEEDBACK
UC_ADMIN_08

CREATE SUB-ADMIN
UC_ADMIN_03

INTERNATIONAL ROAMING
UC_ADMIN_10

LOGIN
UC_ADMIN_CUST_01

LOGOFF
UC_ADMIN_CUST_02

ONLINE BILLING
UC_ADMIN_09

PASSWORDCHANGE
UC_ADMIN_12

UPDATE PROFILE
UC_ADMIN_11

VIEW PROFILE
UC_ADMIN_07

VIEW QUERY
UC_ADMIN_13

VIEW CONNECTION INFORMATION

UC_ADMIN_24

VIEW PAYMENT INFORMATION

UC_ADMIN_25

REQUEST TO BLOCK CONNECTION

UC_CUST_19

FEEDBACK
UC_CUST_17

UC_CUST_18

LOGOFF
UC_ADMIN_CUST_02

ONLINE PAYMENT
UC_CUST_14

CHANGE PASSWORD
UC_CUST_22

PURCHASE CONNECTION
UC_CUST_16

QUERY
UC_CUST_15

UPDATE CUSTOMER PROFILE

UC_CUST_20

RREGISTER USER
UC_CUST_23

Section 3: Class Diagrams
BLOCK CONNECTION
UC_CUST_19

CHANGE PASSWORD
UC_CUST_22

EDIT PROFILE
UC_CUST_20

FEEDBACK
UC_CUST_17

UC_CUST_18

LOG OFF
UC_ADMIN_CUST_02

PURCHASE CONNECTIOHN
UC_CUST_16

QUERY
UC_CUST_15

REGISTER USER
UC_CUST_23

REQUEST TO PAY BILL

UC_CUST_21

ADD BILLS
UC_ADMIN_04

ADD CONNECTIONS
UC_ADMIN_05

BLOCK CONNECTIONS
UC_ADMIN_06

CHANGE PASSWORD
UC_ADMIN_12

CREATE SUB-ADMIN
UC_ADMIN_03

UC_ADMIN_10

LOG IN
UC_ADMIN_CUST_01

LOG OFF
UC_ADMIN_CUST_02
Controller Administrator/Sub-administrator
+logoffrequest()
+logingoff()
GUI
LogoffGUI
+requesttologoff()
+createlogoffGUI()

ONLINE BILLING
UC_ADMIN_09

UPDATE PROFILE
UC_ADMIN_11

CONNECTION INFORMATION
UC_ADMIN_24

VIEW FEEDBACK
UC_ADMIN_08

PAYMENT INFORMATION
UC_ADMIN_25
Database Administrator/Sub-administrator
+searchrequest()
+searching()
GUI
PaymentsinformationGUI
+requesttoviewpaymentinformation()
+createpaymentsinformationGUI()

VIEW PROFILE
UC_ADMIN_07
Database Administrator/Sub-administrator
+searchrequest()
+searching()
CustomerprofileGUI GUI
+createcustomerprofileGUI() +requesttoviewprofile()
+userinformation()
+performvalidation()

VIEW QUERY
UC_ADMIN_13

Section 4: Traceability matrix
Sr. Feature Use case ID UI ID Priority Use Case Cross

# reference
(Related Use
Cases)
UC_ADMIN_CUST_01 UI_CUST_02 1 None
UI_CUST_03
UI_ADMIN_01
To login.
1 UI_ADMIN_02
UC_ADMIN_CUST_02 UI_CUST_15 1 None
To log off.
2 UI_ADMIN_14
To create sub UC_ADMIN_03 1 None
3 administrator. UI_ADMIN_05
To add bills. UC_ADMIN_04 1 None
4 UI_ADMIN_04
To add UC_ADMIN_05 1 None
connections.
5 UI_ADMIN_03
To view and UC_ADMIN_06 1 None
process block sim
requests.
6 UI_ADMIN_06
UC_ADMIN_07 1 None
To view customer
profile.
7 UI_ADMIN_11
To view feedback. UC_ADMIN_08 1 None
8 UI_ADMIN_09
To check online UC_ADMIN_09 1 None
request for billing.
9 UI_ADMIN_07
To check and UC_ADMIN_10 1 None
process roaming.
10 UI_ADMIN_08

To update profile. UC_ADMIN_11 1 None

11 UI_ADMIN_12
To change UC_ADMIN_12 1 None
password.
12 UI_ADMIN_13
To view query. UC_ADMIN_13 1 None
13 UI_ADMIN_10
To pay bill. UC_CUST_14 1 None
14 UI_CUST_04
To ask query. UC_CUST_15 1 None
15 UI_CUST_08
UC_CUST_16 UI_CUST_05 1 None
To purchase
connection. UI_CUST_06
16 UI_CUST_07
To give feed back. UC_CUST_17 1 None
17 UI_CUST_09
To open roaming. UC_CUST_18 1 None
18 UI_CUST_12
To block sim. UC_CUST_19 1 None
19 UI_CUST_11
To update UC_CUST_20 1 None
customer profile.
20 UI_CUST_13
Request for online UC_CUST_21 1 None
payment.
21 UI_CUST_10
To change UC_CUST_22 1 None
password.
22 UI_CUST_14
Register new user. UC_CUST_23 1 None
23 UI_CUST_01
View connections UC_ADMIN_24 1 None
information.
24 UI_ADMIN_16
View payments UC_ADMIN_25 1 None
25 UI_ADMIN_15
information.

Chapter 5
Section 1: GUI
1. 1 Interface Design
The interface of the CRMS required much attention during the development of the
system because a large number of users intend to use the system and user friendliness
guarantees the success of the system. The interface is kept simple so that any user with
any background (computer literate/illiterate) can easily complete the anticipated task. The
use of animations is ignored as it might be confusing for some users and also not much
pictures are used because they might take time be loaded on a slow internet speed. A
common approach is used to maintain the consistency through out the system. The
system uses a three frame page. In the upper frame, the company’s banner, in the left
page navigational bar and the lower frame is used to display different pages as requested
through the navigational bar. The interface is developed according to some of the user
requirements and by storyboarding.
The user enters his/her username and password, if the login is succeeded; the customer is
taken to the index page of customers. This page shows the customer all the operations
he/she could do with links to particular pages.
The pages relating to different operations that could be performed by the system also
follow a common format i.e. firstly a heading at the top which describes intend of the
page immediately followed by some description of the task.
1.1.1 HCI and the process

Human-computer interaction is a discipline concerned with the design, evaluation and
implementation of interactive computing systems for human use and with the study of
major phenomena surrounding them.
As it is quite clear just by looking at the word HCI that it deals with the principles and
techniques that a web designer follows in order to design a structure of a web application
that would ease the use of application for the user. Particularly in web applications where
commonly there are a large number of users, HCI plays a vital role to facilitate a design
effective enough to cater the needs of its users.

Login
Interface No. UI_ADMIN_01
Use case Reference UC_ADMIN_CUST_01
Snapshot

Home
Snapshot

Add Connection
Use case Reference UC_ADMIN_05
Snapshot

Add Bill
Snapshot

Add Sub-Administrator
Snapshot

Block sim Requests

Snapshot

Online Bill Payment Requests

Snapshot

Roaming Requests
Snapshot

Check Feedback Requests

Snapshot

View Queries
Snapshot

View Customer Profile

Snapshot

View Payments
Snapshot

View Connection Information

Snapshot

Update Profile
Snapshot

Change Password
Snapshot

Logoff
Snapshot

Register User
Interface No. UI_CUST_01
Use case Reference UC_CUST_23
Snapshot

Login
Snapshot

Home
Snapshot

Pay Bill
Snapshot

Connection Status
Snapshot

Application Form
Snapshot

Credit Card Verification

Snapshot

Query
Snapshot

Feedback
Snapshot

Request for Online Bill Payment

Snapshot

Block Sim
Snapshot

International Roaming
Snapshot

Update Profile
Snapshot

Change Password
Snapshot

Logoff
Snapshot

Section 2: Mockups
Static text
Form name Text Field
Button

Header Image Site Title
Administrator Links Main Frame

Header Image Site Title
Customer Links Main Frame

Section 3: Data Dictionary
<1.0 adlogin info>

Name Adid, username, password, status
Alias N/a
Where and how used Adlogin
Content adlogin= adid+ username+ password+ Info
1)adid= integer(4)
2)username= varchar (50)
3)password= varchar (50)
4)status = varchar (50)
Supplementary information 1) Adid is auto generated and has a length of 4.

2) Initially the field is empty .Administrator can put his or
her username is this field and it is of length 50.
3) Initially the field is empty .Administrator can put his or
her password is this field and it is of length 50.
4) Whether administrator is online or offline and it is of
length 50
<2.0 adminprofile Info>

Name Uname, psd, fname, lname, nic, address, tel, mob, email,
age, sex, state, country
Alias N/a
Where and how used Adminprofile
Content Adminprofile Info = UName + Psd + Fname + Lname+
Nic + Address + tel + mob + Email + Age + Sex + state +
Country + status
1)UName = Varchar(50)
2)Psd = Varchar(50)
3)Fname = Varchar(50)
4)Lname = Varchar(50)
5)Nic = Varchar(50)
6)Address = Varchar(50)
7)Tel = Varchar(50)
8)Mob = Varchar(50)
9)Email = Varchar(50)
10)Age = Varchar(50)
11)Sex = Varchar(50)
12)State = Varchar(50)

13)Country = Varchar(50)
14)Status = Varchar(50)
Supplementary information 1. Initially the field is empty. It takes the username of
an administrator and it has a length of 50
2. Initially the field is empty. It stores the
administrator password and has a length of 50
3. Initially the field is empty It stores the
administrator first name and it has a length of 50
administrator last name and it has a length of 50
administrator nic number in this field and has a
length of 50
administrator address in this field and has a length
of 50.
administrator telephone number and it has a length
50.
administrator mobile number and it has a length
50.
administrator email and it has a length 50.
administrator age and it has a length 50.
administrator sex and it has a length 50.
administrator state name and it has a length 50.
13. Either he is administrator or sub administrator and
it has a length of 50.

<3.0 bills info>

Name Obid, username, mob, status, billingmonth, duedate,
amtbdd, amtadd
Alias N/a
Where and how used Bills info
Content bills info = obid + username + mob + status +
billingmonth + amtbdd + amtadd
1) obid = int(4)
2) username = varchar(50)
3)mob = varchar(50)
4) status = varchar(50)
5) billingmonth = varchar(50)
6) duedate = varchar (50)
7) amtbdd = varchar(50)
8) amtadd = varchar (50)
Supplementary information 1) Auto generated and has a length of 4.
2) This attribute caries username of the customer and
is has a length of 50.
3) This attribute caries mobile number of customer
and it has a length of 50.
4) Whether customer had paid his bill or not and it
has a length of 50.
5) User can view his billing month and administrator
can change his billing month and it has a size of
50.
6) In the field due date is filled by the administrator
and is viewed by the user and is of length 50.
7) In this filed amount before due date is view by user
and it is changed by the administrator and it has a
size of 50.
8) In this filed amount before due date is view by user
and it is changed by the administrator and it has a
size of 50.

<4.0 block info>

Name Olid, uname, status
Alias N/a
Where and how used Block
Content Block info = olid + uname + status
1) Olid = integer(4)
2) Uname = varchar(50)
3) Status = varchar(50)
2) This attribute carries user name of the customer
and is viewed by the customer. It has a length of
50.
3) Administrator can block the sim of customer and it
has a length of 50
<5.0 custprofile Info>

Name Uname, psd, fname, lname, nic, address, tel, mob, email,
age, sex, occupation, state, country, franchise
Alias N/a
Where and how used Adminprofile
Content Adminprofile Info = UName + Psd + Fname + Lname+
Nic + Address + tel + mob + Email + Age + Sex +
occupation + state + Country + franchise
1)UName = Varchar(50)
2)Psd = Varchar(50)
3)Fname = Varchar(50)
4)Lname = Varchar(50)
5)Nic = Varchar(50)
6)Address = Varchar(50)
7)Tel = Varchar(50)
8)Mob = Varchar(50)
9)Email = Varchar(50)
10)Age = Varchar(50)
11)Sex = Varchar(50)
12)occupation=varchar(50)
13)State = Varchar(50)
14)Country = Varchar(50)
15)Status = Varchar(50)
16)franchise = varchar(50)
Supplementary information 1) Initially the field is empty. It takes the username of a
customer and it has a length of 50

2) Initially the field is empty. It stores the customer

password and has a length of 50
3)Initially the field is empty It stores the customer first
name and it has a length of 50
4) Initially the field is empty. It stores the customer last
name and it has a length of 50
5) Initially the field is empty. It stores the customer nic
number in this field and has a length of 50
address in this field and has a length of 50.
telephone number and it has a length 50.
mobile number and it has a length 50.
9) Initially the field is empty. It stores the customer email
and it has a length 50.
10) Initially the field is empty. It stores the customer age
11) Initially the field is empty. It stores the customer sex
occupation and it has a length 50.
13) Initially the field is empty. It stores the administrator
state name and it has a length 50.
14) Either he is administrator or sub administrator or it has
a length of 50.
15) Initially the field is empty. It stores the
administrator country name and it has a length 50.
franchise name from where he or she purchases the
connection and it has a length 50.

<6.0 fback info>

Name Fbid, uname, fback, status
Alias N/a
Where and how used Fback
Content Fback info=fbid + uname + fback+ status
1) Fbid = integer(4)
2) Uname = char(50)
3)Fback = varchar(999)
4)Status = char(10)
2) This attribute carries username of the customer and
is viewed by the administrator and it has a length
of 50.
3) Customer can give feed back and administrator can
view that feedback and it has a length of 999.
4) Check whether administrator have viewed the
feekback or not and is of length 10.
<7.0 items info>

Name Conid, conntype, aduser, serial, connstatus, cusuer
Alias N/a
Where and how used Items
Content 1) conid =int(4)
2) conntype=varchar(20)
3) aduser = varcahr(10)
4) serial = varchar(10)
5) connstatus = varchar(50)
6) cususer = varchar(50)
Supplementary information 1) It is auto generated and it has a of length 4.
2) Connection type is entered in this field whether it
is post paid or pre paid and it is of length 20.
3) This attribute carries administrator name of the
user and is viewed only by administration and it is
of length 10.
4) Serial number is entered in the field by the
administrator and it is of length 10.
5) Customer can check whether connection are
available or not and it is of length 50.
6) This attribute contain the customer user name and
it has a length of 50.

<8.0 login info >

Name Id, username, password, role
Alias N/a
Where and how used login
Content 1) Id = integer(4)
2) Username = varchar(15)
3) Password = varchar(15)
4) Role = char(15)
Supplementary information 1) It is auto generated and is of length 4.
2) Initially the field is empty. Customer can put
username in this field and it has of length 15.
3) Initially the field is empty. Customer can put her
password in this field and it is of length 15.
4) The role of the user is customer and is of length
15.
<9.0 online info>

Name Onid, uname
Alias N/a
Where and how used Online
Content 1) onid =integer(4)
2) uname = varchar(50)
3) status = varchar(15)
Supplementary information 1) It is auto generated of length 4.
2) This attribute carries the username and is viewed
by the cutomer and is of length 50.
3) It tells us whether its billing is online or offline
and it is of length 15.

<10.0 payment info>

Name Payid, username, holdername, cdtype, paytype, amount
Alias N/a
Where and how used payment
Content 1) Payid= integer(4)
2) Username = varchar(50)
3) Choldername = varchar(50)
4) Cdtype = varchar(50)
5) Paytype = varchar(50)
6) Amount = varchar(50)
2) This attribute carries user name of the customer.
And is of length 50.
3) Initially the field is empty. User can put credit card
holder name in this field and administrator can
view holder name and it is of length 50.
4) User can put credit card type and it is of length 50.
5) Initially the field is empty. Customer purchases the
connection or paid bill and is of length 50.
6) It is already filled and is of length 50.
<11.0 purchase info >

Name Pid, uname, refname, reflname, refadd, refnic, reftel
Alias N/a
Where and how used purchase
Content 1) Pid = integer(4)
3) Refname = varchar(50)
4) Reflname = varchar(50)
5) Refadd = varchar(50)
6) Refnic = varchar(50)
7) Reftel = varchar(50)
8)
2) This attribute carries the username of the customer
and it has a length of 50.
3) Initially the field is empty. Reference first name is
provided by the customer and is viewed by the
administrator and is of length 50.
4) Initially the field is empty. Reference last name is
provided by the customer and is of length 50.
5) Initially the field is empty. Reference address is

given by the customer and is viewed by

administrator and is of length 50.
6) Initially the field is empty. Reference nic is given
by the customer and is viewed by the user and is of
length 50.
7) Initially the field is empty. Customer can put her
reference telephone number and it is of length 50.
<12.0 query info>

Name Qid, uname, query, status
Alias N/a
Where and how used query
Content 1) Qid = integer(4)
2) Uname = char(50)
3) Query = varchar(300)
2) This attributes caries the username of the customer
and is viewed by the administrator. And is of
length 50.
3) Initially the field is empty. In this field query is
filled by the customer and administrator can view
this query and is of length 300.
4) Whether administrator had viewed customer query
or not and is of length 50.
<13.0 roam info>

Name Roamid, uname, status
Alias N/a
Where and how used It is auto generated
Content 1) Roamed = int(4)
2) User name is viewed by the customer and
administrator and it is of length 50.
3) The roaming status, as on or off and it is of length
50.

Chapter 6
Section 1: Testing
1.1 Introduction
The importance of software testing and its impact on software cannot be underestimated.
Software testing is a fundamental component of software quality assurance and
represents a review of specification, design and coding. The greater visibility of software
systems and the cost associated with software failure are motivating factors for planning,
through testing. In the process of testing, some routines are performed that intend to find
errors in the system. The detection of errors depends on the designing of test cases. A
good test case aims to find more errors.
The testing phase received two types of inputs (1) a software configuration; (2) a test
configuration. Tests were performed and all outcomes were considered. Test results were
compared with the expected results. When erroneous data is identified error is implied
and debugging begins. The debugging procedure is the most unpredictable element of
the testing procedure. The time span of debugging error correction can not be stated till
the end.
1. 2 Testing Strategy
The process of testing is distributed through out the development process. Test planning
is done and test cases are designed in the design phase. Testing proceeds with the
implementation phase where actual coding is in progress. Different code modules are
written which correspond to different function of CRMS. As each function is coded, their
respective testing routines (unit testing) are performed for identification and correction of
errors. After completing all the function, they are integrated together to work properly as
combined. This is where integration testing takes place. Then finally system testing is
started which involves testing of the software and other system elements. The test cases
are given in appendix P.
1. 3 Evaluation/Testing Methods
1. 3. 1 Unit Testing
Unit testing concentrates verification on the smallest element of the program i.e. the
module. Using the detailed design description important control paths are tested to
identify errors within the bounds of the module. Unit testing is an additional step with the
coding. Once code is written, reviewed and validated for syntax, unit test case design
starts. The information collected during the design phase help in defining efficient test
cases.
During unit testing, the module interface is tested to ensure that information properly
flows into and out of the program unit being tested. The local data structure is considered
to ensure that data stored temporarily maintains its integrity for all stages in an
algorithm’s execution. Boundary conditions (loops) are tested to ensure that the modules

perform correctly at boundaries created to limit or restrict processing. All independent

paths through the control structure are exercised to ensure that all statements are executed
once. Finally, all error-handling paths are examined.
1. 3. 2 Integration Testing
Once all the individual units have been tested there is a need to test how they were put
together to ensure no data is lost across interface, one module does not have an adverse
impact on another and a function is not performed correctly. Integration testing is a
systematic approach that produces the program structure while at the same time
producing tests to identify errors associated with interfacing.
1. 3. 3 System Testing
This type of testing is performed in the end. The CRMS includes the software and other
system elements so some system validation tests are performed. . System testing is a
series of different tests whose main aim is to fully exercise the CRMS. Although each test
has a different role, all work verifies that all system elements have been properly
integrated and form allocated functions.
1. 3. 4 Security Testing
Security was a crucial requirement identified during the analysis phase. CRMS needs
effective mechanism for enforcing of security and prevention of unauthorized access to
the system from the outside world (internet). During security testing, the tester plays the
role of the individual who wants to enter the system. The tester may try to get passwords
through external clerical approaches; may attack the system with customized software,
purposely produce errors and hope to find the key to system entry. If some fault is
identified, it is reported and corrected.
1. 3. 5 Stress Testing
Stress testing executes a system in the demands resources in abnormal quantity,
frequently or volume. This test checks the CRMS under abnormal condition to see that
the system functions properly.
1. 3. 6 Data Validation Testing

This test was conducted throughout the development and finally after the development
i.e. integration. The will include preparation of test data and entering that data valid or
intentionally invalid in the system to check that the system accepts no garbage data in the
database. Besides this 10-20 users will be asked to input real working data to check the
validation of data.
1.4 Testing Results and Evaluation
The testing of CRMS resulted in some important findings which were appropriately
incorporated in the system. While testing the source code, errors that were identified were
corrected. Then usability tests were conducted which intend to test the usability
(working) of CRMS.

While testing, one problem that the evaluators identified was concerned with the security
of the CRMS. The evaluators noted that copying the URL of the page and typing it in
another blank window opens the page which abuses the idea of logging in with a user
name and password. The error was reported and a solution was found. For solving this
problem, session variables were used and at the time of log in, these variables are
assigned the information of the logged in user. Every operation in the CRMS requires this
information before proceeding towards completion.
1.5 Conclusion
The process of testing continued through out the implementation phase. Through testing
resulted in the identification and correction of errors which were ignored previously
during development. The testing procedures and results guarantee the quality of the
CRMS. Testing phase was an extra effort which was necessary for providing the
demanded quality corresponding to the requirements.

Section 2: Test Cases
The test cases prove to be an effective way of identifying error in the system. The test
cases correspond to the use case model developed during the analysis phase of the
development process. The test cases are designed for the operations where the user has to
manually type some information that has to be stored in the database. Some of the
important test cases are given below.
Administrator
Administrator login
Fields Test Data Results

User name ami123 Valid & Accepted
Password abcd1234 Valid & Accepted

User name ami123-)(*& Invalid & rejected
Password abcd1234@!#$% Valid & Accepted
Add connection

Serial number Hello12344 Valid & Accepted

Serial number @^&87Hello12344$## Invalid & rejected
Add bills

Due date 23/4/04 Valid & Accepted
Amount before due 11/2/04 Valid & Accepted
date
Amount after due 12/2/2004 Valid & Accepted
date

Create sub administrator

First name amisadf Valid & Accepted
Last t name abcdasdf Valid & Accepted
nic 11111-1111111-2 Valid & Accepted
address 41 –c model town Valid & Accepted
telephone 0427512108 Valid & Accepted
mobile 03004300734 Valid & Accepted
email abc@hot.com Valid & Accepted
city asdfasdf Valid & Accepted
username Taim34344 Valid & Accepted
password Sdafsad34 Valid & Accepted

First name ami123+_)( Invalid & Rejected
Last t name abcd1234!@#@#$%124 Invalid & Rejected
nic Dfg34563_3453_3+_~` Invalid & Rejected
address Jordan@#@$#123++~++` Invalid & Rejected
telephone 12345-435_112 Invalid & Rejected
mobile 035-355141 Invalid & Rejected
email abc@ho4*@#.com Invalid & Rejected
city Lahore3445 Invalid & Rejected
username Taimoorjaffar3435*&*& Invalid & Rejected
password 34dsfgdsg#$%@#$2 Invalid & Rejected
Block sim requests

search Hello12344 Valid & Accepted

serach @^&87Hello12344$## Invalid & rejected

Viewer customer profile

search Hello12344 & 03004300734 & Valid & Accepted
tasdfas

search Hello12344343@#@ & 0300- Invalid & rejected
4300734 & tasdfas232
Update profile

First name amisadf Valid & Accepted
Last t name abcdasdf Valid & Accepted
city asdfasdf Valid & Accepted

First name ami123+_)( Invalid & Rejected
Last t name abcd1234!@#@#$%124 Invalid & Rejected
nic Dfg34563_3453_3+_~` Invalid & Rejected
address Jordan@#@$#123++~++` Invalid & Rejected
telephone 12345-435_112 Invalid & Rejected
mobile 035-355141 Invalid & Rejected
email abc@ho4*@#.com Invalid & Rejected

Change password

Old password ami123 Valid & Accepted
New password abcd1234 Valid & Accepted
Confirm new Adsfsd2323 Valid & Accepted
password

Old password ami12322@#@ Invalid & rejected
New password abcd1234&^$! Invalid & rejected
Confirm new Adsfsd2323@#@#2$?<>| Invalid & rejected
password
CUSTOMER
Login

User name taimorr123 Valid & Accepted
Password abcd1234 Valid & Accepted

User name ami123@##$@ Valid & Accepted
Password abcd1234454?>| Valid & Accepted
Purchase connection (application form)

First name smith Valid & Accepted
Last name jhon Valid & Accepted
address e-142 ali view gulshan park Valid & Accepted
tel 0421234567 Valid & Accepted

First name Jack 2342##$ Invalid & Rejected

Last name Jhonk#$@343 Invalid & Rejected

address 4e/2@jsdf lahore34?> Invalid & Rejected
nic 12315+-1245_343 Invalid & Rejected
tel 042_75125478 Invalid & Rejected
Update profile

First name Amisadf Valid & Accepted
Last t name Abcdasdf Valid & Accepted
Occuption Student Valid & Accepted
city lahore Valid & Accepted

First name Amisadf445 Invalid & Rejected
Last t name Abcdasdf343 Invalid & Rejected
nic 11111-1111111_2 Invalid & Rejected
address 41 @343c model town Invalid & Rejected
telephone 042_7512108 Invalid & Rejected
mobile 0300_4300734 Invalid & Rejected
email Abc_hot.com Invalid & Rejected
Occupation Student 243 Invalid & Rejected

New user

First name Amisadf Valid & Accepted
Last t name Abcdasdf Valid & Accepted
Occuption Student Valid & Accepted
city lahore Valid & Accepted
Username Ali876 Valid & Accepted
passowrd Jangoo324 Valid & Accepted

First name Amisadf445 Invalid & Rejected
Last t name Abcdasdf343 Invalid & Rejected
nic 11111-1111111_2 Invalid & Rejected
address 41 @343c model town Invalid & Rejected
telephone 042_7512108 Invalid & Rejected
mobile 0300_4300734 Invalid & Rejected
email Abc_hot.com Invalid & Rejected
Occupation Student 243 Invalid & Rejected
username Ali34@2 Invalid & Rejected
password Jangle32#34 Invalid & Rejected

Change password

Old password ami123 Valid & Accepted
New password abcd1234 Valid & Accepted
Confirm new Adsfsd2323 Valid & Accepted
password

Old password ami12322@#@ Invalid & rejected
New password abcd1234&^$! Invalid & rejected
Confirm new Adsfsd2323@#@#2$?<>| Invalid & rejected
password

REFERENCES
SITES:
1. http://asp.net
2. http://www.aspfree.com
3. http://www.asp-toolkit.com
4. http://www.411asp.net
5. http://www.aspobjects.com
6. http://www.123aspx.com
7. http://msdn.microsoft.com/asp.net
8. http://www.aspnetfaq.com
9. http://www.devasp.net
10. http://www.aspcode.net/default.aspx
11. http://www.aspexperts.com
12. http://www.aniteps.com
13. http://www.crms2day.com
14. http://www.mobilinkgsm.com
15. http://www.uml.org
BOOKS:
1. Developing Web Applications with ASP.NET by Hank
Meyne
2. ASP .NET Kick Start by Stephen Walther
3. ASP.NET Unleashed, Second Edition by Stephen Walther;
Paperback
4. Programming Microsoft ASP.NET by Dino Esposito
5. Programming ASP.NET, 2nd Edition by Jesse Liberty
6. Beginning ASP.NET 1.0 with Visual Basic.NET by Chris
Goode
7. Programming ASP.NET, 2nd Edition by Jesse Liberty, Dan
Hurwitz
8. ASP.NET for Dummies by Bill Hatfield
9. ASP.NET 2.0 Beta Preview by Bill Evjen
10. The Ultimate VB .NET and ASP.NET Code Book by Karl
Moore
11. ASP.NET v. 2.0-The Beta Version (Microsoft Net
Development Series) by Alex Homer
12. Sams Teach Yourself ASP.NET in 21 Days (2nd Edition)
by Chris Payne

13. A First Look at ASP.NET v 2.0 by Alex Homer

14. Sams Teach Yourself PL/SQL in 21 Days (2nd Edition)
by Jonathan Gennick, Tom Luers

Customer Relationship Management System (Aamer1)

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Customer Relationship Management System (Aamer1)

Hochgeladen von

Copyright:

Verfügbare Formate

Software Requirement Specifications (SRS)

In the name of Allah, Most Gracious, Most Merciful.

UCP Application Development Project Standards 1

UCP Application Development Project Standards 2

CUSTOMER RELATIONSHIP MANAGEMENT SYSTEM

UCP Application Development Project Standards 3

“If I don’t come back, tell them,

UCP Application Development Project Standards 4

UCP Application Development Project Standards 5

UCP Application Development Project Standards 6

UCP Application Development Project Standards 7

UCP Application Development Project Standards 8

Software Requirement Specification

Section 1: Vision Statement

1.1 Software Purpose

Name CRM FOR MOBILE PHONE COMPANY

System Subsystem Revision

UCP Application Development Project Standards 9

1.4 Document conventions and definitions

1. 5 Intended audience and reading suggestions

UCP Application Development Project Standards 10

Section 1: Overall Description

Who the system is being developed for?

Why is such a system required?

UCP Application Development Project Standards 11

Brief description of the resources needed by the proposal:

The minimum system requirement would include standard PC running Windows

UCP Application Development Project Standards 12

Programming techniques / packages:

Brief description of the development plan for the proposed project:

Two software methodologies would be used namely Object Oriented Software

Installation and Configuration:

UCP Application Development Project Standards 13

Testing of the system would be considered as an ongoing process which would be

Data Validation Test:

Dot Net Framework and ASP.Net

As the CRMS would be maintaining an online database to store information so Microsoft

UCP Application Development Project Standards 14

UCP Application Development Project Standards 15

Section 2: System features

2.1 System Features of an Administrator

2.1.4 Add sub administrator:

2.1.5 Block sim:

2.1.6 Online payment request:

UCP Application Development Project Standards 16

2.1.7 Roaming request:

2.1.9 View queries:

2.1.10 View customer profile:

2.1.13 Payment information:

2.1.14 Change password:

UCP Application Development Project Standards 17

2.2 System Features of the Customer

2.2.1 Register user

2.2.3 Pay bills

2.2.4 Connection status

2.2.7 Request online payment

2.2.8 Block sim

UCP Application Development Project Standards 18

2.2.10 Update profile

UCP Application Development Project Standards 19

Section 1: Analysis and Design

1.2 Requirement Specifications

1.2.1 The Problem

UCP Application Development Project Standards 20