Software Requirements Specification

[Type text]
Software Requirements Specification

Version 1.1
November 29, 2007
Web Accessible Marriage Hall and Related Services

Table of Contents
Table of Contents................................................................................................................................................ii
Table of Figures..................................................................................................................................................iii
1.0. Purpose...........................................................................................................................................................1
1.1. Introduction................................................................................................................................................1
1.2. Scope............................................................................................................................................................1
1.3. Glossary.......................................................................................................................................................1
1.4. Document overview..................................................................................................................................2
2.0. Overall description.......................................................................................................................................3
2.1. System environment..................................................................................................................................4
2.2. Functional requirements definitions.......................................................................................................5
2.3. Use cases.....................................................................................................................................................6
2.3.1. Use Case: Access NBitOn Marriage Hall Home Page...................................................................6
2.3.2. Use Case: Client / User Access NMH Home Page.........................................................................8
2.3.3. Use Case: Search...............................................................................................................................12
2.3.4. Use Case: Checking Availability of Marriage Hall / Filling the Data.......................................12
2.4. Non-functional requirements.................................................................................................................13
3.0. Requirement specifications.......................................................................................................................16
3.1. External interface specifications............................................................................................................16
3.2. Functional Requirements........................................................................................................................16
3.2.1. Access NMH Home Page................................................................................................................16
3.2.2. Survey.................................................................................................................................................16
3.2.3. Create a new entry............................................................................................................................17
3.2.4 Update an Entry.................................................................................................................................18
3.2.5. Search for an NMH/E-mail an NMH.............................................................................................19
3.3. Detailed non-functional requirements..................................................................................................21
3.4. System Evolution.....................................................................................................................................23
4.0. Index..............................................................................................................................................................24
ii
Table of Figures
iii
1.0. Purpose
1.1. Introduction
This Software Requirements Specification provides a complete description of all
the functions and specifications of the NBITON Solutions Private Ltd Marriage Hall
(NMH) Web Accessible NMH Database.
1.2. Scope
The NBITON Solutions Private Limited Marriage Hall Web Accessible NMH
Database (NMH) is designed to run on the NBITON server and to allow client to fill
out, modify their space/tiles, and update an existing database entry. The data will be
held in an MYSQL database on the NBITON server.
1.3. Glossary
Term Definition
NMH NBITON Solutions Private Limited
Marriage Hall
MDE MYSQL Database Engine
MODIFY Client can Edit their Tiles with
Permitted Elements
NMHWAMD NBITON Solutions Private Limited
Marriage Hall Web Accessible MYSQL
Database
Html Hyper text markup language
IEEE Institute of Electrical and Electronic
Engineers
Web Site A place on the world wide web
1
1.4. Document overview
The remainder of this document is two chapters, the first providing a full
description of the project. It lists all the functions performed by the system. The final
chapter concerns details of each of the system functions and actions in full for the
software developers’ assistance. These two sections are cross-referenced by topic; to
increase understanding by both groups involved.
2
2.0. Overall description
The NMH encompasses numerous files and information from the NMH
Database, as well as files on the NBITON server system. This system will be
completely web-based, linking to NMH and the remote web server from a standard
web browser. An Internet connection is necessary to access the system.
2.1. System environment
FIGURE – 2.1
DFD FOR SYSTEM ENVIRONMENT
FIGURE – D 2.1
3
System Environment
The NMHWAMD web site will be operated from the NBITON server. When an
Clients/User connects to the Web Server, the Web Server will pass the Entry/Request
to the NBITON Server. The NBITON Server will then interact with the NMH
Database through MDE, which allows the Windows type program to transfer data to
and from a database.
2.2. Functional requirements definitions
Functional Requirements are those that refer to the functionality of the
system, i.e., what services it will provide to the user. Nonfunctional (supplementary)
requirements pertain to other information needed to produce the correct system and
are detailed separately.
2.3. Use cases
The system will consist of NMH Home page with ----------- selections.
The first selection is Client can modify the Tiles. After Handover the Tiles to
Client, they can able to Modify and Update their details, with help of their user
Name and Password periodically. Using this facility Client no need to call to
developer to Modify / Update the required Information. Individually they would do
4
the Modification / Updation as per their requirements with permit-able fields. End
of the Modification / Updation the page will automatically return to home page of
the NMH.
The Second selection is user can Access the data’s from NBITON Server
through Web server and they can able to search whatever they require related
Marriage Hall Information.
2.3.1. Use Case: Access NMH Home Page
FIGURE – 2.3.1
FIGURE – 2.3.1 A
5
DFD FOR ACCESSING HOME PAGE
FIGURE - D 2.3.1
FIGURE - D 2.3.1 A
Figure 2.3.1/2.3.1 A Access NMH Home Page

