Study About Requirement Specification (SRS)

2IT602: Software Engineering Practical - 4
Aim: Study about Requirement Specification (SRS).
 Develop the SRS using SRS Template for following System in Group.
(1) Online Banking System (Bank of Baroda).
1. Introduction 47
1.1 Purpose 47
1.2 Scope 47
1.3 Definitions, Acronyms and Abbreviations 48
1.4 References 48
1.5 Overview 48
2. Overall Description 49
3. Specific Requirements 54
3.1 Functionality 54
3.1.1 Logon Capabilities 54
3.1.2 Mobile Devices 54
3.1.3 Alerts 54
3.2 Usability 54
3.3 Reliability 54
3.3.1 Availability 54
3.3.2 Mean Time Between Failures (MTBF) 54
3.3.3 Mean Time to Repair (MTTR) 54
3.3.4 Accuracy 54
3.3.5 Maximum Bugs or Defect Rate 54
3.3.6 Access Reliability 54
3.4 Performance 55
3.4.1 Response Time 55
3.4.2 Administrator/Librarian Response 55
3.4.3 Throughput 55
3.4.4 Capacity 55
3.4.5 Resource Utilization 55
3.5 Supportability 55
3.5.1 Internet Protocols 55
3.5.2 Information Security Requirement 55
3.5.3 Billing System Data Compatibility 55
3.5.4 Maintenance 55
3.5.5 Standards 55
3.6 Design Constraints 56
Patel Vatsal R. [15012021035] 45
3.6.1 Software Language Used 56

3.6.2 Development Tools 56
3.6.3 Class Libraries 56
3.7 On-line User Documentation and Help System Requirements 56
3.8 Purchased Components 56
3.9 Interfaces 57
3.9.1 User Interfaces 57
3.9.2 Hardware Interfaces 59
3.9.3 Software Interfaces 59
3.9.4 Communications Interfaces 59
3.10 Licensing Requirements 59
3.11 Legal, Copyright, and Other Notices 59
3.12 Applicable Standards 59
4. Database Design 60
5. Entity-Relationship Diagram 62
Patel Vatsal R. [15012021035] 46

Software Requirements Specification
1. Introduction
Online banking system is specifically developed for account summary , fund transfer , pay bills
, online fixed deposit , online gift card and request for new cheque book.
We have decided to investigate the use of an Online Banking System. This system would be
used by customer and employees of that bank to maintain the account summary and transaction
and databases and records of customers .The purpose of this document is to analyse and
elaborate on the high-level needs and features of the Online Banking System. It focuses on the
capabilities and facilities provided by a Net-Banking. The data update is done almost
automatically and is much faster..
1.1 Purpose
The purpose of Software Requirements Specification (SRS) document is to describe the
behaviour and working of the Online Banking System. Requirements Specification defines and
describes the operations, interfaces, performance, and quality assurance requirements of the
Online Banking System. The document also describes the non-functional requirements such as
the user-interfaces, security. It also describes the design constraints that are to be considered
when the system is to be designed, and other factors necessary to provide a complete and
comprehensive description of the requirements for the software. The Software Requirements
Specification (SRS) captures the complete software requirements for the system, or a portion
of the system.
1.2 Scope
The Software Requirements Specification captures all the requirements in a single document. The
Online Banking System that is to be developed provides the customers and employees of the Bank
with accounts information and many other facilities. The Online Banking System is supposed to
have the following limitations.
• Customer must have a valid user id and password to login to the system
• If a wrong password is given thrice in succession, that account will be locked and the customer
will not be able to use it. When an invalid password is entered a warning is given to the user
that his account is going to get locked.
• After the valid user logs in he/she is shown the list of accounts he/she has with the banks.
• On selecting the desired account he is taken to a page which shows the present balance in that
particular account number.
Patel Vatsal R. [15012021035] 47

• User can request details of the last “n” number of transactions he/she has performed.
• User can make a funds transfer to another account in the same bank .User is provided with a
transaction password which is different from the login password.
• User can request for cheque book/change of address/stop payment of cheques.
• User can view his monthly as well as annual statements.
1.3 Definitions, Acronyms and Abbreviations

EWS: Employee work space
ATM: Automated teller machine
1.4 References
The SRS document uses the following documents as references:
1.4.1 http://students.iitmandi.ac.in/~v_kumar/Project/BankingSystem/SRS_BankMan_final.pdf
1.4.2 https://www.scribd.com/doc/126596335/online-banking-srs
1.5 Overview
The SRS will provide a detailed description of the Online Banking System. This document will
provide the outline of the requirements, overview of the characteristics and constraints of the
system.
•The first section of SRS gives a brief introduction on bank of Baroda Banking system. This
section also provides the reference information for further study, intended audience and need
&purpose of the product.
•The second section provides an overall description of the application, product features
&functions, users and operating environment (hardware, software and external).
•The third section is about the specific requirements like external interfaces, performance
requirements, design constraints and additional comments.
Patel Vatsal R. [15012021035] 48

2. Overall Description
 Product Perspective
The application is to be fully-functional bank software. It will consist of a few different

modules: -The first module is to be a software application that can be used by bank
customers Online. This application will allow the user to deposit, withdraw and transfer
funds and check balance. The second module is to be a software application that is used
within the bank creates the new user accounts. This application will allow everything the
Online allows as well as some additional features. These features include; account creation,
account deletion, customer records, and reports. Both pieces of software will be linked to a
central bank server. This server will handle multiple threads and will therefore allow for
simultaneous access of multiple users. It will provide for user authentication and will store
all data. In these all are handled by Administrator.
Overview of the proposed system
Patel Vatsal R. [15012021035] 49

 Product Functions
The Online Banking System provides online real time information about the user’s
transactions. The Product functions are more or less the same as described in the product
perspective. The functions of the system include the system providing different type of
services based on the type of users [Member/administrator/manager].
BankMan (Bank Management System) can be used by Bank Employees and/or

Customers
depending on bank policy. It can be used by several employees of the bank at the same
time with
required rights. It can be accessed using any general web browser with graphical
interface.
Our Product consists mainly of two parts i.e. the Employee Work-Space (EWS) and the
ATM Banking.
The EWS would deal with the internal banking functions like new account registration,
withdrawal, deposit, money transfer etc. The ATM banking would be for direct access
of
customers, who could use it for Cash-Withdrawal, Transfers and Account-Summary.
Both of them connect to a main database server for storing and retrieving the data of the
customers.
Functions:
EWS requires employee login. It handles following
1. New Customer Registration
2. Transactions
a. Detail Updation
Patel Vatsal R. [15012021035] 50

b. Deposit
i. Cheque
ii. Cash
c. Debit
d. Transfer
e. Account Summary
ATM transaction requires ATM No. and PIN that will be available to Bank's customer. It
doesn't
require Employee login.
It performs following
1. Cash withdrawal
2. Transfer
3. Account Summary
 User characteristics
The typical bank customer will be a person, from the age of 18 and up. There will more than
likely be a fairly equal distribution of males and females. The typical customer will probably
use the online couple of times a week. The typical customer might not know anything about
computers, so their system needs to be very simple and easy to use. The typically customer will
probably be a busy person; therefore, they will need to do their transactions as quickly and
efficiently as possible. The other user is a bank employee. The bank employee will be a
different type of user. The bank Employee is a fairly educated user, who is willing to sacrifice
simplicity for functionality. They will use the software daily, for every transaction. This could
quite possibly be 30-60 transactions per hour per employee. Due to this frequency of usage
stability and speed of this software is incredibly important
 Constraints
The information of all the users must be stored in a database that is accessible by the
Online System. The Online Banking System is connected and is running all 24 hours a day.
The users access the Online System from any computer that has Internet browsing
capabilities and an Internet connection. The users must have their correct usernames and
Patel Vatsal R. [15012021035] 51

passwords to enter into the Online Dictionary System. The project is safety critical. Under
no circumstances shall a user of the system be harmed or harm others through proper or
improper use of the online. The project shall conform to any rules for Online Banking in
place in the Government of India.
 Assumptions and dependencies

 Embedded real-time environment, or compatible, available on platform if the client
changes or upgrades their office system, the Online Banking System will not be
guaranteed to function unless the new operating system is fully compatible with the
current system. All timings stated in this SRS shall be adhered to within +/- 10% all
requirements are addressed in this version of the Online Banking System. No
requirements are delayed to future versions.
 The various numbers of users and services on the Online Banking system
 Power source
 Systems (User systems/Servers)
 Communication mediums(wired/wireless)
 Internet Connections
Patel Vatsal R. [15012021035] 52

3. Specific Requirements
This section describes in detail all the functional requirements.
3.1 Functionality
3.1.1 Logon Capabilities
The system shall provide the users with logon capabilities.
3.1.2 Mobile Devices

The Online Banking System is also supported on mobile devices such as cell phones.
3.1.3 Alerts
The system can alert the CEO of the bank or the administrator in case of any problems.
3.2 Usability
 The system shall allow the users to access the system from the Internet using HTML or it’s
derivative technologies. The system uses a web browser as an interface.
 Since all users are familiar with the general usage of browsers, no specific training is
required.
 The system is user friendly and self-explanatory.
