i

Software Requirements Specification

National Registration System (NRS)

Prepared by:

Institute of Information Technology

Quaid-i-Azam University, Islamabad

24-03-2012

ii

Table of Contents
1. Introduction................................................................................................................................1 2. Overall Description....................................................................................................................3 3. System Features......................................................................................................................... 7 4. External Interface Requirements........................................................................................... 11 5. Other Nonfunctional Requirements....................................................................................... 13 6. Other Requirements................................................................................................................ 14

Revision History
Name Date Reason For Changes Version

ii

Software Requirement Specification for NRS

1.
1.1

Introduction
Purpose

The purpose of this document is to provide a comprehensive description of the National Registration System. Requirement specification specifies the different aspects of system and all factors that are necessary for the completion of this project. This document describes the objective of project including functional, non functional requirements and information about external interface. A detailed description of features and objectives of system is also a part of this document. Non functional requirement, constraints, operating environment and internal, external behavior of system is captured in this document. Users of the system and their classes according to their characteristics are defined. The release number or revision and reasons for change in documents are also maintained.

1.2

Document Conventions

The following are the list of conventions and acronyms used in this document and the project as well: NRS: National Registration System. IIT: Institute of Information Technology. SQL: Structured Query Language; used to retrieve information from a database SQL Server: A server used to store data in an organized format PHP: Hypertext Preprocessor. A server side scripting language. Layer: Represents a section of the project User Interface Layer: The section of the project that refers to what a user can see. Application Logic Layer: The section of the project referring to the Web Server. This is the coordination layer. Data Storage Layer: The section of the project referring to where all data is recorded Boolean: A true/false notation
1

Software Requirement Specification for NRS

Interface: Something used to communicate across different mediums Unique Key: Used to differentiate entries in a database Administrator: A login id representing a user with user administration privileges to the software User: A general login id assigned to most users Client: Intended users for the software

1.3

Intended Audience and Reading Suggestions

This document is reviewed by the intended audience mentioned below and if there is some need of change in requirements according to the vision and scope then it is included in next release of the SRS document. The final implementation of project is done using this document and this would be the final document after approval. The team members of National Registration System The project Supervisor Madam Robina. The Administrative Staff of IIT.

1.4

Project Scope

The current document is related to the first version of National Registration System. This document contains the information about the functionality and requirement analysis of the system that is to be developed. The system would be used for national registration purposes. The National Registration System (NRS) would provide the efficient access to database form different locations. This would be a large scale system that would store the information of a huge population. Database would maintain two types of records, the records of people in country that are 18 or above and those who are less than 18 years. The records of people less than 18 year old would be part of B-form until they reach the age of 18. This system would be very useful and will provide a lot of benefits to different
2

Software Requirement Specification for NRS

institutions in the country. The database accessibility from different locations will also be available. There would be multiple backups for This project has a large Database and number of application software to create, update and retrieve records. Database can be updated from different locations by any authorized administrator using assigned login key, while database users can only view information related to their selves.

References
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.

2.
2.1

Overall Description
Product Perspective

This is a standalone project and it is not a part of any larger system. It is designed to improve the registration process and accessibility to National Database System. This project is motivated by the needs to build an efficient, reliable an accessible database system. This work will propose a system that would be used for the registration of people and it would be easily accessible. Database accessibility form different locations of country and outside country is very important and of great benefits. Easy and efficient access will provide a lot of benefits to different institutions in country. Fingerprint registration is also a part of this project that will give a great power to identify people. This project integrates a large Database and number of application software to create, update and retrieve records. Database can be updated from different locations by any authorized administrator and it would be a centralized database system to maintain consistency and data integrity.

Software Requirement Specification for NRS

Block Diagram of System Deployment Architecture.

2.2

Product Features

This project has different users so functionality is different for different users. There may be there types of users for this project, Administrator, Entry operators and end users. So every user can perform some specific takes according to privilege to system. This system is accessible anywhere through internet and it backup is maintained at different locations. Tasks a User can perform: A user can register information. A user can view information A user can request for any information A user may extract information A user can ask for any correction of information. A user can provide information. Tasks an Administrator can perform: Administrator Administrator Administrator Administrator Administrator Administrator Administrator Administrator Administrator can view any record. can edit any record can update any record can delete any record can add new record can restrict any information can give privilege to other users for information access can make change in system. can take Backup.