Brief Description
The NBITON Web Server is waiting on a Client/User to connect.
Initial step-by-step description
For this use case to be initiated, the user/Client must be connected to the Internet
and connected to the Web Server.
1. The User/Client connects to the Web Server.
2. The User selects the Search link on the NMH home page.
3. The Client selects the Modify/Update link on the NMH home page.
6
4. The Web Server passes the request to the NMH Home Page.
2.3.2. Use Case: Client / User Access NMH Home Page
FIGURE 2.3.2
DFD FOR USER AND CLIENT ACCESSING HOMEPAGE
FIGURE D 2.3.2
7
Figure 1.3.3 Client Login Page
Brief Description:
The Client Login for Modify/Update.
Initial step-by-step description:

For this use case to be initiated the Client must be connected to the Internet and
on the NMH Edit Page.
1. The Clients Verifying their user name and Password
2. The user name should be match with database
3. The password should be match with database
4. There is no registration facility for clients
5. Administrator only provide temporary user name and password to client
6. Using Temporary user name and password client select submit
7. After first login, the system will ask permanent user name and password
8. Clients can select their preferred user name and password
9. Once user name has been selected they can’t change the user name
10. There is a facility to change clients password
11. Modification of User name and Password will be reflected in Database.
12. Client can use their changed user name and password only for their Login
13. Verification completed the page will be automatically redirected to their own
tiles page. It will help to Modify / Update.
14. Clients user name and password doesn’t match the page will be displayed error
message.
8
15. Client can re login / use exact user name and password to access their tiles page
16. The Log out option is helps client to secure out from Client tiles page
Rules for creating Login Name:
 User Name should be small case

 User Name should be minimum 5 characters
 User Name should be maximum 8 characters
 User Name field should not allow more than 8 characters
 User Name should contain alpha numeric characters
 User Name should be unique
 User Name should be case sensitive
 User Name should not contain special characters
 User Name should not contain spaces
 User Name should not be same as password
 User Name should not be same as client name for security.
 Don’t allow Expired user name.
Rules for creating Client Login Password
1. Password can have any case

2. Password should be minimum 5 characters
3. Password should be maximum 8 characters
4. Password should contain alpha numeric characters
5. Password should be case sensitive
6. Password should not contain special characters
7. Password should not contain spaces
8. Password should not be same as with user name
9. Password should not allow copy and paste
10. Password can get from keyboard characters only
2.3.3. Use Case: Client Login
9
FIGURE 2.3.3
DFD FOR CLIENT LOGIN
FIGURE D.2.3.3
Figure 2.3.4 Administrator Login Page
Brief Description:
The Administrator Login for Add / Modify / Update

For this use case to be initiated the Administrator must be connected to the
Internet and on the NMH Edit Page.
1. The Administrator Verifying their user name and Password
2. The user name should be match with database
10
3. The password should be match with database
4. There is no registration facility for Administrator
5. Administrator their self they can create user name and password to access the
Add / Modify / Update page
6. Administrator verifying admin user name and password
7. If it is wrong the page will give appropriate error message and automatically
retrieves the Edit page.
8. If it is successfully verified and if it is right, the page turns to Add / Modify /
Update page.
9. The Administrator can see the all dynamic contents of NMH home page
10. The Administrator need to enter 2nd password to Access the Add / Modify /
Update page
11. These two passwords help to save the dynamic content page from
unauthorized users.
12. These two passwords made for security purpose.
13. Authorized person can login as a Administrator with the help of two
passwords.
14. After Admin login, the Administrator can do Add / Modify / Update or any
other related work with NMH pages.
15. There is a facility to change Administrator password
11
16. Modification of Password will be reflected in Database
17. Logout option helps to secure out from NMH Content page
Rules for creating Administrator Login Name
1. User Name should be small case