3.3 Reliability
The system has to be very reliable due to the importance of data and the damages incorrect or
incomplete data can do.
3.3.1 Availability
The system is available 100% for the user and is used 24 hrs a day and 365 days a year. The
system shall be operational 24 hours a day and 7 days a week.
3.3.2 Mean Time Between Failures (MTBF)

The system will be developed in such a way that it may fail once in a year.
3.3.3 Mean Time to Repair (MTTR)

Even if the system fails, the system will be recovered back up within an hour or less.
Patel Vatsal R. [15012021035] 53

3.3.4 Accuracy
The accuracy of the system is limited by the accuracy of the speed at which the employees of
the bank and customers of the bank uses the system.
3.3.5 Maximum Bugs or Defect Rate
Not specified.
3.3.6 Access Reliability
The system shall provide 100% access reliability.
3.4 Performance
3.4.1 Response Time
The Splash Page or Information page should be able to be downloaded within a minute using a
56K modem. The information is refreshed every minute. The access time for a mobile device
should be less than a minute. The system shall respond to the member in not less than two
seconds from the time of the request submittal. The system shall be allowed to take more time
when doing large processing jobs.
3.4.2 Administrator/Manager Response

The system shall take as less time as possible to provide service to the administrator or the
manager or CEO.
3.4.3 Throughput
The number of transactions is directly dependent on the number of customers, the customers
may be the manager, employees of the bank, CEO of the bank and also the people who use the
bank for checking accounts, accounts information, deposited money information,withdrawals
information.
3.4.4 Capacity
The system is capable of handling 250 customers at a time.
3.4.5 Resource Utilization
The resources are modified according the customers requirements .
3.5 Supportability
The system designers shall take in to considerations the following supportability and technical
limitations.
3.5.1 Internet Protocols
The system shall be comply with the TCP/IP protocol standards and shall be designed
accordingly.
Patel Vatsal R. [15012021035] 54

3.5.2 Information Security Requirement

The system shall support the UHCL information security requirements and use the same
standard as the UHCL information security requirements.
3.5.3 Billing System Data Compatibility

The customers balance amount that will be calculated and sent to the system shall be
compatible with the data types and design constraints of the system.
3.5.4 Maintenance
The maintenance of the system shall be done as per the maintenance contract. There shall be
design documents describing the internal works of the software. There shall be an access on the
control panel and servers for the purpose of upgrading the software or flashing any firmware.
3.5.6 Standards
The coding standards and naming conventions will be as per the American standards.
3.6 Design Constraints

3.6.1 Software Language Used
The languages that shall be used for coding the Online Banking System are Active Server
Pages (ASP), Java Servlets, Java Server Pages (JSP), HTML, JavaScript, and VBScript. For
working on the coding phase of the Online Banking System, the Internet Information Services
(IIS) Server needs to be installed.
3.6.2 Development Tools

Will make use of the available Java Development Tool kits for working with Java Beans and
Java Server Pages. Also will make use of the online references available for developing
programs in ASP, HTML and the two scripting languages, JavaScript and VBScript.
3.6.3 Class Libraries
Will make use of the existing Java libraries available for JSP and Servlets. Also we need to
develop some new libraries for the web-based application. Also will develop new programs
using ASP and scripting languages.
3.7 On-line User Documentation and Help System Requirements
Online help is provided for each of the feature available with the Online Banking System. All
the applications provide an online help system to assist the customer. The nature of these
systems is unique to application development as they combine aspects of programming
(hyperlinks, etc) with aspects of technical writing (organization, presentation). Online help is
provided for each and every feature provided by the system.
The User Manual describes the use of the system to Manager and Employees. It describes the
use of the system on mobile systems. The user manual should be available as a hard copy and
also as online help.
Patel Vatsal R. [15012021035] 55

An installation document will be provided that includes the installation instructions and
configuration guidelines, which is important to a full solution offering. Also, a Read Me file is
typically included as a standard component. The Read Me includes a “What’s New With This
Release” section, and a discussion of compatibility issues with earlier releases. Most users also
appreciate documentation defining any known bugs and workarounds in the Read Me file.
Since the installation of Online Banking System is a complex process, our experts will do it. So
an installation Guide will not be provided to the user.
3.8 Purchased Components

The System Administrator will need to purchase the license for IIS Server. Mostly it is
available with Windows Environment. So the system need not purchase any licensing products.
3.9 Interfaces
3.9.1 User Interfaces
Will make use of the existing Web Browsers such as Microsoft Internet Explorer or Netscape.
The user-interface of the system shall be designed as shown in the user-interface prototypes.
Logon Screen Prototype:
New Customer registration
Patel Vatsal R. [15012021035] 56

Home Page Of Bank of Baroda Prototype:
Member Information once Logged in:
Patel Vatsal R. [15012021035] 57

3.9.2 Hardware Interfaces

The software shall interface with the electromechanical that controls the online connection
systems. The software shall interface with a breaking mechanism in case of emergencies. The
transactions and accesses shall be controlled by the software based on command and graphical
user inputs. The hardware interface is supported by the main control panels (buttons, keyboard
,mouse and communication mediums).
3.9.3 Software Interfaces

A firewall will be used with the server to prevent unauthorized access to the system. Software
interface is supported by the main control panels and operating system in which hosts the
algorithms for calculating distributed travel and wait time information . Additionally, the
algorithms define and export system commands for main control panels, and communication
mediums. For testing purposes the software shall be capable of interfacing with software
simulators on a PC computer using GUI applications of web pages.
3.9.4 Communications Interfaces

The Online Banking System will be connected to the World Wide Web. All system interfaces
communicate in order to activate ordered requests. The communication mediums (wired or
wireless) are the external interface that communicates with the control panel of the Online
Banking System. This communication allows for failure messages, and requests to be sent and
received by the main system.
Patel Vatsal R. [15012021035] 58

3.10 Licensing Requirements

Licenses are typically issued by a national banking regulator to applicant corporations that
meet its banking requirements. The requirements may include minimum capital requirements,
minimum number of directors, residence of shareholders, spread of shareholdings, disclosure
of beneficial shareholders, besides other matters. These requirements may differ between
jurisdictions, and may differ depending on the type of license being sought.
3.11 Legal, Copyright, and Other Notices

Online Banking System for Bank of Baroda is legal and cannot be used without its consent.
3.12 Applicable Standards
The ISO/IEC 6592 guidelines for the documentation of computer based application systems
will be followed.
Patel Vatsal R. [15012021035] 59

4. Database Design
Database Name:Online Banking
Table Name: LOGIN

Description: This table is used to store Login details.
Key Field Name Data Type Length Nullable

PK ACCOUNTNO VARCHAR 12 NO
PASSWORD VARCHAR 45 NO
Table Name: CLIENTS

Description: This table is used to store customer details.
NAME VARCHAR 45 NO
SURNAME VARCHAR 45 NO
INITIAL VARCHAR 10 NO
ACCOUNTTYPE VARCHAR 45 NO
SEX VARCHAR 6 NO
D.O.B DATE NO
ADDRESS VARCHAR 200 NO
MOBILENO VARCHAR 10 NO
TELEPHONENO VARCHAR 10 NO
EMAIL VARCHAR 45 NO
PK ID_PASSPORT VARCHAR 45 YES
Patel Vatsal R. [15012021035] 60

Table Name: ACCOUNT

Description: This table is used to store account details.
Key Field Name Data Type Length Nullabe

FK ACCOUNTNO VARCHAR 12 NO
ACCOUNTTYPE VARCHAR 45 NO
ACCOUNTHOLD
ER VARCHAR 45 NO
DATEOPENED DATE NO
BRANCHCODE INT 5 NO
DATEAPPROVE
D DATE NO
ACCOUNTBALA
NCE DECIMAL NO
APPROVED VARCHAR 6 NO
DISAPPROVED VARCHAR 6 NO
Table Name: TRANSACTION

Description: This table is used to store the transaction details.

FK ACCOUNTNO VARCHAR 12 NO
TRANSACTIONID INT NO
TYPEOFTRANSAC
TION VARCHAR 45 NO
TRANSACTIONDA
TE DATETIME NO
REFERENCE VARCHAR 45 NO
Patel Vatsal R. [15012021035] 61

5. Entity-Relationship Diagram
Patel Vatsal R. [15012021035] 62

(2) Online Library Management System
Table of Contents
1. Introduction 66
1.1 Purpose 66
1.2 Scope 66
1.4 References 667
1.5 Overview 677
3. Specific Requirements 73
3.1.1 Logon Capabilities 73
3.1.2 Mobile Devices 73
3.1.3 Alerts 73
3.2 Usability 73
3.3 Reliability 73
3.3.1 Availability 73
3.3.2 Mean Time Between Failures (MTBF) 73
3.3.3 Mean Time to Repair (MTTR) 73
3.3.4 Accuracy 73
3.3.5 Maximum Bugs or Defect Rate 73
3.3.6 Access Reliability 73
3.4 Performance 74
3.4.1 Response Time 74
3.4.2 Administrator/Librarian Response 74
3.4.3 Throughput 74
3.4.4 Capacity 74
3.4.5 Resource Utilization 74
3.5.1 Internet Protocols 74
3.5.2 Information Security Requirement 74
3.5.3 Billing System Data Compatibility 74
3.5.4 Maintenance 74
3.5.5 Standards 74
3.6 Design Constraints 75
Patel Vatsal R. [15012021035] 63