Tasks an Entry Operator can perform: Entry operator Entry operator Entry operator Entry operator Entry operator can create record. can update record. can view any record. can delete record. can edit record.

Software Requirement Specification for NRS

2.3

User Classes and Characteristics

This is a national database and registration system so there are various kinds of users of this system. The users of this system are Administrators who maintain system and registered people also have option to view their information. As this system would be accessible on internet so the users should have some knowledge of internet and computer. The administrators of the system should have more knowledge of the internals of the system and is able to rectify the small problems that may arise due to disk crashes, power failures and other disaster to maintain the system. The proper user interface, users manual, online help and the guide to install and maintain the system must be sufficient to educate the users on how to use the system without any problems.

Software Requirement Specification for NRS

2.4

Operating Environment

Server Hardware Software: This software is windows based, and it would install on any hardware platform having windows operating system. Client Operating Systems UNIX MAC Windows Client Application Java and Java Script compatible browser: Netscape IE Opera Mozilla Firefox

2.5

Design and Implementation Constraints

This product will be developed using PHP language and MySQL database would be used at backend. To run any application developed in PHP there is need of web server software so the PHP would work. The best web server for current system is Apache and it is free. Next task is to install PHP on the server. Finally there is need of MySQL . This is the actual database software for storing data, any database software like PLSQL, Oracle can be used.

2.6

User Documentation

The product will include user manual. The user manual will include product overview, complete configuration of the used software (such as MySQL and web server,), technical details, backup procedure and contact information which will include email address. There will be no online help for the product at this moment. The product will be compatible with the Internet Explorer 6.0 or higher.

Software Requirement Specification for NRS

2.7

Assumptions and Dependencies

This system can also work for a small network but full working of the NRS is dependent on the availability of Internet connection. The system is designed in such a manner which will gather maximum information from the users; the user will be given the provision of Login, Logout.

Basic password authentication will be used to protect NRS from unauthorized access. Redundant Database is setup as the role of backup Database Server when primary database is failure. This project can work only when web server and database would be installed so if the assisted software does not work then the whole system would be useless.

3.

System Features

This system is required to maintain data and provide access to this data, so there would be some major functions illustrated in the use case given below. The functions originated by system would different for different user class. A user with unauthorized access would not be able to view or extract any information form system, the security in this system is of much importance only registered or authorized administrators can access to the system. System Environment:

Software Requirement Specification for NRS

3.1
3.1.1

Access to information:
Description and Priority The proposed system in intended to store retrieves, update and manipulate information. The information stored in the database system would be accessible from anywhere but this information is available to registered users and members containing Login ID and password. For every function there are some constraints or checks that would help to maintain data consistency and integrity.

3.1.2

Stimulus/Response Sequences Responses for Administrator: The administrator can access to information of any member. For this purpose administrator use the given login ID and password. The system checks the login validity and then gives rights to the administrator to access any information in the system. Response for Members: The registered member can view information only related to them, so for viewing information members require the identification number. When a member enters identification number the system checks the corresponding information against that ID and then sends this information to member. If there is no match of ID found the system will display a message that ID is not valid or not registered.

Response for Entry Operators: The Entry operator can also access to any information in a system. For this purpose Entry Operator requires a login ID and password.

Software Requirement Specification for NRS

3.1.3

Functional Requirements

There is condition for every person to register once and this information is stored and a unique identification number is also given to that person. Person would be identified through the given identification number. The retrieval would be efficient so the identification process can take place without delays.

3.2
3.2.1

Login for authorization:

A system generated login Id and password would be given to Administrators. The data security is very important in this system so to change any information into the system the system Administrator ID will be used. Administrators can create users that would have some limited rights like update, create, and view information. These users would help to manage different tasks as this is a large scale system so it requires more staff 3.2.2 Stimulus/Response Sequences Responses for Administrator: The administrator can Login and Logout, when the Administrator Login into the Library system, the system will check for validity of login .If the Login and password are valid, the response to this action is the administrator will be able to modify, view, add, deleting and all other functions that can be performed on the database. Response for Members: The registered member can view information only related to them, so for viewing information members require the identification number. When a member enters identification number the system checks the corresponding

Software Requirement Specification for NRS

information against that ID and then sends this information to member. If there is no match of ID found the system will display a message that ID is not valid or not registered.

