Software Requirements

Specification
for

City corporation automation

Table of Contents
Table of Contents...........................................................................................................................ii
Revision History.............................................................................................................................ii
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........................................................................................................................4
3.3 Software Interfaces.........................................................................................................................4
3.4 Communications Interfaces.............................................................................................................4
4. Functional requirements .........................................................................................................4
5. Other Nonfunctional Requirements.......................................................................................5
5.1 Performance Requirements..............................................................................................................5
5.2 Safety Requirements........................................................................................................................5
5.3 Security Requirements.....................................................................................................................5
5.4 Software Quality Attributes.............................................................................................................6
5.5 Business Rules................................................................................................................................6
6. Other Requirements.................................................................................................................6
Appendix A: Glossary....................................................................................................................6
Appendix B: Analysis Models.......................................................................................................6
Appendix C: To Be Determined List............................................................................................6
1. Introduction
       Our intelligent city corporation Solution for management of the municipality System offers the
ability to acquire real-time information, . Experts in the field enables operators to perform real-time
data analysis on the information gathered. Road repair management measures are aimed at improving
the safety and flow of traffic utilizing road maps more effectively.

1.1 Purpose
 The main purpose of this project is to help the public in knowing their place details 
and getting their problems solved in online without going to the officer regularly until 
the problem is solved. By this system the public can save his time and eradicate 
corruption in government offices
 This can be used for automating various book keeping activities associated with 
various responsibilities of the Municipal Corporation of a large city.
 The corporation also plans to use the same web site for its road maintenance activity

1.2 Document Conventions

            Font: Times new roman 
            Font size:12 
            Font siz (headings): 20

1.3 Intended Audience and Reading Suggestions

           The members of the city , the employees of the municipal corporation , the workers and also 
mayor can access this application  for  effective functioning . Since the city population exceeds 5 
lakh, the maximum number of concurrent clicks can be upto 10 clicks per second.

1.4 Product Scope

Smart city corporation automation is an Analytics Module and provides Traffic Incident Detection,
and real time Traffic Flow Metrics & statistical analysis , individual profiles of citizens , Traffic and
road Monitoring can integrate with third party traffic management and smart roadway systems and
hosts a feature rich product scope itself. The system can be used for incident detection, road repair
or repair management for statistical metrics of a roadway
1.5 References
. 1. Anderson, J. E. 2003. “Control of Personal Rapid Transit Systems.” Elektronikk , Vol. 99, No. 1,
108-116
2. Bretherton, D., Bowen, G., Wood, K. 2002. ‘Effective urban traffic management and control –
SCOOT VERSION 4.4’. Proceedings of European Transport Conference Proceedings Cambridge.
3. Christos Xithalis, 2008, PRT Hermes
4.IEEE SRS format
Project specification requirement

2. Overall Description

2.1 Product Perspective

 The main purpose of this project is to help the public in knowing their place details 
and getting their problems solved in online without going to the officer regularly until 
the problem is solved. By this system the public can save his time and eradicate 
corruption in government offices
 This can be used for automating various book keeping activities associated with 
various responsibilities of the Municipal Corporation of a large city.
 The corporation also plans to use the same web site for its road maintenance activity
the major components of the overall system, subsystem interconnections, and external
interfaces can be helpful.

2.2 Product Functions

 Summarize the major functions the product must perform or must let the user perform.
 Organize the functions to make them understandable to any reader of the SRS.
 A picture of the major groups of related requirements and how they relate, such as a top level
data flow diagram or object class diagram, is often effective.

2.3 User Classes and Characteristics

 Identify the various user classes that you anticipate will use this product.
 User classes may be differentiated based on frequency of use, subset of product functions
used, technical expertise, security or privilege levels, educational level, or experience.
 Distinguish the most important user classes for this product from those who are less
important to satisfy.
2.4 Operating Environment
 The software will operate in including the hardware platform, operating system and versions,
and any other software components or applications with which it must peacefully coexist are
as follows :

3. J2EE: (Servlet, JSP, JAXP, Java Beans) Application architecture.

 JAVA: Application architecture.

 DB2: Database.

 Ajax: Asynchronous Java Script and XML.

 XML: Extension Markup Language.

 WASCE: (Web Sphere Application Server Community Edition) Web Server.

 TSM (Admin): Tivoli storage Manager Admin.

 Soda: For developing use case reports.

 Local Language Translator: For local language developing

 ORACLE For inserting Tables.

3.1 Design and Implementation Constraints

 GUI is only in English.
 This system is working for single server.
 Limited to HTTP/HTTPS.
 User should have basic knowledge of computer .

 For example, if the customer’s organization will be responsible for maintaining the
delivered software.
3.2 User Documentation
 tbd

3.3 Assumptions and Dependencies

 it is assumed that one hundred compatible computers will be available before the system
is installed and tested.
 It is assumed that the muncipality will have enough trained staff to take care of the
system.

4. External Interface Requirements

4.1 User Interfaces

 The software provides good graphical interface for the user any administrator can operate
on the system, performing the required task such as create, update, viewing the details of
the book.
 Allows user to view quick reports like complaints registered / repairs made etc in between
particular time.
 Stock verification and search facility based on different criteria.

4.2 Hardware Interfaces

 Operating system : window 
 Hard disk :40 GB 
 RAM : 256 MB 
 Processor : Pentium(R)Dual­core CPU

4.3 Software Interfaces

 Java language 
 Net beans IDE 7.0.1 
 MS SQL server 2005