3.6.1 Software Language Used 75

3.6.2 Development Tools 75
3.6.3 Class Libraries 75
3.7 On-line User Documentation and Help System Requirements 75
3.8 Purchased Components 75
3.9 Interfaces 76
3.9.1 User Interfaces 76
3.9.2 Hardware Interfaces 79
3.9.3 Software Interfaces 79
3.9.4 Communications Interfaces 79
3.10 Licensing Requirements 79
3.11 Legal, Copyright, and Other Notices 79
3.12 Applicable Standards 79
4. Supporting Information 80
Patel Vatsal R. [15012021035] 64

1.Introduction
Borrowing books, returning books or viewing the available books at the Library of the local
University is currently done manually where in the student has to go to the Library and check
the available books at the Library. Students check the list of books available and borrow the
books if the book is a borrow book otherwise it is of waste for the student to come to the
library to come to check for the books if the student doesn’t get the book. Then the librarian
checks the student id and allows the member to check out the book and the librarian then
updates the member database and also the books database. This takes at least one to two hours
if the member is available at the near by place otherwise it may take more time.
We have decided to investigate the use of an Online Library Management System. This system
would be used by members who may be students or professors of that University to check the
availability of the books and borrow the books, and by the librarian to update the databases.
The purpose of this document is to analyze and elaborate on the high-level needs and features
of the Online Library System. It focuses on the capabilities and facilities provided by a
Library. The details of what all are the needs of the Online Library System and if it fulfils these
needs are detailed in the use-case and supplementary specifications.
1.1 Purpose
The purpose of Software Requirements Specification (SRS) document is to describe the
external behavior of the Online Library System. Requirements Specification defines and
describes the operations, interfaces, performance, and quality assurance requirements of the
Online Library System. The document also describes the nonfunctional requirements such as
the user interfaces. It also describes the design constraints that are to be considered when the
system is to be designed, and other factors necessary to provide a complete and comprehensive
description of the requirements for the software. The Software Requirements Specification
(SRS) captures the complete software requirements for the system, or a portion of the system.
Requirements described in this document are derived from the Vision Document prepared for
the Online Library System.
1.2 Scope
The Software Requirements Specification captures all the requirements in a single document.
The Online Library System that is to be developed provides the members of the Library and
Patel Vatsal R. [15012021035] 65

employees of the library with books information, online blocking of books and many other
facilities. The Online Library System is supposed to have the following features.
 The product provides the members with online blocking of books capabilities and the
Online Library System is up and running all day.
 The system provides logon facility to the users.
 The system provides the members with the option to check their account and/or change
their options like password of the account whenever needed all through the day during
the library hours.
 The system allows the members to block the books 24 hours a day and all the through
the semester.
 The system lets the library staff to check which all members have blocked the books
and whether they can borrow any more books or not.
 The system allows the Librarian to create the books catalog, add/delete books and
maintain the books catalog.
 The system updates the billing system as and when the member borrows or returns a
book.
 The book catalog is automated and the decision of offering the book based on the
category of the book is automatically decided.
 We also have an order department, which manages to add or remove a book from the
Library.
The features that are described in this document are used in the future phases of the software
development cycle. The features described here meet the needs of all the users. The success
criteria for the system is based in the level up to which the features described in this document
are implemented in the system.

 UHCL – University of Houston-Clearlake.
 Provided wherever necessary in the document.
 PIN – Personal Identification Number
1.4 References
The SRS document uses the following documents as references:
1.4.1 UHCL Information Security Requirements: To provide security to the system based
on the current security system currently used by UHCL.
1.4.2 The Billing System: To provide the interface between the system being developed and
the billing system currently in use by UHCL to update the member account due as and when
they borrow and return the books.
Patel Vatsal R. [15012021035] 66
1.5 Overview
The SRS will provide a detailed description of the Online Library System. This document will
provide the outline of the requirements, overview of the characteristics and constraints of the
system.
1.5.1 Section 2: This section of the SRS will provide the general factors that affect the product
and its requirements. It provides the background for those requirements. The items such as
product perspective, product function, user characteristics, constraints, assumptions and
dependencies and requirements subsets are described in this section.
1.5.2 Section 3: This section of SRS contains all the software requirements mentioned in
section 2 in detail sufficient enough to enable designers to design the system to satisfy the
requirements and testers to test if the system satisfies those requirements.
Patel Vatsal R. [15012021035] 67

 Product Perspective
The Online Library System is a package to be used by Libraries to improve the

efficiency of Librarians, Library employees and Users. The Online Library System to
be developed benefits greatly the members and the Librarian of University of Houston-
Clearlake. The system provides books catalog and information to members and helps
them decide on the books to borrow from the library. The Librarian can keep the books
catalog updated all the time so that the members (students and the professors) get the
updated information all the time.
The complete overview of the system is as shown in the overview diagram below:
The product to be developed has interactions with the users: Librarian, Members who are
the students and professors of the UHCL.
The product has to interact with other systems like: Internet, Billing System and the UHCL
Information Security System.
Billing System
Librarian
UHCL Information
The Proposed Online Library Security System
Patel Vatsal R. [15012021035] 68
Management System
Internet
Users
Overview of the proposed system
 Product Functions
The Online Library System provides online real time information about the books available
in the Library and the user information. The Product functions are more or less the same as
described in the product perspective. The functions of the system include the system
providing different type of services based on the type of users [Member/Librarian].
 The member should be provided with the updated information about the books
catalog.
 Provisions for the members to borrow the books they want, if all the other required
rules hold good.
 The member is given a provision to check his account information and change the
account information any time in the given valid period.
 The members are provided with the books available roster and allowed to choose
the books, which they want to use in the coming up days.
 The librarian can get the information about the members who have borrowed or
returned the books.
 The librarian is provided with interfaces to add/delete the books available in the
book catalog.
 The members when complete the book borrowing or returning process, the due to
be paid by the member must be calculated and the information about the member
and the due amount is sent to the university billing system.
 The system uses the University information security requirements to provide the
login facility to the users.
 User characteristics
The users of the system are members, librarian of the university and the administrators who
maintain the system. The members and the librarian are assumed to have basic knowledge
of the computers and Internet browsing. The administrators of the system to have more
knowledge of the internals of the system and is able to rectify the small problems that may
arise due to disk crashes, power failures and other catastrophes to maintain the system. The
proper user interface, users manual, online help and the guide to install and maintain the
Patel Vatsal R. [15012021035] 69

system must be sufficient to educate the users on how to use the system without any
problems.
 Constraints
 The information of all the users must be stored in a database that is accessible by the
Online Library System.
 The university information security system must be compatible with the Internet
applications.
 The Online Library System is connected to the university computer and is running all
24 hours a day.
 The users access the Online Library System from any computer that has Internet
browsing capabilities and an Internet connection.
 The billing system is connected to the Online Library System and the database used by
the billing system must be compatible with the interface of the Online Library System.
 The users must have their correct usernames and passwords to enter into the Online
Library System.
 Assumptions and dependencies

 The users have sufficient knowledge of computers.
 The University computer should have Internet connection and Internet server
capabilities.
 The users know the English language, as the user interface will be provided in English
 The product can access the university student database
Patel Vatsal R. [15012021035] 70

3. Specific Requirements
This section describes in detail all the functional requirements.
3.1 Functionality
3.1.1 Logon Capabilities
The system shall provide the users with logon capabilities.
3.1.2 Mobile Devices

The Online Library System is also supported on mobile devices such as cell phones.
3.1.3 Alerts
The system can alert the Librarian or the administrator in case of any problems.
3.2 Usability
 The system shall allow the users to access the system from the Internet using HTML or it’s
derivative technologies. The system uses a web browser as an interface.
 Since all users are familiar with the general usage of browsers, no specific training is
required.
 The system is user friendly and self-explanatory.
3.3 Reliability
The system has to be very reliable due to the importance of data and the damages incorrect or
incomplete data can do.
3.3.1 Availability
The system is available 100% for the user and is used 24 hrs a day and 365 days a year. The
system shall be operational 24 hours a day and 7 days a week.
3.3.2 Mean Time Between Failures (MTBF)

The system will be developed in such a way that it may fail once in a year.
Patel Vatsal R. [15012021035] 71
3.3.3 Mean Time to Repair (MTTR)

Even if the system fails, the system will be recovered back up within an hour or less.
3.3.4 Accuracy
The accuracy of the system is limited by the accuracy of the speed at which the employees of
the library and users of the library use the system.
3.3.5 Maximum Bugs or Defect Rate
Not specified.
3.3.6 Access Reliability
The system shall provide 100% access reliability.
3.4 Performance
3.4.1 Response Time
The Splash Page or Information page should be able to be downloaded within a minute using a
56K modem. The information is refreshed every two minutes. The access time for a mobile
device should be less than a minute. The system shall respond to the member in not less than
two seconds from the time of the request submittal. The system shall be allowed to take more
time when doing large processing jobs.
3.4.2 Administrator/Librarian Response