Response for Entry Operators: The Entry Operators are registered users with assigned account ID and password. When an Entry operator login the system checks for the validation of login ID. Entry operated has the access to some limited features of system.

3.2.3

Functional Requirements This feature of the system is very important and if it fails then the integrity of the whole system would be doubted. Authorized access to information stored in the system is very important if any unauthorized person reach to the information then the whole system can be destroyed.

3.3

Automated response:

3.3.1

Description and Priority A very useful feature of automated response is also contained by this system, automatic responses would b generated when there will be some satisfied condition occur. For example when the registration of a member becomes expired the system will generate an alert message.

3.3.2

Stimulus/Response Sequences Responses for Administrator: The automated response feature is only for the assistance of administrator. An administrator can view the automated alerts generated from system. The system generated responses are then managed by administrator.

10

Software Requirement Specification for NRS

Response for Members: Automated responses for members are also displayed when a member view information. These responses inform a user about validation of any information. Response for Entry Operators: The Entry Operators are registered users with assigned account ID and password. Entry operators can also manage the automated responses generated by system.

3.3.3

Functional Requirements The automated response generation is a feature that assists both the users and administrator of the system. Wherever some specific condition becomes the automated responses are generated from system. These responses are because of some predefined conditions mentioned in the system, so when a condition in fulfilled then a message or request is sent in response.

4.
4.1

External Interface Requirements

The system has an external user interface through which users communicate with system. This interface provides the necessary information to users about the system and how to use the system. Graphical User Interface (GUI): User of the system has only one way to interact with system. Graphical User Interface provides a very helpful and easy communication interface to the users of the system. The interface provides the option to the users of system to login. The control buttons are also provided to view information about system or to contact with system administrator. The interface would be interactive and all necessary checks would be provided. The Client Side Scripting language JS would be the best to provide an error free and interactive
11

Software Requirement Specification for NRS

interface. The validation checks for input forms will check if the entered information is according to the rules of system. If a user enters invalid data into the form the client side script will work before submitting the form and it will indicate the error by display and error message. User will be using any web browser to view the interface.

4.2

Hardware Interfaces

The current project does not need any special hardware but it requires a server machine that would handle huge number of simultaneously requests. So there is need for a computer system with greater memory to install database. If the functionality is provided at three different layers then there would be need of two different servers, one for database and the other for applications. Common hardware requirement for a server side would be as following. Server Side: Operating System: Windows 7, xp or Me. Processor: Dual Core Hard Drive: 80GB or more RAM: 4 GB Client Side: Operating system: windows 7, 2000,xp Processor: 1.7 GHz RAM: 256 MB Hard Drive: 20 GB or more

4.3

Software Interfaces

The system would be developed using both client side and server side scripting language. The PHP would be used for server side scripting. There is need of server software so Apache or IIS (Internet Information Service) would be used. The IIS serve is proved with Microsoft windows and need not to be purchased. PHP library files are also needed to be
12

Software Requirement Specification for NRS

installed to run PHP so PHP would also be installed. The PLSQL database would be used for storing data. The software interfaces description is given below: Database: PLSQL Web Application: PHP (Hypertext Preprocessor) Web Server: IIS (Internet Information Services)

4.4

Communications Interfaces

The system specified in this document would be available on internet so there are some software protocols that enable the communication between two computer systems. Theses software protocols are listed below. TCP/IP HTTP HTTPS FTP TCP/IP stands for Transmission control protocol/ internet protocol which enable the communication between two of more computes. HTTP stands for HyperText Transfer Protocol which provides a secure and encrypted transmission of data on internet. FTP stands for file transfer protocol, this is the most important protocol which is used to transfer files form host to client computer.

5.
5.1

Other Nonfunctional Requirements

<If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features.>

5.2

Safety Requirements

<Specify those requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define any safeguards or actions that must be taken, as well as actions that must be prevented. Refer to any external policies or regulations that state safety issues that affect the products design or use. Define any safety certifications that must be satisfied.>

5.3

Security Requirements

<Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication
13

Software Requirement Specification for NRS

requirements. Refer to any external policies or regulations containing security issues that affect the product. Define any security or privacy certifications that must be satisfied.>

5.4

Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning.>

6.

Other Requirements

<Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>

Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire organization, and just include terms specific to a single project in each SRS.>

Appendix B: Analysis Models

Appendix C: Issues List

14