2. User Name should be minimum 4 characters
3. User Name should be maximum 8 characters
4. User Name should contain alpha numeric characters
5. User Name should be unique
6. User Name should be case sensitive
7. User Name should not contain special characters
8. User Name should not contain spaces
9. User Name should not be same as password
10. User Name should not be same as deactivated
Rules for creating Administrator Login Password

4. Password should contain alpha numeric characters
6. Password should not contain special characters
Rules for creating Administrator Secure Password

4. Password should be contain at least one Caps, one small, one special
Character and one numeric character
5. Password should contain alpha numeric and special characters
12
2.3.4. Use Case: Administrator Login
FIGURE 2.3.4
DFD FOR ADMINISTRATOR LOGIN
13
FIGURE D.2.3.4
Figure 3.3.5 Client Selects Modify / Update
Brief Description:
The Client chooses to Modify/Update.

For this use case to be initiated the Client must be connected to the Internet and
on the NMH Edit Page.
1. The Clients Verifying their user name and Password
2. It’s verified the page automatically will turn to their own tiles.
14
3. Client has a Modify / Update option.
4. The Client selects the “Modify/Update” link.
5. The NBITON Server returns the Modify/Update form.
6. The Modify/Update the form.
7. The Client clicks submit.
8. The NBITON Server retains information in the database and updation /

modification will be reflected in Database.
9. The NBITON Server returns the Client to the NMH Edit Page.
2.3.5. Use Case: Client Selects Modify/ Update
FIGURE 2.3.5
DFD FOR MODIFY / UPDATE
15
FIGURE D.2.3.5
Figure 2.4.6 User Selects Search
Brief Description:
The User chooses to Search option from NMH home page.
Initial step-by-step description.

For this use case to be initiated the User must be connected to the Internet and on
the NMH Home page.
1. The User selects the “Search” link.
2. The NBITON Server returns the “Search Option.”
3. The User fills in the option form.
4. The User can choose which City/Area/State to give the result.
5. The User clicks submit.
16
6. The NBITON Server checks to see if all required fields are selected / filled.
7. If all required fields contain data / its filled the NBITON Server give the searched
data from the NBITON Database.
8. If a required filed is empty the NBITON Server returns the search form to the
Client with a error / suggestion message.
9. The NBITON Server returns the User to the NMH Home Page.
2.3.6. Use Case: Search
FIGURE 2.3.6
DFD FOR SEARCH
FIGURE D 2.3.6
Figure 2.3.6 User Checking Availability of Marriage Hall / Filling the data
Brief Description:
The User chooses to Checking Availability an existing Marriage Hall in the NMH
Database.
17
For this use case to be initiated the Alum must be connected to the Internet and
on the NMH Home page.
1. The User chooses the “Checking Availability” option.
2. The NBITON Server presents the User with a search Option.
3. The User Selects the Marriage Hall for Checking Availability.
4. The NBITON Server returns the data’s from NBITON database for the requested
search.
5. The User checks the Availability.
6. The NBITON server returns the form to fill the details from user to hold the
Marriage Hall for requested user.
7. The NBITON Server returns the Confirmation Message to User which they have
filled.
8. The copy of the filled form has been sent to the respective Client and the
Administrator of the NMH Home page via EMAIL.
9. The User can search again if they need any other Marriage Hall.
10. The NBITON Server updates the data in to NBITON Data Base.
11. The NBITON Server returns the User to the NMH Home Page.
2.3.7. Use Case: Checking Availability of Marriage Hall / Filling the Data
18
FIGURE 2.3.7
DFD FOR CHECKING AVAILABILITY / FILLING DATA
19
FIGURE D.2.3.7
2.4. Non-functional requirements
There are requirements that are not functional in nature. Specifically, these
are the constraints the system must work within.
The web site must be compatible with the Netscape and Internet Explorer,
Mozilla web browsers. This system will use the same type of Internet security
presently being used by NBITON Private Solutions Private Limited.
20
3.0. Requirement specifications
3.1. External interface specifications