The system shall take as less time as possible to provide service to the administrator or the
librarian.
3.4.3 Throughput
The number of transactions is directly dependent on the number of users, the users may be the
Librarian, employees of the Library and also the people who use the Library for checking-out
books, returning books and checking online library account.
3.4.4 Capacity
The system is capable of handling 250 users at a time.
3.4.5 Resource Utilization
The resources are modified according the user requirements and also according to the books
requested by the users.
3.5 Supportability
The system designers shall take in to considerations the following supportability and technical
limitations.
3.5.1 Internet Protocols
The system shall be comply with the TCP/IP protocol standards and shall be designed
accordingly.
Patel Vatsal R. [15012021035] 72
3.5.2 Information Security Requirement

The system shall support the UHCL information security requirements and use the same
standard as the UHCL information security requirements.
3.5.3 Billing System Data Compatibility

The member balance amount that will be calculated and sent to the billing system shall be
compatible with the data types and design constraints of the billing system.
3.5.4 Maintenance
The maintenance of the system shall be done as per the maintenance contract.
3.5.5 Standards
The coding standards and naming conventions will be as per the American standards.
3.6 Design Constraints

3.6.1 Software Language Used
The languages that shall be used for coding the Online Library System are Active Server Pages
(ASP), Java Servlets, Java Server Pages (JSP), HTML, JavaScript, and VBScript. For working
on the coding phase of the Online Library System, the Internet Information Services (IIS)
Server needs to be installed.
3.6.2 Development Tools

Will make use of the available Java Development Tool kits for working with Java Beans and
Java Server Pages.Also will make use of the online references available for developing
programs in ASP, HTML and the two scripting languages, JavaScript and VBScript.
3.6.3 Class Libraries
Will make use of the existing Java libraries available for JSP and Servlets. Also we need to
develop some new libraries for the web-based application. Also will develop new programs
using ASP and scripting languages.
3.7 On-line User Documentation and Help System Requirements
Online help is provided for each of the feature available with the Online Library System. All
the applications provide an on-line help system to assist the user. The nature of these systems is
unique to application development as they combine aspects of programming (hyperlinks, etc)
with aspects of technical writing (organization, presentation). Online help is provided for each
and every feature provided by the system.
The User Manual describes the use of the system to Librarian and Employees. It describes the
use of the system on mobile systems. The user manual should be available as a hard copy and
also as online help.
An installation document will be provided that includes the installation instructions and
configuration guidelines, which is important to a full solution offering. Also, a Read Me file is
Patel Vatsal R. [15012021035] 73

typically included as a standard component. The Read Me includes a “What’s New With This
Release” section, and a discussion of compatibility issues with earlier releases. Most users also
appreciate documentation defining any known bugs and workarounds in the Read Me file.
Since the installation of Online Library System is a complex process, our experts will do it. So
an installation Guide will not be provided to the user.
3.8 Purchased Components

The System Administrator will need to purchase the license for IIS Server. Mostly it is
available with Windows Environment. So the system need not purchase any licensing products.
3.9 Interfaces
3.9.1 User Interfaces
Will make use of the existing Web Browsers such as Microsoft Internet Explorer or Netscape.
The user-interface of the system shall be designed as shown in the user-interface prototypes.
Logon Screen Prototype:
Home Page Of UHCL Library Prototype:
Patel Vatsal R. [15012021035] 74

Member Registration Screen:
Patel Vatsal R. [15012021035] 75

Member Information once Logged in:
Main Search Page of Library Catalog:
Patel Vatsal R. [15012021035] 76

3.9.2 Hardware Interfaces

The existing Local Area Network (LAN) will be used for collecting data from the users and
also for updating the Library Catalogue.
3.9.3 Software Interfaces
A firewall will be used with the server to prevent unauthorized access to the system.

The Online Library System will be connected to the World Wide Web.
3.10 Licensing Requirements

The usage is restricted to only University of Houston-Clearlake Library who is purchasing the
Online Library System from Library InfoSys and signs the maintenance contract.
3.11 Legal, Copyright, and Other Notices
Online Library System is a trademark of Library InfoSys and cannot be used without its
consent.
3.12 Applicable Standards
The ISO/IEC 6592 guidelines for the documentation of computer based application systems
will be followed.
Patel Vatsal R. [15012021035] 77

4. Supporting Information
The use-case storyboards or the user-interface prototypes are not available. The appendices are
not to be considered as part of the requirements.
Patel Vatsal R. [15012021035] 78

(3) Online Shopping System
Table of Contents
1. Introduction.................................................................................................................81
1.1 Purpose....................................................................................................................81
1.2 Document Conventions............................................................................................82
1.3 Intended Audience and Reading Suggestions .........................................................83
1.4 Project Scope............................................................................................................ 83
2. UML Diagrams............................................................................................................84
Patel Vatsal R. [15012021035] 79

Patel Vatsal R. [15012021035] 80

1. Introduction
1.1 Purpose
Online Shopping Software main purpose is to provide customers with the possibility to perform online
purchases on products already on store. Customers are identified properly and are able to perform
online transactions using three kind of methods: either using credit card or banking documents, but
also through PayPal account. Online Customers are divided on two categories upon user account
types: basic and business.
Basic accounts beside other attributes contain a specific one named Fidelity which deals with the
number of years the user has been joining the online shop. On the other hand is business plan which is
characterized uniquely by the Volume attribute that is the total amount of transactions performed
within the online shop. The customer is able to operate throughout the system after properly
authenticated. He is able to create a cart and add products to it or delete them as well. Then he decides
whether he might go on with the checkout operation and complete the purchase. Once the user decided
upon the plan to use: basic or business, he is given the alternatives to pay through the previously
mentioned methods accordingly. Once the purchase is confirmed by the customer and admitted by
shop commission, customer details come into use in order to define the shipping address and other
supplementary information. Customer is given the possibility to view and print some information
regarding his activity on the shop. For instance he can print the number of purchases completed by
him from eh beginning of the current year.
He can print the status of previously performed purchases and decide whether to cancel or not a
specific purchase if it is still in “Not available” status.
During the process of product selection and addition to cart specifying correspond quantity the system
automatically checks if the product is available within the quantity or not. In case of negative response
the system generates a request to the product supplier. Stated in short terms this is the overall situation
on hand.
1.2 Document Conventions

Specific terminology is used throughout the specification of the system.
User Profile: stands for the profile of the customer (person) opened in the software. One person can
have multiple profiles using different emails. A profile can be linked to none or one account type.
Person: defines an real person who has an identity defined by class attributes. A person can have
multiple profiles and consequently multiple accounts. For instance a person can have a basic and a
business account.
Account: defines an entity that enables the user to operate throughout the system and perform
purchases. It is the super class of two other classes respectively: Basic and Business which extend the
super class.
Payment: defines an entity that enables an account to perform a payment transaction using one of
alternative methods.
Patel Vatsal R. [15012021035] 81
Purchase: defines an entity that encapsulates a purchase object. A purchase is specified by a unique
number and status thus using the Status class.
Cart: stands for a container that holds selected products during the session and is included by a
purchase.
Cart Products: as the name itself defines an entity that makes possible operations of addition, deletion,
and selection of products in and from the cart.
Bank Transfer: stands for a payment method when using a basic plan.
Credit Card: stands for a payment method using a credit card when using a basic plan.
PayPal: defines a payment method when using business plan. In this case it includes a PayPal service
using a previously configured PayPal account.
1.3 Intended Audience and Reading Suggestions

The system is worth using by an audience that is interested on buying online products and benefit from
facilities offered in such a case. Facilities are: saving time, saving money by selecting the best offer,
comfort circumstances, safety of money transactions etc...
1.4 Project Scope

The scope of this project is to design and develop a system that is necessary to shops when they need
to operate online, sell products online. The shop can keep an electronic history of all purchases and
transactions. This gives more control over the operations that the company offers. The system can be
adapted to a range of shops from simple small ones to big markets. A shop can outsource the function
of shipping to another external company or can handle it itself. Project scope also includes financial
transactions that call for other third party services like PayPal. Project scope from customer
perspective, limits the range of customers to only those who have internet connation on some form and
have a bank account in hand.
The aim of this project is to promote an efficient, user-friendly, time-fashionable, safe way for
customers to bye and receive products without being physically at a shop thus using virtual money.
Patel Vatsal R. [15012021035] 82

2. UML Diagrams
2.1 Use Case Diagrams
Online Shop from user perspective use case
Description:
This use case provides the viewpoint for the whole process from user perspective. Customer sees only
the necessary functions that the system must define.
Actors: Online Customer
Preconditions: Customer must have a bank account.
Patel Vatsal R. [15012021035] 83
Base Case:
1. Customer must log in and authenticate
2. Customer must choose the type of purchase to perform
3. Customer can view and select products
4. Customer can perform a purchase
5. Customer can cancel a purchase
6. He can view additional information regarding the purchase
Alternative Flows
None
Post conditions: Customer performs transactions based on defined accounts.
Additional Info/Issues: None
View Products Use Case
Patel Vatsal R. [15012021035] 84