4.4 Communications Interfaces
 Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting.
 Identify any communication standards that will be used, such as FTP or HTTP.
 Specify any communication security or encryption issues, data transfer rates, and
synchronization mechanisms.

5. Functional Requirements

5.1 Login
4.1.1 Description and Priority
This is required to verify the access authorization of different users to the city corporation
automation software. It is highly important The general public is not provided any login id and
possess access only to home page and progress page.
4.1.2 Stimulus/Response Sequences
Input as form:
1. Username
2. Password
Output:
Success:
 If administrator, redirected to branch office page
 If supervisor, redirected to the branch office page
 If mayor, Report generation page
Error: Try again later
4.1.3 Functional Requirements
TBD

5.2 Branch office

4.1.1 Description and Priority

After login credentials verified the supervisor and administrator are redirected to the 
specific branch webpage. It is used to limit the information access of the supervisor and 
administrator to the specific locality that they preside over. In case of general public this page gives 
non­confidential information about the specific locality.
4.1.2 Stimulus/Response Sequences
 Input:
1. Road maintenance
2. Water supply
Output:
Redirection as per selected by the concerned user.
4.1.3 Functional Requirements
TBD

5.3 Road Maintenance

4.1.1 Description and Priority

This function records all necessary information about the requested, ongoing or
completed road maintenance projects.
4.1.2 Stimulus/Response Sequences
Input:
1. If Supervisor:
a. Road maintenance request
i. Priority
ii. Estimation of raw material
iii. Estimation machines required
iv. Estimation of personal
b. Ongoing Road maintenance
i. End date
ii. On time/ Delay
c. Completed road maintenance
2. If administrator:
a. Inventory
3. If user:
a. Request road maintenance
i. Locality
ii. Road Name
iii. Explain grievance
b. Progress
Output:
1. If Supervisor:
a. Road maintenance request accepted and maintenance id generated.
2. If administrator:
a. Redirected to inventory page
3. If user:
a. Check Progress

4.1.3 Functional Requirements

TBD
5.4 Inventory

4.1.1 Description and Priority

Keep record of the available materials for road maintenance projects. Access is
restricted to the corporation administration.
4.1.2 Stimulus/Response Sequences
Input:
1. Add
a. Raw material required
b. No of machines
c. Types of personnel
d. No of personnel
2. Update
Output:
Database successfully updated. Schedule function is executed.
4.1.3 Functional Requirements
TBD

5.5 Schedule Maintenance

4.1.1 Description and Priority

Schedule the accepted road maintenance.
4.1.2 Stimulus/Response Sequences
Input:
1. Locality
2. Priority of projects
3. Estimated raw material
4. Estimated machines required
5. Estimated no of personal
6. Available no of machines
7. Available types of personnel
8. Available no of personnel
Output:
A schedule of all accepted road maintenance projects is provided to the
supervisor of each locality.
4.1.3 Functional Requirements
TBD
5.6 Progress report

4.1.1 Description and Priority

A progress report of all ongoing road maintenance projects can be monitored by the
general public as submitted by the supervisor.
4.1.2 Stimulus/Response Sequences
Input:
1. Road maintenance id
2. Locality
Output:
1. End date
2. Percentage complete
3. Delay/ On time

4.1.3 Functional Requirements

TBD

5.7 Statistics

4.1.1 Description and Priority

Maintenance statistics generated area wise or for the whole city.
4.1.2 Stimulus/Response Sequences
Input:
1. Area
2. Time range
Output:
Table containing
1. maintenance id,
2. date requested,
3. end date,
4. accepted/ongoing/completed,
5. locality
4.1.3 Functional Requirements
TBD
6. Other Nonfunctional Requirements

6.1 Performance Requirements

 Response Time :­ The system shall give responses in 1 second after checking the citizen’s 
information. 
  Capacity :­ The System must support  10  people at a time. 
 User­interface :­ The user­interface screen shall respond within 5 seconds. 
 Conformity:­ The systems must conform to the Microsoft Accessibility

6.2 Safety Requirements

Humans are error-prone, but the negative effects of common errors should be limited.
E.g., users should realize that a given command will delete data, and be asked to confirm their intent or
have the option to undo..

6.3 Security Requirements

 Citizen  Identification:­ The system requires the patient to identify himself /herself using 
PHN 
  Logon ID :­ Any user who uses the system shall have a Logon ID and Password. 
 Modification Any modification (inert, delete, update) for the Database shall be synchronized
and only by the administrator in the city. 
 Front Desk staff Rights:­ Front Desk staff shall be able to view all information , add new 
citizens  to city corporation  but shall not be able to modify any information in it.
 Administrators' Rights:­ Administrators shall be able to view and modify all information in 
city corporation .

6.4 Software Quality Attributes

 Good quality of the framework= produces robust, bug free software which contains all 
necessary requirements Customer satisfaction

6.5 Business Rules

 A business rule is anything that captures and implements business policies and practices. A
rule can enforce business policy , make a decision, or infer new data from existing data .
 This includes the rules and regulations that the system user should abide by .
 This includes the cost of the project and the discount offers provided .
 The user should avoid illegal rules and protocols
 Neither admin nor member should cross the rules and regulations .
7. Other Requirements
The other requirements could be of different categories of users namely the working staff, the
employees who work in the second, third levels of the corporation etc.
Depending upon the category of the user the access rights are decided .It means if the user is an
administrator then he will be able to modify the data, delete append etc.
All other users except the admin can only retrieve information for various purposes and avail services
.

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.