Essay: Integrated Application for Caller-Identification System – Software Requirements Specification

1) Introduction:
A Software Requirements Specification (SRS) is a description of a software system to be developed, laying out functional and non-functional requirements. Software requirements specification establishes the basis for an agreement between customers and contractors or suppliers.
The software requirements specification document enlists enough and necessary requirements that are required for the project development. To derive the requirements we need to have clear and thorough understanding of the products to be developed or being developed. This is achieved and refined with detailed and continuous communications with the project team and customer till the completion of the software.
1.1) Purpose:
The goal of this windows application is to get customer’s information regarding their contact number and display all the information. This application can facilitate the work of those who can handle huge amount of data, as manual track of records is a tedious task, this may reduce lot of unnecessary work.
1.2) Scope:
The work that needs to be accomplished to deliver the customer for better results with specified features and functions in the project. This windows application is limited to specific organizations. There is no need of internet connection. This is an intranet scope for organizations.
1.3) Definitions, Acronyms, Abbreviations:
This is an Integrated Application for Caller-Identification System (Caller-ID System). It is the service where the CLI (Caller Line Identity) is sent to the admin. CNAM (Caller Name) is the character text field used in caller name service. Caller-ID System typically consists of the caller’s contact number with contact information. The information made available to the called party may be displayed on a separately attached device.
It is a windows based application which is hardware integrated system. It is build by using windows technology ASP.NET with C#.NET and Microsoft SQL Server 2008R2.The basic aim of this application is to display customer’s information based on their contact number. It can facilitate the work of those who need to handle huge amount of phone calls by serving customer data for the right person, to the right interface in the appropriate time.
If there is an unknown number for admin then admin asks all details to customer and save it in database. If existing number is appeared then all details of customer will be displayed on the hardware device (Caller-ID device). It is important to handle as many requests as possible on the first contact, and handle them as efficiently as possible. This helps minimize costs while keeping customer satisfied. To help admin to handle requests quickly.
It is common to have a window form with customer’s information, It’s called as CPN (Calling Party Number). This form holds the customer’s screen while entering the contact number. This window is usually called as screen population (screen POP) because that screen is populated with customer’s information.
An acronym, abbreviations of this application are as follows:
• Caller-ID: Caller-Identification.
• CPN: Caller Party Number.
• CLI: Calling Line Identity.
• CNAM: Caller Name.
• Screen-POP: Screen Population.
• Communication Module: The module that allows communication between clients (Customers) and server (admin).
• Developers: The team responsible for developing software system.
1.4) References:
csharp.net-tutorials.com – C#.Net
w3schools.com, tutorialspoint.com – for SQL server
1.5) Overview:
This document, the Software Requirements Specification (SRS), identifies the software requirements in the form of a task and system object model. The model presented within this document is an implicit statement of the requirements. It exhibits the boundaries and capabilities of the system to be built.
2) Overall Description:
The basic aim of this application is to display customer’s information based on their contact number. It is important to handle as many requests as possible on the first contact, and handle them as efficiently as possible.
 User Characteristics:
• Customer:
Customer as an actor demands for particular product along with specification of all the requirements. Customer can:
 Create a new product request.
 Specify all requirements
 Optionally attach design specifications
 View all past request and its details.
• Admin:
The main job of an administrator is to manage the tasks performed by the user. Admin performs the following tasks:
 Creating whole systems.
 Configure all the parameters for displaying information.
 Configure role of the user be it the employee or the customer.
 Constraints:
• Hardware Limitations:
Interface problem in system found at the stage of integration which leads to hardware limitations problem. Problems of uncoordinated system components also create a barrier thus resulting in issues related to hardware.
• Regulatory Policies:
The software works on the basic fundamentals of 3-tier architecture. Hence necessary software is needed to be installed on the computer. The system is relatively heavy and therefore requires huge bandwidth.
• Reliability Requirements:
User is ensured that the system would be reliable at the time if Power Failure. A reliability program plan also improves and evaluates availability of the system by strategy of focusing on increasing maintainability and testability. It checks whether the system is highly reliable or not and generates updates information in correct order.
 Assumptions and Dependencies:
The schedules, estimates and costs are based on many assumptions. If any assumptions are incorrect then specific organization reserves the right to re-estimate both the schedule and the cost for this project.
3) Specific Requirements:
This section of the Software Requirements Specification should contain all the details of the developer need to create. This is the largest and most important part of the SRS.
• Specific requirements should be organized in a logical and readable fashion.
• Each requirement should be stated such that its achievement can be objectively verified by a prescribed method.
• Sources of a requirement should be identified where that is useful in understanding the requirement.
• This should be classify as follows:
3.1) Functionality:
 Admin response for feedback.
 All requirements are very well known, clear and fixed.
 Whole technology should be understood.
 Code simplicity is one the best feature to understand the coding phase.
 This Caller-ID on PC is used for specific organizations as well as for Home Purpose too.
 This is also one of the Home Purpose features as Bright House Network Gadget.
 
3.2) Usability:
This subsection specifies the required learning, operate and training time for a normal user and a power user.
 The whole system takes an hour to understand all requirements, specifications and functionality for a normal user.
 It will take minimum 6 months for learning this application.
 Integration with hardware device to software takes much time for learner (normal user).
 Developers need to be up-skilling and expected to bring great code to an organization.
 Developers must follow the specific standards, which the technology is used.