Description:
View products use case describes the whole operations a user can perform on a product currently on
the store. It also describes an exceptional case when a product is not available on the quantity required.
Preconditions: Customer must login and authenticate firstly
Base Case:
1. Customer can view the products
2. he can select the products
3. he can add the products to cart
4. he can define quantities on ordered products
5. system checks whether the quantity is satisfied or not
6. system responds to client with approving the purchase
7. system generates an automatic order to products supplier
8. Alternative Flows
None
Post conditions: Customer performs transactions based on defined accounts.
Additional Info/Issues: None
Make Purchase Use Case
Description:
Patel Vatsal R. [15012021035] 85
This use case defines the cycle when customer makes a purchase. When deciding to perform a
purchase the customer proceeds to the checkout operation and then to the payment method and
according verifications.
Preconditions: Customer must confirm the final form of the cart and products already in.
Base Case:
1. Customer must complete with the cart
2. he is taken to the checkout step
3. he is forwarded to a payment method based on the purchase type that he decided beforehand.
Alternative Flows:- The customer may cancel the purchase when it is in “Not Available yet” status.
Post conditions: Customer performs transactions based on defined account.
Additional Info/Issues: Includes third party accounts like PayPal or supporting bank documents.
Payment Use Case
Description:
Payment use case deals with the cycle of performing a payment through on of the methods mentioned.
Preconditions: Customer must authenticate and decide upon the type of purchase to commit.
Patel Vatsal R. [15012021035] 86
Base Case:
1. Customer decides on the type of method to pay using either credit card or providing bank
documents in case of basic type of purchase.
2. he decides upon PayPal method to pay if he decides on business purchase type.
3. each of the methods forward the user to the corresponding sites where he can enter credit card info,
or upload a document or confirm a PayPal account.
Alternative Flows :None
Post conditions: Customer performs transactions based on defined account.
Additional Info/Issues: Includes third party accounts like PayPal or supporting bank documents.
View Purchase Use Case
Description:
This use case describes processes when the customer can view and print information for purchases he
has already performed.
Preconditions: Customer must authenticate.
Base Case:
1. Customer can view the status of the purchases already submitted.
Patel Vatsal R. [15012021035] 87

2. If the status is “Not available yet” the user has the choice to cancel such a purchase.
3. he can list, view and print purchases from eh beginning of the year also.
Alternative Flows: None
Post conditions: None
4.Social Networking Application
Table of Contents
Contents
1.Introduction 89
1.1Purpose 89
1.2Document Conventions 89
1.3 Intended Audience 89
1.4 Project Scope 89
2.Overall description 90
2.1 Product Perspective 90
2.2 Product Functions 90
2.3 Operating Environment 90
2.4 Design and Implementation Constraints 90
2.5 Assumptions and Dependencies 90
2.6External Interface Requirements 91
2.6.1Flow Diagram 91
2.6.2Activity Chart for Social Networking Website 92
2.6.3Communications Interfaces 92
2.7 System Features 92
Main Features 92
2.8 System Feature 93
3.Other Requirements 97
3.1 System Development Requirements 97
3.1.1Description 97
3.1.2Requirements 98
4.Uml Diagram 99
4.1Design Phase 99
4.1.1Use case diagrams. 99
5.Database Relationship 102
Patel Vatsal R. [15012021035] 88

1 Introduction
1.1 Purpose
This software requirement specification (SRS) document describes the functional and nonfunctional
requirements of our social networking application. In the project’s later phases, such as system design,
database design, implementation and testing, this document should be referred as functional model of
the system.
1.2 Document Conventions

All system development activities should follow the final version of this document. Any discrepancy
that found during in later phases should be modified subject to SRS. However, this document may be
subject to change dependent on the decision of Conf. dr. ing. MihaiHoriaZaharia.
1.3 Intended Audience

1. Software developer
2. Administrator
3. Security Analysts
4. Users of the system
5. Maintenance Team
1.4 Project Scope
The social networking application is designed to make social life more active and stimulating. The
social network can help you maintain existing relationships with people and share pictures and
messages, and establish new ones by reaching out to people you've never met before.
This application also provides the features of blogging. The main idea behind blogging is to share your
thoughts with all your friends which can be read by all the users using the application. This blog can
be handled by the user as he wants. It also provides the features of adding videos and photos.
Patel Vatsal R. [15012021035] 89

2 Overall Description
2.1 Product Perspective

This social networking application challenges to give a better socializing and secure System at the
same place.
2.2 Product Functions

 Authorization: Entire authority of the system is to the administrators of the system.
 User authentication: A newly created user is authenticated against the given email address.
 User form: The system offers a simple, attractive, user friendly user interface easily
understandable by the users of the system. Entries of the user form are under the authority of
the administrator only. Some of the entries in the form are mandatory in order to authenticate
the user, describe the user thoroughly etc.
 Administrator Functions:
1. Authentication of the users after registration.
2. Mails to the users regarding the approval as a registered user, disapproval
3. Mentioning the appropriate reasons of an action.
4. Approving the update of the account details of the users.
5. Notification to the end users regarding proposals.
6. Mentioning the security measures for the system’s safety.
7. Deleting an account/user from the system’s databases on request of the user or misconduct.
 Application Information:
1. Displaying History: Mentions the history about the system such as founders of the system.
2. Contact details: Contact details.
3. Advertisements: Application will contain advertisements related to all various products
present for selling.
2.3 Operating Environment

 Operating System Support:
1. WINDOWS 98/XP/VISTA/7/8
2. Mac OS
3. Linux
 Internet Connectivity Required

2.4 Design and Implementation Constraints
1. Security:The system should take care of hacks like SQL injection. It should also not expose any
sensitive information to normal users.
2. Fault Tolerance: Data should not become corrupted in case of system crash or power failure.
Patel Vatsal R. [15012021035] 90

2.5 Assumptions and Dependencies

1. Central server of the system must be able to handle all the incoming requests simultaneously.
2. Back up of the databases in case of hardware failure, disaster, natural calamities.
3. No data loss in case of handling of the system by the administrators or the system related personnel
2.6 External Interface Requirements
2.6.1 Flow Diagram
Fig 1: Flow Diagram

Patel Vatsal R. [15012021035] 91
2.6.2 Activity Chart for Social Networking Website

To use the social networking system efficiently the user needs to have an internet connection with a
personal computer running with an Operating System, like Windows or Linux, that has a JVM
installed.
2.7 System Features

The social networking application is intended for connecting people. In addition to this feature the
users have the facility to add videos and photos. This website gives a lot of features all at one place.
Main Features
FE-1: Create/Delete Profile
Patel Vatsal R. [15012021035] 92

FE-2: Update account

FE-3: Get forgotten password through Email
FE-4: Message system (write on others wall/Delete own message from others wall/delete message
from own wall)
FE-5: Search members /add as member/delete member
FE-6: Blog system (add/modify/delete posts)
FE-7: Add comment on others blog post
FE-8: Post and search classifieds.
FE-9: Add comments on classifieds.
FE-10: User login/Logout
*FE-111:Add/ Delete/Modify Photo Galleries
*FE-122: Add/ Delete/Modify Video Galleries
*FE-133: Update/add/delete company information, Site administration to manage site content like
Admin Users Members, Pictures, Videos, Music, Blog, Categories, Blog ,Posts, classifieds Categories,
block users (by administrator)
2.8 System Feature

Creating a new account
1. User is allowed to create his own profile.
2. According to the specifications required by the administrator, the user creates his own profile and
submits it to the system.
Deleting the account
1. The user can delete his/her account.
Updating the account
1. The user is allowed to update his/her account.
2. The administrator updates the profile accordingly.
3. The user is not allowed to keep any mandatory fields blank while updating. e.g. Name, Last name,
email Id etc.
Get forgotten password via Email
1Features with an asterisk (*) means this feature will be implemented if time permits.
Patel Vatsal R. [15012021035] 93

In case of forgotten account password, the user can receive a mail containing a verification code to
authenticate the user.
Message system
User can send and get message to his message box.
Search members /add as member/delete member

User can search, add and delete members in his list to widen his network
Uploading Photographs
The user has a facility to upload and share his photographs.
Adding YouTube videos

The user can add videos from YouTube and share with people
Blogging
The user has the right to write posts in his blog and publish them.
Patel Vatsal R. [15012021035] 94

3 Other Requirements
3.1System Development Requirements
3.1.1 Description
This section describes what resources will be utilized in the development and use of the software.
3.1.2 Requirements
Req # Description
REQ-SR1 The database backend system in use will be MYSQL.
REQ-SR2 The Front-end and middle logic tools and technology will be
written using Java
REQ-SR3 Code will be stored on the Google Code SVN repository.
REQ-SR4 Development environment will be the Eclipse Integrated

Development Environment.
REQ-SR5 The database and other dependences will use Tomcat as a web
server.
REQ-SR6 The project will use Iterative model (Scrum Framework) and
Agile Methodology.
REQ-SR7 Bugzilla will be for bug tracking
3.1.2.1 Agile Methodology
Patel Vatsal R. [15012021035] 95

3.1.2.2Iterative Model
3.1.2.3 Scrum Framework
Patel Vatsal R. [15012021035] 96

4 Uml Diagram
4.1 Use case diagrams.
4.1.1 Login/Registration
<<include>>
Get email to confirm registration
Regester for login
<<include>>
Login Validate user
User
<<include>>
Get password email
Request for forgetted passward
<<include>>
4.1.2 Home Page
Patel Vatsal R. [15012021035] 97

4.1.3 Wall Page
Delete message from own wall
User
Reply to Message
4.1.4 Blog Page
Add/Modify/Delete Post to blog
Add/Delete comment on blog post

User
Patel Vatsal R. [15012021035] 98

