Software Requirements

Specification
for
An On-line RTO system
Version 1.0 approved
Prepared y Amol !"ed#ar$ Ameet !"ed#ar
Sin"%ad &olle%e of 'n%ineerin%$Pune
0()0*)+01,
Copyright 2014 An On-line RTO System
Software Requirements Specification for An On-Line RTO System Page ii
Table of Contents
1. Introduction................................................................................................................................1
1.1 Purpose ............................................................................................................................................ 1
1.2 Document Conventions..................................................................................................................... 1
1.3 Intended Audience and Reading Suggestions...................................................................................1
1.4 Product Scope................................................................................................................................... 1
1.5 References........................................................................................................................................ 1
2. Overall Description....................................................................................................................2
2.1 Product Perspective...........................................................................................................................2
2.2 Product Functions............................................................................................................................. 2
2.3 User Classes and Characteristics.......................................................................................................2
2.4 Operating Environment..................................................................................................................... 2
2.5 Design and Implementation Constraints...........................................................................................2
2.6 User Documentation......................................................................................................................... 3
2.7 Assumptions and Dependencies........................................................................................................3
3. External Interface Requirements.............................................................................................3
3.1 User Interfaces.................................................................................................................................. 3
3.2 Hardware Interfaces..........................................................................................................................3
3.3 Software Interfaces...........................................................................................................................3
3.4 Communications Interfaces..............................................................................................................3
4. System Features.........................................................................................................................4
4.1 System Feature 1............................................................................................................................... 4
4.2 System Feature 2 (and so on)............................................................................................................4
5. Other Nonfunctional Requirements.........................................................................................4
5.1 Performance Requirements...............................................................................................................4
5.2 Safety Requirements.........................................................................................................................5
5.3 Security Requirements...................................................................................................................... 5
5.4 Software Quality Attributes..............................................................................................................5
5.5 Business Rules.................................................................................................................................. 5
6. Other Requirements..................................................................................................................5
Revision History
Name Date Reason For Changes Version
Initial 03/07/14 Creation 1.0
Software Requirements Specification for An On-Line RTO System Page 1
1. Introduction
1.1 Purpose
This software implements an internet based system for RTO activities. This software is the first of
its kind, in the way that it converts daily manual activities to a user friendly manner of interactions.
This software is the first release V1.0.
1.2 Document Conventions
This SRS document follows the followin conventions!
1. Stron or bold type for hiher"level re#uirements.
$. %talici&ed font type for lower"level re#uirements.
1.3 Intended Audience and Reading Suggestions
This SRS document is intended for developers, pro'ect manaers, marketin staff, users, testers,
and documentation writers concerned with this pro'ect. (sers are encouraed to read throuh the
documentation carefully for complete manual of usae. )evelopers may skip the introduction and
directly refer the functional re#uirements from the table of contents for re#uired functionality
related documents.
1.4 Product Scope
%mplement the followin operations in a user friendly and efficient way!
(ser reistration includin personal and vehicular details.
*onduct on"line e+amination for issuin ,earner-s ,icense to new users.
%mplement reservation system for .ermanent ,icense issuin.
%ssue reistration numbers to new vehicles /commercial0private1
.rovide statistical #ueryin of vehicles to 23Os and 3overnment 4uthorities for
informational purposes.
.rovide support to .olice investiations based on any search parameter
/personal0vehicular1
1.5 References
This document has only referred the .ro'ect Scope document provided alon with the complete
pro'ect report.
Software Requirements Specification for An On-Line RTO System Page 2
2. Overall Description
2.1 Product Perspective
The system replaces a manual methodology of activities being carried out daily in the form of a
computer based interface for registering vehicles and new users for online testing. The product also
provides statistical information for NGOs and other authorities which is an pioneering innovation
for easy information retrieval.
2.2 Product Functions
Reistration of vehicles and users
Statistical data access to authorities
2ew reistration plates for vehicles
2.3 User Classes and Characteristics
There are four main cateories of user classes accessin this pro'ect!
1. System )evelopers! for debuin, testin and validation of data stored in to database
$. 3eneral (ser! for reisterin vehicles, licenses and e+aminations
5. .olice 4uthority! for information related to criminal activities
6. 23O! for RT% implementation on #ueries of vehicles and persons of interest.
2.4 Operating Environment
Re#uirements!
1 gigahertz (GHz) or faster 32-bit (x86) or 64-bit (x64) processor
1 gigabyte (GB) RAM (32-bit) or 2 GB RAM (64-bit)
16 GB available hard disk space (32-bit) or 20 GB (64-bit)
DirectX 9 graphics device with WDDM 1.0 or higher driver
Operating System: Any system with internet browsing support
Browser: HTML5 Compatible browser with Adobe Flash support
2.5 Design and Implementation Constraints
This software was implemented usin V7.2et paradim. 8ence it re#uires that the client have .net
framework 6.0 installed on the system. Open source systems may use the 9ono implementation
of .net. 2o other constraints are imposed by this liht weiht system.
2.6 User Documentation
:ully documented 4.% of the system is provided ;in"place< into the system. (ser at any point of
time may hit the :1 key to access the online help provided into the pro'ect or click on the #uestion
mark symbol on the top riht of the software menu.
Software Requirements Specification for An On-Line RTO System Page 3
2.7 Assumptions and Dependencies
4ssumptions! This system assumes that the user maintains level of anonymity while appearin for
the test e+amination and depends on the user-s choice to maintain moral behavior.
)ependencies! The .2=T 6.0 platform must be installed into the user-s system for runnin the
application without any problems.
3. External Interface Requirements
3.1 User Interfaces
The 3(% implementation is based on the >indows implementation of forms, thus all the
screens have a simple minimi&e, ma+imi&e and close button for each of the functionality.
8elp menu te+t appears over each icon on a hover time of $ seconds on any item with the
mouse pointer.
3.2 Hardware Interfaces
On"line e+amination re#uires web cam interface for validation of user appearin for test.
.ermanent e+amination re#uires the candidate to sin on a virtual pad to validate his0her
sinature.
9anetic strip scanner for #uickly swipin vehicle reistration card.
3.3 Software Interfaces
1. 9yS?, database for storae and retrieval of records.
$. Visual 7asic .2=T user interface
3.4 Communications Interfaces
This program uses communication to the Web and Database server for transfer of form data filled
into system by user. It can communicate over HTTP web protocol for user based side as well as
communicate over 802.3 Ethernet between computers operating on RTO system internal computers.
4. System Features
4.1 New User Registration
4.1.1 Description and Priority
This allows user to create a validated user account for logging in to the RTO system. User
information collected is:
Software Requirements Specification for An On-Line RTO System Page 4
Name, Date of Birth, Address, Gender, Mobile number, email address, preferred user
name and password.
Vehicle type, fuel, Class of Vehicle, Manufacturing date, Place of Manufacturing,
Place of Purchase, Date of Purchase,Chassis Number, Insurance Number,Vehicle
registration plate number,Pollution Under Control Certificate.
4.1.2 Stimulus/Response Sequences
Use Case 1: User enters an invalid data in form. Example: Length of Mobile number is not
10.
System Response: Message Box containing error message and solution to problem. Example:
Please enter only 10 numbers.
Use Case 2: User is less than 18 years of age. This can be calculated from the user's entered
Date of Birth.
System Response: Message Box containing error message: You cannot register for this
account. User must be 18 years or more.
Use Case 3: User enters invalid email id and/or leaves email id field empty.
System Response: Message Box containing error message: Your email address is empty or
invalid. Please check your email id.
4.1.3 Functional Requirements
REQ-1: User must be connected to internet to access the homepage landing.
4.2 Online Examination for Learner's License
4.2.1 Description and Priority
This is a core functional requirement of the system. It enables Internet Based acquisition of
Learner's License by passing a simple test of 10 questions selected randomly out of a
question bank of 500 questions stored on server. The user must pass this exam with a
minimum of 70% marks to be eligible for receiving the license.
4.1.2 Stimulus/Response Sequences
Use Case 1: User unable to finish exam within time ie timer counts down to zero.
System Response: All unanswered questions are marked incorrectly answered and total
score will be calculated on basis of all answers given till that point. Execution resumes
normally.
Use Case 2: User answers all questions and ends test
System Response: On calculation of total marks, the system generates a token for the license
user and displays it if the person has passed the criteria.
Use Case 3: User answers all questions but fails to achieve criteria
System Response: Message Box displaying the score of person and prompt to retry the test
or exit the module completely.
4.2.3 Functional Requirements:
Software Requirements Specification for An On-Line RTO System Page 5
REQ1: User must have a validated user account and must enter the user name
password combination assigned to him in order to access link to online examination.
REQ2: If the user has already registered for a permanent license, this link will not be
accessible. Unless the COV is different, this link will not be accessible.
4.3 Token System for Permanent License
4.3.1 Description and Priority
This feature allows user to book a date for applying for a Permanent License Test. The system will
allocate only a fixed number of people for a given day, and attempts to suggest the closest possible
date for the given failed date.
4.3.2 Stimulus/Response Sequences
Use Case 1: User has tried to attempt booking before 30 days from issuing of license
System Response: Error message displaying: You cannot register for a permanent license
within 30 days of obtaining a Learner's license. Please try later.
Use Case 2: User has tried to attempt booking after 90 days from issuing of license
System Response: Error message displaying: You cannot register for a permanent license
because your learner's license has expired. Please register for your renewal of license.
Use Case 3: User attempts to book a test date in an over full slot on calendar.
System Response: Error message displaying: You cannot select the given date, as it is full or
it is a holiday. Please select another date.
Use Case 4: User successfully books a test date.
System Response: The slot number allocated to user is displayed on the screen. User may
take a printout of this to show for physical verification at the actual test centre.
4.3.3 Functional Requirement
REQ1: User login and password combination.
REQ2: User's licensing status ie invalid or valid Learner's license available.
REQ3: Valid date on calendar for test booking.
4.4 Statistical Data Enquiry Support
4.4.1 Description and Priority
This is an addon feature for providing information to NGOs and government authorities regarding
number of vehicles , class of vehicles and manufacturing date.
4.4.2 Stimulus/Response Sequences
Use Case 1: User attempts to search with multiple parameters .
System Response :Message box prompting the user that all fields must be filled.
Use Case 2: User enters valid data .
System Response: Data report is generated showing the required information.
4.4.3 Functional Requirement
REQ1: The NGO should have separate account.
Software Requirements Specification for An On-Line RTO System Page 6
4.5 Support to police investigations
4.4.1 Description and Priority
This feature helps authorities to gather information about on going criminal investigations.
5. Other Nonfunctional Requirements
5.1 Performance 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 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,
Software Requirements Specification for An On-Line RTO System Page 7
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.>
5.5 Business Rules
<List any operating principles about the product, such as which individuals or roles can perform which
functions under specific circumstances. These are not functional requirements in themselves, but they may
imply certain functional requirements to enforce the rules.>
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
<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-
transition diagrams, or entity-relationship diagrams.>
Appendix C: To Be Determined List
<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they can be
tracked to closure.>
Source: http://www.frontiernet.net/~kwiegers/process_assets/srs_template.doc