None
3.2. Functional Requirements
3.2.1. Access NMH Home Page

Use Case Name: Access NMH Home Page
Priority Essential
Trigger Menu selection
Precondition User/Client is connected to the Internet
and on the NMH home page
Basic Path 1. Web Server sends the User / Client to
the NBITON Server.
2. The NBITON Server presents the
User / Client with the NMH Home
Page.
Alternate Path N/A
Postcondition The User / Client is on the NMH Home
Page
Exception Path If there is a connection failure the
NBITON Server returns to the wait state
Other
Reference SRS 2.3.1 & 2.3.2
3.2.2. Client Login

Use Case Name: Client Login
Priority Essential
Trigger Selects
Precondition The Client is connected to the Internet
and on the NMH Edit Page
Basic Path 1. The NBITON Server presents the
Client with a User Name , Password
requisition form.
2. The Client fills in the form and click
submit
3. The NBITON Server checks to see if
21
all required fields are not empty.
4. If the required fields are not empty,
the NBITON Server Verifies the filled
User Name and Password are
matching with existing data’s in the
NMH Database.
5. If any of the required fields are
mismatch, the NBITON Server
returns a message and returns the
Client to the User Name and
Password requisition form.
6. The User Name and Password are
correct NBITON Server returns the
respective tile to the Client from
NMH Page
Alternate Path N/A
Postcondition The Login Name and Password record is
created in the Login Name, Password
Table of the NMH Database.
Exception Path 1. If the connection is terminated before
the form is submitted, the fields are
all cleared and the NBITON Server is
returned to the wait state.
Other
Reference: SRS 2.3.3
3.2.2. Administrator Login

Use Case Name: Administrator Login
Priority Essential
Trigger Selects
Precondition The Administrator is connected to the
Internet and on the NMH Edit Page
User Name , Password requisition
form.
2. The Administrator fills in the form
and click submit
3. The NBITON Server checks to see
if all required fields are not
22
empty.
4. If the required fields are not
empty, the NBITON Server
Verifies the filled User Name and
Password are matching with
existing data’s in the NMH
Database.
Administrator to the User Name
and Password requisition form.
6. The User Name and Password
are correct NBITON Server
returns the dynamic contents page
to the Administrator from NMH
Page
7. The Administrator should verify
secure password to Add /
Modify / Update Dynamic
contents page to do the respect
work
Alternate Path N/A
Postcondition The Login Name and Password record is
created in the Login Name, Password
Table of the NMH Database.
Exception Path 8. If the connection is terminated
before the form is submitted, the
fields are all cleared and the
NBITON Server is returned to the
wait state.
Other
3.2.4. Modify / Update