4.1.5 Profile Page
Add/Modify/delete profile info
User
4.1.6 Search Friend Page
Get List of Searched Friend
Add friend
User
Write message on friends wall
Delete own message from friendrs wall
Patel Vatsal R. [15012021035] 99

4.1.7 Friend List Page
View Profile Info
Write message on friends wall
Delete own message from friendrs wall

User
Delete friends
Add/Delete comment on blog post
4.1.8 Photo Page
Add/Delete photo
User
4.1.9Video Page
Add/Delete video Link
User
Patel Vatsal R. [15012021035] 100

Patel Vatsal R. [15012021035] 101

5.Database Relationship
Patel Vatsal R. [15012021035] 102

5.2 Programmer’s Point of View

The earlier section covers the schema of the project with the design of the tables being created.
For all pages we are going to use JSP as frontend and MySQL as backend.
Login Page:
We are going to verify the login credentials from user table. If user enters valid information he/she
will get logged in and home page will get displayed. If person is new user he will select register page
option.
Thispage will take basic user details and after checking all the values ( eg. Empty values, Invalid
Password etc. ) It will insert all the values in the register table. After successful inserts, user will get
directed to login page.
Home Page:
On the home page, we will have friends list displayed on the right side of page and all these values
will be retrieved from friends table. This page will also have links to pages like videos, blogs etc. The
middle part of home page will have entries displayed from user table.
Edit profile page:
Once the user has logged on, he can change the profile details by using the edit profile page. When the
user reaches this page, data will be obtained from the user table and displayed in the respective text
boxes. The user could change these details if he wishes to do so. After he finishes editing the details he
can click the update button. When this button is clicked the new details will be updated in the user
table. These new details will be selected from the user table during future references.
Video Page:
For video page we are going to use YouTube API. We will have search video option. After searching
the videos, option will be provided to user for adding the video to his/her profile. For this functionality
will add the ‘Embed’ details for that video will get added to video tables. All the profile videos will
get displayed on the right hand side of the page.
Photo Page:
On the image page we will have browse button. User will select the image file from his local machine
and click on add Image. After adding the image, the image will be stored in the images folder on the
server. And the URL of that image will be stored in the images tables. Below the browse button, all
the images added for the current user will get displayed from images table.
Patel Vatsal R. [15012021035] 103

Blogging Page:
The blogging page would give you create new blog post form. The user will enter the title of
the blog post and the contents of the blog post in the respective text boxes. After entering the
user will click the create button. When the create button is clicked the title of the blog post and
the contents of the blog post will be saved in the blog table. All previously stored blog posts
will be retrieved from the blog table and displayed below to create new blog form.
Patel Vatsal R. [15012021035] 104

(5) Online Matrymony System
Table of Contents
Contents
1. Introduction ………………………………………………………………………………………..103
1.1 What is Matrimonial Web Application…………………………………………………...…103
1.2 Purpose of applications…………………………………………………………………...…..103
1.3 Scope……………………………………………………………………………………...……104
2. Overall description…………………………………………………………………………………105
2.1 About matrimonial web application…………………………………………………............105
2.2 SOFTWARE MATRICES…………………………………………………………..………..107

2.2.1 Estimation:-…………………………………………………………………..………….107
2.2.2 Application Authoring And Design Tool :-………………………………..…………..107
3. Analysis……………………………………………………………………………….…………….109
3.1 DATA FLOW DIAGRAM……………………………………………….…………………..109

3.1.1 Level 0………………………………………………………….……………………….109
3.1.2 Level 1……………………………………………………….………………………….110
3.1.2.1 Data Flow Diagram For User……………………….……………………………...111
3.1.2.2 Data Flow Diagram For Admin………………….…………………………………111
3.2 USE CASE DIAGRAM………………………………..…………………………………….112

3.2.1 Admin Use Case :-……………………………..………………………………………..112
3.2.2 User Use Case :-…………………………..…………………………………………….112
3.3 SEQUENCE DIAGRAM……………………………………………………………………..113

3.3.1 Sequence diagram for Registration….…………………………………………………..113
3.3.2 Sequence diagram for Edit Profile….…………………………………………………...114
3.3.3 Sequence diagram for Search…….……………………………………………………...115
3.4 ACTIVITY DIAGRAM…………….………………………………………………………....116

3.4.1 I/P Validation………………….………………………………………………………......116
3.4.2 Display Records…………….……………………………………………………………..117
3.5 CLASS DIAGRAM……….…………………………………………………………………...118

3.5.1Admin class diagram……………………………………………………………………....118
3.5.2User Class Diagram………………………………………………………………………..118
Patel Vatsal R. [15012021035] 105
3.5.3Login Class Diagram………………………………………………………………………118
4. Conclusion………………….………………………………………………………………………..120
5. Future Extension………….…………………………………………………………………………121
1. INTRODUCTION
1.1 What is Matrimonial Web Application?

The main objective of Matrimonial Web Application is to provide Grooms and Brides with excellent
matchmaking experience by exploring the opportunities and resources to meet true potential partner.
Keeping our objective in mind, we have created a world renowned online matchmaking services that
will touch the souls of millions of people all over the globe.
1.2 The purposes of the Matrimonial Web Application are:
 The main purpose of this application is to facilitate matchmaking business by applying the
information in the field.
 It helps the user by providing profiles of perspective “Bride” or “Groom” and other
information regarding them online.
 User can get information regarding their dream life partner at his/her home at his/her
convenience.
 This application also provides a search utility which helps those users who have a certain
criteria of qualities in mind to make online matrimonial easier.
 Since internet is a pivot for modern business, our project which is based on internet paves a
path for modernization in trade.
For This Application, we will provide following capabilities:
(1) Admin Module.

(2) User Registration Module
(3) Image Uploading module
(4) Creating album
(5) Sending Express Interest
(6) Sending Personal messages
Patel Vatsal R. [15012021035] 106

(7) Marriage Loan

(8) Paid Membership
(9) Search Module.
(10) Quick Tour.
1.3 SCOPE
Matrimonial website which will provide platform to a lot of Bride/Groom for finding perfect match.
There are different sectors like Registration, Partner , Search, etc. So the Bride/Groom can get their
interest for find their partner. Bride/Groom can directly search Partner according to their required
criteria.
The Bride/Groom can use match By Email functionality so he/she can get directly E-mail alert for the
match which fulfill their required criteria.
Patel Vatsal R. [15012021035] 107

2.1 ABOUT MATRIMONIAL WEB APPLICATION
The main objective of Matrimonial Web Application is to provide Grooms and Brides with excellent
matchmaking experience by exploring the opportunities and resources to meet true potential partner.
Keeping our objective in mind, we have created a world renowned online matchmaking services that
will touch the souls of millions of people all over the globe.
Matrimonial Web Application will allow a new user to register and after successfully registration user
can get email confirmation, after completing registration users profile will be visible to other users.
There are different sectors like Registration, Partner , Search, etc. So the Bride/Groom can get their
criteria. The Bride/Groom can use match By Email functionality so he/she can get directly E-mail
alert for the match which fulfill their required criteria.
For This Application, we will provide following capabilities:
(a) Admin Module.

The main functions of admin of are as mentioned below.
1) Login
2) Report generation
 Report of all members
 Report of free members and paid members
 User management
3) Logout
(b) User Registration Module.
Patel Vatsal R. [15012021035] 108

In this module when user fill-ups first three registration form user will get a member id and
will also get conformation message on his/her Email id.
After getting member id user will use his/her member id to login, and user can modify his/her
profile, fill-up remaining form of registration, image upload, create album .
(c) Image Uploading module.
User can change his/her photo, Image uploading is done after registration only, so user must
have member id for image uploading.
(d) Creating album.
User can create album.
(e) Search Module.
This five types of search available for user..
 Advance Search,
 Quick Search,
 Search by City,
 Search by Id,
 Search by Profession,
(f) Sending Express Interest.
Here after searching the profile user can send a express interest to a profile of his liking
.The messages here will be pre-defined here .
(g) Sending Personal messages.
Here after searching the profile user can send a Personal Message to a profile of his liking .For
this functionality user must be a paid member.
(h)Marriage Loan.
Patel Vatsal R. [15012021035] 109
Here user can apply for marriage loan .For this to happen user have to fill up the form for loan
specifying his need for loan and loan amount .
(i) Paid Membership.
Some of the facilities can only be done by only paid members .And they are like Send a
personal message ,viewing album of user, viewing contact information.
(j) Profile Management Module.
After login user will be redirected to the page containing his information .User can edit ,update
and delete the profile if no longer he wants to retain it .
(k) Quick Tour.
This is a module that contains the flow of the website .Here user can have a idea how he can
commit himself in the website.
(l) Directory.
This is a module that contains the details like hotels, beauticians .Here user can have best
options for appropriate category to chose among them.
2.2 SOFTWARE MATRICES
2.2.1 Estimation:-
In Web engineering, the metrics have three goals:
1 To provide the indication of the quality from the technical point of view.
2 To provide the basis for effort estimation.
3 To provide an indication of the success from the business point of view.
2.2.2 Application Authoring And Design Tool :-
Patel Vatsal R. [15012021035] 110

Suggested measure Description
Structuring effort Time to structure Web App and/or

