You are on page 1of 32

[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............................................................................................................................................2
2.1. System environment......................................................................................................................................3
2.2. Functional requirements definitions.............................................................................................................4
2.3. Use cases.......................................................................................................................................................4
2.3.1. Use Case: Access NMH Home Page.....................................................................................................5
2.3.2. Use Case: Client / User Access NMH Home Page................................................................................6
2.3.3. Use Case: Client Login..........................................................................................................................9
2.3.4. Use Case: Administrator Login...........................................................................................................12
2.3.5. Use Case: Client Selects Modify/ Update............................................................................................14
2.3.6. Use Case: Search .................................................................................................................................16
........................................................................................................................................................................16
2.3.7. Use Case: Checking Availability of Marriage Hall / Filling the Data.................................................17
FIGURE D.2.3.7................................................................................................................................................19
2.4. Non-functional requirements......................................................................................................................19
3.0. Requirement specifications.............................................................................................................................20
3.1. External interface specifications.................................................................................................................20
3.2. Functional Requirements............................................................................................................................20
3.2.1. Access NMH Home Page....................................................................................................................20
3.2.2. Client Login ........................................................................................................................................20
3.2.2. Administrator Login ............................................................................................................................21
3.2.4. Modify / Update ..................................................................................................................................22
3.2.3. Search ..................................................................................................................................................23
3.2.4 Checking Availability..........................................................................................................................24
3.2.5. Filled Information Sending to Client and NMH Administrator...........................................................25
3.3. Detailed non-functional requirements.........................................................................................................26
3.4. System Evolution........................................................................................................................................28
4.0. Index...............................................................................................................................................................29

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.0. Overall description

2
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

System Environment

3
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 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.

4
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

DFD FOR ACCESSING HOME PAGE

FIGURE - D 2.3.1

5
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.

4. The Web Server passes the request to the NMH Home Page.

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

6
FIGURE 2.3.2

DFD FOR USER AND CLIENT ACCESSING HOMEPAGE

FIGURE D 2.3.2

Figure 1.3.3 Client Login Page

Brief Description:
The Client Login for Modify/Update.

7
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.

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

8
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

FIGURE 2.3.3
DFD FOR CLIENT LOGIN

9
FIGURE D.2.3.3

Figure 2.3.4 Administrator Login Page

Brief Description:
The Administrator Login for Add / Modify / Update

Initial step-by-step description:


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

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.

10
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

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

11
Rules for creating Administrator 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

Rules for creating Administrator Secure Password


1. Password can have any case
2. Password should be minimum 5 characters
3. Password should be maximum 8 characters
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
6. Password should be case sensitive
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.4. Use Case: Administrator Login

FIGURE 2.3.4

DFD FOR ADMINISTRATOR LOGIN

12
FIGURE D.2.3.4
Figure 3.3.5 Client Selects Modify / Update

Brief Description:
The Client chooses to 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. It’s verified the page automatically will turn to their own tiles.

3. Client has a Modify / Update option.

13
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

14
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.

6. The NBITON Server checks to see if all required fields are selected /
filled.

15
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.

Initial step-by-step description:


For this use case to be initiated the Alum must be connected to the

Internet and on the NMH Home page.

16
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

17
FIGURE 2.3.7

DFD FOR CHECKING AVAILABILITY / FILLING DATA

18
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.

19
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 all required fields are not
empty.
4. If the required fields are not
empty, the NBITON Server

20
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
Basic Path 1. The NBITON Server presents
the 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 empty.
4. If the required fields are not
empty, the NBITON Server
Verifies the filled User Name
and Password are matching

21
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 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
Reference: SRS 2.3.4

3.2.4. Modify / Update


Use Case Name: Modify / Update
Priority Essential
Trigger Selects
Precondition The Client is connected to the
Internet and on the NMH Edit Page
Basic Path 7. The NBITON Server presents the
Client with a User Name ,
Password requisition form for
Modify / Update.
8. The Client fills in the form and
click submit
9. The NBITON Server checks to see

22
if 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.
11. 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.
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 NBITON
Server is returned to the wait
state.
Other
Reference: SRS 2.3.5

3.2.3. Search
Use Case Name: Search
Priority Essential
Trigger Menu selection
Precondition The User must be connected to the
Internet and on the NMH Home
page.
Basic Path 1. The User clicks on search option.

23
2. The NBITON Server returns a
form.
3. The User fills in the search option
and clicks submit.
4. The NBITON Server checks to see
if 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.
Exception Path 1. If the connection is terminated
before the form is submitted, the
fields are cleared and the
NBITON Server is returned to the
wait state.
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

3.2.4 Checking Availability


Use Case Name: Checking Availability
Priority Essential
Trigger Menu selection
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.
2. The NBITON Server returns a
form.

24
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.
Exception Path 1. If the connection is terminated
before the form is submitted, the
fields are cleared and the
NBITON Server is returned to the
wait state.
Other
Reference: SRS 2.3.7

3.2.5. Filled Information Sending to Client and NMH Administrator


Use Case Name: Filling and Mailing
Priority
Trigger Menu selection
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.
2. The NBITON Server returns a
form.
3. The User fills in the form and
clicks submit.
4. The NBITON Server checks to see
if 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

25
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
Exception Path 1. If the connection is terminated
before the information is
returned, the NBITON Server is
returned to the wait state.
2. If the connection is terminated
after the information is returned,
the NBITON Server is returned to
the wait state
Other
Reference: SRS 2.3.7

3.3. Detailed non-functional requirements

Attribute Name Attribute Attribute


Type Size
Pageid* Varchar 20
Lableid* Varchar 20

26
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
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.

27
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.

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.

28
4.0. Index
Borland Database Engine...............................................................................................................................1, 4, 28
Customer..................................................................................................................................................................4
Database.................................................................................................................1, 3, 4, 14, 16, 20, 24, 25, 26, 28
Function...............................................................................................................................................................1, 2
Institute of Electrical & Electronic Engineers.........................................................................................................1
Non-functional.......................................................................................................................................................26
Server...................................................................................1, 3, 4, 6, 14, 15, 16, 17, 20, 21, 22, 23, 24, 25, 26, 28
System..................................................................................................................................................2, 3, 4, 19, 28
Use Case...................................................................................................................................4, 6, 8, 10, 13, 15, 16

29