3.3) Reliability:
Requirements for reliability of the system should be specified as below:
 Availability: A reliability program plan also improves and evaluates availability of the system by strategy of focusing on increasing maintainability and testability.
 MTBF (Mean Time Between Failures): MTBF is a reliability term used to provide amount of failures per million hours for a system or product. This windows based application can take minimum 6 to 7 months for developing the whole application for normal user.
 Accuracy: This term is used to describe the system that estimate, measure or predict. The true value of this windows application is customer’s contact number and measured value is customer’s name and all details. Hence the developer must maintain accuracy between these two values.
3.3.1) Reliability Requirements: There are other requirements for reliability of the system. Some are as below:
 Maintainability: If any requirement occurs, then it should be easily incorporated in the system.
 Portability: The application should be portable on any windows based system.
3.4) Performance:
Performance characteristics of the system are described as below:
 Response time for transaction: This term represents the time for a database transaction. This application will take one to two seconds (average) for database transaction.
 Capacity: The system can accommodate around the 40-50 customers’ capacity in this application.
 Resource Utilization: This application contain resources like,
 Personal Computer configured with Windows-7, Pentium dual core processor.
 RAM is around 256MB to 1GB.
 Communication is done through Ethernet cable or RS232 cable between hardware device and software.
3.4.1) Performance Requirements:
 Cost Sensitivity: Under all circumstances, the maximum cost payable as submitted by the user will be the maximum cost charged to the user.
3.5) Supportability:
This section includes following supportability requirements:
 Naming Conventions: All code will be written as specified by the Pascal Naming Convention (for Class name and Methods name), Camel Casing Convention (Method arguments and local variables) and Hungarian Naming Convention (Data type identification).
 Coding Standards: All codes will be written as required by the .NET Coding Standards.
3.5.1) Supportability Requirements:
 Cost-Effective-To-Maintain: It may covers divers level of documentation, such as system documentation as well as test documentation.
3.6) Design Constraints:
This section represents design decisions that have been mandated and must be adhered to. There are many aspects of any design project that must be considered to determine the feasibility of the system.
3.6.1) Design Constraints Requirements:
 Software Language: All coding will be done in standard of Microsoft .NET platform.
 Scheduling Constraints: Exhaustive searches of the entire set of combinations of jobs will not be done. Heuristics will be developed for this scheduling problem.
3.7) On-line User Documentation and Help System Requirements:
Online help and the guide to install and maintain the system must be sufficient to educate the users on how the use the system without any problems. All documentations will be made in accordance with requirements pertaining to open source software.
3.8) Purchased Components:
In this Caller-ID system, extra Caller-ID device is purchased and used as displaying the information of customer regarding their contact number.
3.9) Interfaces:
This section defines the interfaces that must be supported by the application. It should contain following interfaces:
 User Interface:
The term “User Interface” is used in the context of Personal Computer Systems and electronic devices. The system would be developed with user friendly Graphical User Interface (GUI) making it is to understand at the initial phase.
 Hardware Interface: This system can be implemented on system platform as:
 Microsoft Windows XP/7/8
 Dual Core Processor
 RAM- 2GB and above
 Hard Disk-100GB and above
 Software Interface:
 Platform: Microsoft .NET
 Technology: ASP.NET
 Language: C# (C Sharp)
 For Development: Microsoft Visual Studio-2010
 Back End: Microsoft SQL Server-2008
 Communication Interface: Communication is very important between customers and organizations. Physical connection is required as the LAN cabling.
Diagrams
 .NET Technology is following Object-Oriented Approach.
 Object-Oriented UML Diagrams are as below:
1. Class Diagram
2. System Activity Diagram:
3. Use Case Diagram:
I. Use Case for Admin:
II. Use Case for Whole The System:
4. Sequence Diagram:
5. Collaboration Diagram:
Data Dictionary
1. Table Name: Login
Primary Key: Log_id
Field Name Data Type Size Constraints Description
Log_id Varchar 15 Primary Key Login id of Customer
Email_id Varchar 25 Not Null Email id of Customer
Log_pwd Varchar 25 Not Null Password of Customer
2. Table Name: Admin
Primary Key: id
Foreign Key: Log_id
Field Name Data Type Size Constraints Description
Id Int 25 Primary Key Identification of Admin
Name Varchar 25 Not Null Name of Admin
Log_id Varchar 25 Foreign Key Login id of Admin
Password Varchar 25 Not Null Password of Admin
3. Table Name: Parameter
Primary Key: ParameterID
Field Name Data Type Size Constraints Description
ParameterID Int 30 Primary Key To identify unique parameter
Name Varchar 30 – Parameter Name
4. Table Name: Customer
Primary Key: Contact Number
Field Name Data Type Size Constraints Description
Customer ID
Integer
30
Not Null For Customer unique identification
Contact Number
Numeric
(18,0)
Primary Key Customer contact number
Name
Nvarchar
50
Not Null Customer Name
Age
Numeric
(18,0)
Not Null Customer’s Age
Address Nvarchar 150
Not Null To store the Customer Address
Nationality Nvarchar 50 Not Null Customer’s Nationality
City Nvacrhar 50 Not Null City of Customer
Email Nvarchar 50 Not Null For Customer’s email address
Occupation Nvarchar 50 Not Null Customer’s Occupation
Image Varchar – Not Null Image of Customer
5. Table Name: Call Log
Primary Key: Contact Number
Field Name Data Type Size Constraints Description
Id Int 30 Not Null Identity of Call logs
Contact Number Numeric 30 Primary Key Customer Contact Number
Date Numeric 30 Not Null Call Date
Time Numeric 30 Not Null Call Time