device architecture.
Interlinking effort Time to interlink pages to build the Apps.
Interfacing planning Time taken to plan Web Application interface.
Interface building Time taken to implement Web Application interface.
Link-testing effort Time taken to test all links in Web Application.
Media-testing effort Time taken to test all media in Web
Application.
Total effort Structuring effort + Interlinking effort
+ Interface Planning + Interface Building
Patel Vatsal R. [15012021035] 111

3. ANALAYSIS
3.1 DATA FLOW DIAGRAM
3.1.1 Level 0
Patel Vatsal R. [15012021035] 112

3.1.2 Level 1
3.1.2.1 Data Flow Diagram For User
Patel Vatsal R. [15012021035] 113

3.1.2.2 Data Flow Diagram For Admin
Patel Vatsal R. [15012021035] 114

3.2 USE CASE DIAGRAM

3.2.1Admin Use Case :-
Admin can Add or Update

Add/Update
the records
Patel Vatsal R. [15012021035] 115
Records
Admin can send the mail to

Sending Mail the customer
3.2.2User Use Case :-
User can register

Registration
himself/herself in the
system
User can login to the system

Login
User can edit his/her

Edit Profile profile.
User can search the record

Searching for male/female.
3.3 SEQUENCE DIAGRAM

3.3.1 Sequence diagram for Registration
Patel Vatsal R. [15012021035] 116

Sequence Diagram For Registration:-
:User :Home :Registration :Registration :Registration

:Profile :Database
personal physical socio-occupation
click on registration fill-up data fill-up physical data store to database
profile is created now user can login by user-id
login page
login using userid check username and password

and password
username and password is valid or not valid

not valid
valid username and password
wellcome user now you can edit/update your profile
3.3.2 Sequence diagram for Edit Profile
Patel Vatsal R. [15012021035] 117

Sequence Diagram For Edit Profile:-
:User :Profile :Registration :Photoupload :database
login with correct

username and password
click on edit profile
update imformation
give remaining registration screen
fillup form and click on update store to database
profile updated
click on photoupload
browes photo
click on upload
photo uploaded
Patel Vatsal R. [15012021035] 118

3.3.3 Sequence diagram for Search
Sequence Diagram For Search:-
:User :Search :Database
click on search
search option
select option
give form according

search selection
Fill up information
required in given form
search according
click on search
given information
give result
Patel Vatsal R. [15012021035] 119

3.4 ACTIVITY DIAGRAM
3.4.1 I/P Validation
[Prompt For Correcrion]

Enter I/P Data
[Data Valid] [Data Invalid]
Valid Data From User Invalid Data Entered by User
Patel Vatsal R. [15012021035] 120

3.4.2Display Records
Fetch Record from Database
Display Data on form No Data in to Database
Patel Vatsal R. [15012021035] 121

3.5 CLASS DIAGRAM
3.5.1 Admin class diagram:-
3.5.2 User Class Diagram
Patel Vatsal R. [15012021035] 122

3.5.3 Login Class Diagram
Patel Vatsal R. [15012021035] 123

Patel Vatsal R. [15012021035] 124

4. Conclusion
Matrimonial Web Application is to provide Grooms and Brides with excellent matchmaking
experience by exploring the opportunities and resources to meet true potential partner.
There are different sectors like Registration, Partener , Search, etc. So the Bride/Groom can get their
criteria. The Bride/Groom can use match By Email functionality so he/she can get directly E-mail
alert for the match which fulfil their required criteria. It helps the user by providing profiles of
perspective “Bride” or “Groom” and other information regarding them online.
Matrimonial web application provide facility like quick tour.this is a module that contains the flow of
the website .Here user can have a idea how he can commit himself in the website.
Matrimonial web application provide facility to change preference about partner.
This application provide facility like edit profile, update photo and delete photo, hide profile, create
album, send express interest, send personal message, apply for loan to the user.
Patel Vatsal R. [15012021035] 125

5. Future Extension
 It is possible to provide the web space to the users for creating his portal.
 It is possible to create our own mail server.
 It is possible to create chat server so that user can communicate with each other.
 It is possible to provide facility like create video album.
Patel Vatsal R. [15012021035] 126

Student Information Management System

Requirements Specification
Patel Vatsal R. [15012021035] 127

Table of Contents
1. Introduction 12925
1.1 Purpose 12925
1.2 Scope 12925
1.4 References 13025
1.5 Overview 13026

2.1 Product Perspective 13126
2.2 Product Functions 11316
2.3 User Characteristics 11316
2.4 Assumptions and Dependancies 11327
3. System Requirements 127

3.1.1 Functional Requirement 1 (FR) – Transcript Requests 127
3.1.2 Functional Requirement 2 (FR) – Centralized Location 127
3.1.3 Functional Requirement 3 (FR) – Records Employee Interface 127
3.1.4 Functional Requirement 4 (FR) - Viewing Account Balance 127
3.2 Usability 127
3.2.1 Usability Requirement 1 (FR) - Single Sign-on 128
3.2.2 Usability Requirement 2 (FR) – More Detailed and Concise Documentation for Grades 128
3.2.3 Usability Requirement 3 (NFR) – Account Management 128
3.2.4 Usability Requirement 4 (NFR) – Reports Information 128
3.2.5 Usability Requirement 5 (NFR) – Web Accessibility 128
3.2.6 Usability Requirement 6 (NFR) – Intuitive Interface 129
3.2.7 Usability Requirement 7 (NFR) – Ease of Use 129
3.3 Reliability 129
3.3.1 Reliability Requirement 1(NFR) – Crash Handling 129
3.3.2 Reliability Requirement 2 (NFR) – Effective Recovery 129
3.4 Performance 129
3.4.1 Performance Requirement 1 (NFR) – Load and concurrency 129
3.4.2 Performance Requirement 2 (NFR) – Dealing with large quantities of data 130
3.5.1 Supportability Requirement 1 (FR) – Minimum Access Requirements 130
3.5.2 Supportability Requirement 2 (FR) – System Communication 130
4. Interfaces 130
4.1 User and Software Interfaces 130
Patel Vatsal R. [15012021035] 128

Requirements Specification
1. Introduction
1.1 Purpose
This document describes the software requirements for a web based student information
management system. It is meant to be used to maintain a shared understanding of the
requirements between the developers and the clients of the system.
1.2 Scope
The function of the system is to facilitate student activities such as registration and the viewing
of time tables, transcripts, account balances, and other information. Additionally, it is to be
used by student records administration for viewing and closing transcript requests.

WebView: This is the system used for viewing student records. Tools contained include: view
courses, grades, timetable, address, account balance, account details, transfer credit details,
unofficial transcript, admissions inquiry, records inquiry, and address change.
WebReg: This is the system used for actual course registration. PinChg is accessed through this
system. Students can us this system to add or drop courses, or list the available sections of a
course.
WebTT: This is the system used for course listings and availability.
PinChg: This is the utility used for changing student PIN codes
PIN: Personal identification number. It is used for authentication to access the system.
Legacy System: This is a database of information regarding student records.
Records Employee: This is an employee who works for the Records office and handles official
transcript requests.
Patel Vatsal R. [15012021035] 129
1.4 References
UVic Web Systems: http://uvic.apparitiondesigns.com/
1.5 Overview
This document is organized into a couple major sections. Section 2 provides an overall
description of the system. Section 3 details the specific requirements of the system.
Patel Vatsal R. [15012021035] 130

2.1 Product Perspective

UVic Web Systems requires the development of a centralized system for facilitating all student
administrative tasks such as registering for courses, managing account balances and transcript
requests. Not only will the system be designed for students, there will be a feature to allow
Records Administration to handle transcript requests. The system will also work with the
existing University database.
2.2 Product Functions
The new web-based system should combine the functionality of the existing WebView,
WebReg, WebTT and PinChg systems.
There should be a single log-on portal with which the user can access all the above systems.
The user would be directed to the appropriate page depending on whether the user is a student
or records staff.
If the user is a student:
 They are directed to a Main page that has links to the other systems. (Course
Registration, Course time-Table, Student Accounts, and Records)
 The Course Registration page will provide course information and allow the user to
register for course as well as view his time-table.
 The Course time-Table page will provide general course information without any need
of registration.
 The Student Accounts page will display a student’s personal and tuition (monetary)
information. It will also contain access to their Netlink account.
 The Records page will display information regarding the student’s academic progress at
UVic and allow interaction with the Records Department at UVic.
If the user is a Records employee:
 The user is directed to a page that allows them to process Student Record related
requests.
2.3 User Characteristics
There are two groups of users using the system:
Students
The students access the system to manage their courses and view their information. Due to the
large size of this group, there is a wide range of technical ability. Ease of learning the system
should be a priority for this user group
Records Employees
The records employees access the system to view pending transcript requests and close them
when they've been completed. As using the system is a specialized part of the records
employee occupation, efficiency of their workflow is the priority.
Patel Vatsal R. [15012021035] 131

2.4 Assumptions and Dependancies

We assume that everyone that uses the system has access to the internet at speeds of 56k or
above.
The system is depended upon by many users therefore it should be able to deal with thousands
of users logging onto the system at any one time.
Patel Vatsal R. [15012021035] 132