Use Case Name: Modify / Update
Priority Essential
Trigger Selects
Precondition The Client is connected to the Internet
23
and on the NMH Edit Page
Client with a User Name , Password
requisition form for Modify / Update.
8. The Client fills in the form and click
submit
all required fields are not empty.
10. If the required fields are not empty,
the NBITON Server Verifies the filled
User Name and Password are
matching with existing data’s in the
NMH Database.
Client to the User Name and
Password requisition form.
12. The User Name and Password are
correct NBITON Server returns the
respective tile to the Client from
NMH Page
13. The User Modifying / Updating the
Tiles and Submit the Modified /
Updated page.
14. The NBITON Server returns the
NMH Home Page to the Client
Alternate Path N/A
Postcondition The Modification / Updation record is
created in the Modify / Update Table of
the NMH Database.
Exception Path 9. If the connection is terminated
before the form is submitted, the
fields are all cleared and the
wait state.
Other
24
3.2.3. Search
Use Case Name: Search
Priority Essential
Precondition The User must be connected to the
Internet and on the NMH Home page.
Basic Path 1. The User clicks on search option.
2. The NBITON Server returns a form.
3. The User fills in the search option and
clicks submit.
any required field is empty.
5. If any required field is empty the
NBITON Server will send a message
and return the User to the new entry
search option page.
6. If no required field is empty and clear
the NBITON Server will returns the
required data to the user from the
NMH Table in the NMH Database,
and return the user to the NMH
Home Page.
Alternate Path N/A
Postcondition A record is created in the NMH Table of
the NMH Database.
cleared and the NBITON Server is
2. If the connection is terminated after
the form is submitted, but before the
User is returned to the NMH Home
Page, the record will be selected from
the NMH Table of the NMH
Database.
Other
Reference: S.R.S 2.3.6
25
3.2.4 Checking Availability
Use Case Name: Checking Availability
Priority Essential
Precondition The User must be connected to the
Internet and on the NMH Home Page.
Basic Path 1. The User clicks on Checking
Availability on NMH Home page.
3. The User enters the Date/Month/Year
and type of Hall for the Availability.
4. The NBITON Server queries the
NMH Database for that particular
Date/Month/Year and type of Hall
then it returns a table of all
Availability from that
Date/Month/Year and Hall type in a
form.
Alternate Path
Postcondition The record in the NMH Table of the
NMH Database has been retrieved and
the User is returned to the CIS NMH
Home Page.
cleared and the NBITON Server is
Other
3.2.5. Filled Information Sending to Client and NMH Administrator

Use Case Name: Filling and Mailing
Priority
Precondition The User is connected to the Internet and
on the NMH Information Page.
Basic Path 1. The User clicks on e-mail an NMH
Availability link.
26
3. The User fills in the form and clicks
submit.
any mandatory required fields are
empty.
5. If any mandatory required fields are
empty the NBITON Server returns a
message and the form.
6. If none of the mandatory required
fields are empty the NBITON Server
queries the NMH Database for the
requested User’s entry.
7. The NBITON Server returns the non-
private information on the requested
User and a message stating if the
requested User will accept e-mails.
8. After completion of the User request
the copy of the filled forms has been
sent to respected Client and NMH
Administrator , the NBITON Server
returns a message to the User and
returns the NMH Home Page.
Alternate Path N/A
Postcondition The User receives the information on the
requested data, receives e-mail
confirmation message, or is returned to
the NMH Home Page
the information is returned, the
wait state.
2. If the connection is terminated after
the information is returned, the
wait state
Other
27
3.3. Detailed non-functional requirements
Attribute Name Attribute Type Attribute Size

Pageid* Varchar 20
Lableid* Varchar 20
Lablename* Varchar 25
url* Varchar 60
Forecolor* Varchar 10
Backgroundcolor* Varchar 10
Allowelement* Varchar 6
State* Varchar 20
City* Varchar 20
Area* Varchar 20
Typeofservice* Varchar 20
Name* Varchar 25
Address* Varchar 125
Website* Varchar 60
Contactnumber* Int 11
Email* Varchar 40
Contactperson* Varchar 25
Proprietor* Varchar 25
Hoteltype* Varchar 20
Hallcapacity* Int 11
Diningcapacity* Int 11
Conferencefacility* Int 11
Noofrooms* Int 11
Parkingfacility* Varchar 20
Foodallowed* Varchar 20
Charges* Int 11
Selectstate* Varchar 20
Selectcity* Varchar 20
First_area* Varchar 20
28
Second_area Varchar 20
Third_area Varchar 20
First_date* Date 3
Second_date Date 3
Third_date Date 3
Purpose* Varchar 20
Mandapam Bit 1
Hotel Bit 1
Decorators Bit 1
Catering Bit 1
Orchestra Bit 1
Photovideo Bit 1
Beautyparlour Bit 1
Fields marked with an ‘*’ are required fields.
4. REQUIREMENTS
Hardware: NBitOn Server
Operation System Window 95 or above
Internet Connection Existing telephone lines / Broad Band
Code Standard The web pages will be coded in jsp and Servlet in
Netbean 5.5.1.
The connection to the NMHWAMD Database will be done
with MySql Connector Java 5.0.8.
Each page of the web site will be fully documented.
Performance The system should generate the records in the