3. System Requirements
(FR) = Functional Requirement
(NFR) = Non Functional Requirement
3.1 Functionality
3.1.1 Functional Requirement 1 (FR) – Transcript Requests
The system must allow students to request official transcripts from WebView. All
requests will be sent and managed by the university records database
3.1.2 Functional Requirement 2 (FR) – Centralized Location
The system must encompass the functionalities of WebView, WebReg, WebTT and
PinChg. Rather than having each system as a separate entity, they will be consolidated
into one central system while maintaining the functionality of each system.
3.1.3 Functional Requirement 3 (FR) – Records Employee Interface

The system is specifically intended for Records Employee. It will have a separate log in
page where Records Employee’s can log in with their Netlink id and password. This
connects them with the transcript database. From there, they will be able to fulfil
transcript requests.
3.1.4 Functional Requirement 4 (FR) - Viewing Account Balance

The system will display account outstanding balances. An account balance will be
placed on the interface indicating the amount owned until payment is fulfilled. There
will also be another function within the system that will provide a detailed breakdown
of all fees charged by the University.
3.2 Usability
3.2.1 Usability Requirement 1 (FR) - Single Sign-on
The system checks if the entered student number and password are valid.
Input: Student enters student number and password
Processing: The system checks if the student number is valid and the password is
correct. The system authorizes the student to access their record information if they
entered valid student number and password.
Output:
Patel Vatsal R. [15012021035] 133

- System returns the user to the log in page if the student number or password
is invalid.
- System provides user with options to access different records and do
different functionalities with the system if the student number and password
are correct
3.2.2 Usability Requirement 2 (FR) – More Detailed and Concise Documentation

for Grades
The system will have functionality of producing a more professionally looking
unofficial transcript that can be obtained and used when applying for jobs (mostly for
coop students)
3.2.3 Usability Requirement 3 (NFR) – Account Management

The new system is a combination of old systems namely, WebReg, WebView, WebTT
and PinChg which required separate log in accounts. The new system should function
such that when a user (student) signs into it, it provides them with all the information
combined for the old systems without having to re-log in when they want to change
from one service to the next.
The new system will also allow records employees to log into the system, view and
process transcript requests
3.2.4 Usability Requirement 4 (NFR) – Reports Information

The new system will provide a report that clearly shows what courses the student have
completed and what courses they still need to take. This functionality will be important
in saving students time from looking at the whole timetable of their course.
3.2.5 Usability Requirement 5 (NFR) – Web Accessibility

The new system will be accessible in any computer that is connected to the internet
3.2.6 Usability Requirement 6 (NFR) – Intuitive Interface

The new system will have an interface that is very easy to use and does not require
training to use. It should combine some of the features of the old system so that users
(students) who are familiar with the old system will not have trouble adjusting to the
new system.
The new system should also have an interface that can be useful to records employees
for them to easily process transcript requests. Some of the old records system features
will be included in the new system to help records employees to adjust easily to the
new system.
Patel Vatsal R. [15012021035] 134

3.2.7 Usability Requirement 7 (NFR) – Ease of Use

The new system should have a tool to help students produce their timetable instead of
them spending much time looking at the timetable and manually planning it. This
functionality does not replace the old system of planning the timetable manually but it
is an additional feature that can be used.
3.3 Reliability
3.3.1 Reliability Requirement 1(NFR) – Crash Handling

In the event of a system crash during a transaction, the current transaction will either
completed or not completed. This will be handled by an already existing database.
3.3.2 Reliability Requirement 2 (NFR) – Effective Recovery

The system must effectively recover from a crash within five seconds. For the system
to effectively recover, it must be able to restart a sessions with the user within the time
limit.
3.4 Performance
3.4.1 Performance Requirement 1 (NFR) – Load and concurrency

The system must be able to run without interruption and able to handle thousands of
concurrent requests. It must be able to effectively recover from crashes and other
problems, as it is handling sensitive data. It should be designed in such a way that it can
run on distributed systems.
When brought up in the interview the response from UVic web systems was “Basically
we want the system to handle errors gracefully, like crashes.”
3.4.2 Performance Requirement 2 (NFR) – Dealing with large quantities of data

The developed system will have to deal with large quantities of data and a large number
of users accessing the data at once.
When asked in the interview “In section 6.0 what do you mean by “large quantity of
data”?” the response was “Probably internal data—like timetable information, data
retrieved from the database—input data itself isn’t very big.”
3.5 Supportability
3.5.1 Supportability Requirement 1 (FR) – Minimum Access Requirements

The required system should be available on any system or workstation with a minimum
requirement of 56k internet access.
Patel Vatsal R. [15012021035] 135
When asked “Why do you have a 56K limit?” during the interview process the client
responded with the following comment “We want the system to be able to load up in a
reasonable time, recover with sensitive data, and guarantee it will work so it doesn’t
just have to be broadband access only—more like expanding to support 56k, not
“limited” to 56k.”
3.5.2 Supportability Requirement 2 (FR) – System Communication
The new system should be able to work with the existing system used by the
records system. This should allow the records office to receive transcript
requests.
When asked during the elicitation the response received from UVic Web
systems was “Yes”.
Patel Vatsal R. [15012021035] 136

4. Interfaces
4.1 User and Software Interfaces
Main Access Page/ Welcome Page
The user interface will have a single access portal where the user can sign-in and have access
to the entire system.
If a student signs in, they are taken to the Student Main Page. If a Records employee signs in,
they are taken to a Records Main Page.
The Records main page would allow a records employee to process Official Transcript orders.
The Student main page would have links or tabs to the various other systems like Course
Registration, Course Time-tables, Student Accounts, Transcripts and Records.
The pages are detailed below:
Course Registration Page
The Course Registration Page would show the courses the user is currently registered in and
allow the user to register for next term courses if they are eligible. It will not display past
courses or grades.
When a user chooses the ‘Register for Courses’ option, they are taken to a page that has a list
of courses offered that semester and an empty time-table. When the user selects a course, the
course information like class size, current enrollment information (i.e how many seats have
been filed, how many seats are available), Instructor is displayed in text form. The course also
appears in the time-table.
Course Time-Tables page
The Course Time-Tables page basically displays information (timings, instructor, class size,
pre-requisites) of all the courses offered at UVic.
Patel Vatsal R. [15012021035] 137

Student Accounts page
The Student Account page contains information like a student’s address, tuition account
information, Netlink account details, and PinChg. A student will be able to view and edit
information which includes changing passwords.
Transcripts and Records
The Transcripts and Records page will contain a student’s unofficial transcripts including and
an ability to display all previously taken courses and the corresponding grades. It will also
display a student’s standing i.e. G.P.A.
This page will also allow a student to order official transcripts.
Patel Vatsal R. [15012021035] 138

Study About Requirement Specification (SRS)

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Study About Requirement Specification (SRS)

Încărcat de

Drepturi de autor:

Formate disponibile

2IT602: Software Engineering Practical - 4

Aim: Study about Requirement Specification (SRS).

(1) Online Banking System (Bank of Baroda).

3.6.1 Software Language Used 56

Patel Vatsal R. [15012021035] 46

Software Requirements Specification

Patel Vatsal R. [15012021035] 47

• User can request for cheque book/change of address/stop payment of cheques.

• User can view his monthly as well as annual statements.

1.3 Definitions, Acronyms and Abbreviations

ATM: Automated teller machine

Patel Vatsal R. [15012021035] 48

The application is to be fully-functional bank software. It will consist of a few different

Overview of the proposed system

Patel Vatsal R. [15012021035] 49

BankMan (Bank Management System) can be used by Bank Employees and/or

customers, who could use it for Cash-Withdrawal, Transfers and Account-Summary.

EWS requires employee login. It handles following

1. New Customer Registration

Patel Vatsal R. [15012021035] 50

require Employee login.

Patel Vatsal R. [15012021035] 51

 Assumptions and dependencies

Patel Vatsal R. [15012021035] 52

3.1.2 Mobile Devices

3.3.2 Mean Time Between Failures (MTBF)

3.3.3 Mean Time to Repair (MTTR)

Patel Vatsal R. [15012021035] 53

3.4.2 Administrator/Manager Response

Patel Vatsal R. [15012021035] 54

3.5.2 Information Security Requirement

3.5.3 Billing System Data Compatibility

3.6 Design Constraints

3.6.2 Development Tools

Patel Vatsal R. [15012021035] 55

3.8 Purchased Components

Logon Screen Prototype:

New Customer registration

Patel Vatsal R. [15012021035] 56

Home Page Of Bank of Baroda Prototype:

Member Information once Logged in:

Patel Vatsal R. [15012021035] 57

3.9.2 Hardware Interfaces

3.9.3 Software Interfaces

3.9.4 Communications Interfaces

Patel Vatsal R. [15012021035] 58

3.10 Licensing Requirements

3.11 Legal, Copyright, and Other Notices

Patel Vatsal R. [15012021035] 59

Database Name:Online Banking

Table Name: LOGIN

Key Field Name Data Type Length Nullable

Table Name: CLIENTS

Key Field Name Data Type Length Nullable

ADDRESS VARCHAR 200 NO

PK ID_PASSPORT VARCHAR 45 YES

Patel Vatsal R. [15012021035] 60

Table Name: ACCOUNT

Key Field Name Data Type Length Nullabe

Table Name: TRANSACTION

Key Field Name Data Type Length Nullable

Patel Vatsal R. [15012021035] 61

Patel Vatsal R. [15012021035] 62

(2) Online Library Management System