appropriate table of the NMH Database 100% of the time.
29
3.4. System Evolution
In the future this system will be update to allow students from the Computer
Masters Program to join. If time does not permit the search/e-mail section can be
done, possibly by another Master Studio student. A report generated by the
system of the responses to the survey could be another addition to the CISWAAD
in the future.
30
4.0. Index
31
Audience, 1
MySql Database Engine, 1, 3, 16
Configuration Item, 1
Customer, 3
Database, i, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 16
Developer, 1
Function, 1, 2
Institute of Electrical & Electronic Engineers, 1, 2
Non-functional, 14
Quality Assurance, 1, 2
Server, 1, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
Software Configuration Management Plan, 1
Software Design Document, 1
Software Engineering Institute, 2
Software Project Management Plan, i, 2
Software Quality Assurance Plan, 2
Software Requirement Document, 2
System, 1, 2, 3, 9, 15, 16
Use Case, 3, 5, 6, 7, 8

Software Requirements Specification

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

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

Software Requirements Specification

Hochgeladen von

Copyright:

Verfügbare Formate

[Type text]

Software Requirements Specification

Web Accessible Marriage Hall and Related Services

This Software Requirements Specification provides a complete description of all

(NMH) Web Accessible NMH Database.

held in an MYSQL database on the NBITON server.

software developers’ assistance. These two sections are cross-referenced by topic; to

increase understanding by both groups involved.

web browser. An Internet connection is necessary to access the system.

2.1. System environment

DFD FOR SYSTEM ENVIRONMENT

and from a database.

2.2. Functional requirements definitions

Functional Requirements are those that refer to the functionality of the

are detailed separately.

2.3. Use cases

developer to Modify / Update the required Information. Individually they would do

Marriage Hall Information.

2.3.1. Use Case: Access NMH Home Page

Figure 2.3.1/2.3.1 A Access NMH Home Page

The NBITON Web Server is waiting on a Client/User to connect.

Initial step-by-step description

and connected to the Web Server.

1. The User/Client connects to the Web Server.

2.3.2. Use Case: Client / User Access NMH Home Page

DFD FOR USER AND CLIENT ACCESSING HOMEPAGE

Initial step-by-step description:

1. The Clients Verifying their user name and Password

2. The user name should be match with database

3. The password should be match with database

4. There is no registration facility for clients

5. Administrator only provide temporary user name and password to client

6. Using Temporary user name and password client select submit

8. Clients can select their preferred user name and password

10. There is a facility to change clients password

11. Modification of User name and Password will be reflected in Database.

Rules for creating Login Name:

 User Name should be small case

Rules for creating Client Login Password

1. Password can have any case

2.3.3. Use Case: Client Login

Figure 2.3.4 Administrator Login Page

Initial step-by-step description:

1. The Administrator Verifying their user name and Password

2. The user name should be match with database

4. There is no registration facility for Administrator

Add / Modify / Update page

6. Administrator verifying admin user name and password

retrieves the Edit page.

8. If it is successfully verified and if it is right, the page turns to Add / Modify /

12. These two passwords made for security purpose.

other related work with NMH pages.

15. There is a facility to change Administrator password

Rules for creating Administrator Login Name

1. User Name should be small case

Rules for creating Administrator Login Password

Rules for creating Administrator Secure Password

2.3.4. Use Case: Administrator Login

DFD FOR ADMINISTRATOR LOGIN

Initial step-by-step description:

on the NMH Edit Page.

1. The Clients Verifying their user name and Password

4. The Client selects the “Modify/Update” link.