Академический Документы
Профессиональный Документы
Культура Документы
Develop the SRS using SRS Template for following System in Group.
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
2IT602: Software Engineering Practical - 4
4. Database Design 60
5. Entity-Relationship Diagram 62
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.
• 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.
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.
2. Overall Description
Product Perspective
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].
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
Both of them connect to a main database server for storing and retrieving the data of the
customers.
Functions:
2. Transactions
a. Detail Updation
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
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
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.
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.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.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.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.
3.5.6 Standards
The coding standards and naming conventions will be as per the American standards.
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.
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.
4. Database Design
PASSWORD VARCHAR 45 NO
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
MOBILENO VARCHAR 10 NO
TELEPHONENO VARCHAR 10 NO
EMAIL VARCHAR 45 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
TRANSACTIONID INT NO
TYPEOFTRANSAC
TION VARCHAR 45 NO
TRANSACTIONDA
TE DATETIME NO
REFERENCE VARCHAR 45 NO
5. Entity-Relationship Diagram
Table of Contents
1. Introduction 66
1.1 Purpose 66
1.2 Scope 66
1.3 Definitions, Acronyms and Abbreviations 667
1.4 References 667
1.5 Overview 677
3. Specific Requirements 73
3.1 Functionality 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 Supportability 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
4. Supporting Information 80
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
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.
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
2IT602: Software Engineering Practical - 4
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.
2. Overall Description
Product Perspective
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
2IT602: Software Engineering Practical - 4
Management System
Internet
Users
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
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.
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.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.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.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
2IT602: Software Engineering Practical - 4
3.5.5 Standards
The coding standards and naming conventions will be as per the American standards.
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
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.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.
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.
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
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.
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.
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
2IT602: Software Engineering Practical - 4
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
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
Description:
Patel Vatsal R. [15012021035] 85
2IT602: Software Engineering Practical - 4
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.
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
2IT602: Software Engineering Practical - 4
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.
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.
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
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.
2 Overall Description
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.
Main Features
FE-1: Create/Delete Profile
*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)
1Features with an asterisk (*) means this feature will be implemented if time permits.
2Features with an asterisk (*) means this feature will be implemented if time permits.
3Features with an asterisk (*) means this feature will be implemented if time permits.
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.
Uploading Photographs
The user has a facility to upload and share his photographs.
Blogging
The user has the right to write posts in his blog and publish them.
3 Other 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-SR2 The Front-end and middle logic tools and technology will be
written using Java
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.
3.1.2.2Iterative Model
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>>
User
Reply to Message
User
Add friend
User
Delete friends
Add/Delete photo
User
4.1.9Video Page
User
5.Database Relationship
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.
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.
Table of Contents
Contents
1. Introduction ………………………………………………………………………………………..103
1.3 Scope……………………………………………………………………………………...……104
2. Overall description…………………………………………………………………………………105
3. Analysis……………………………………………………………………………….…………….109
4. Conclusion………………….………………………………………………………………………..120
5. Future Extension………….…………………………………………………………………………121
1. INTRODUCTION
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.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.
2. Overall Description
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.
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.
1) Login
2) Report generation
Report of all members
Report of free members and paid members
User management
3) Logout
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 .
User can change his/her photo, Image uploading is done after registration only, so user must
have member id for image uploading.
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 .
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
2IT602: Software Engineering Practical - 4
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 .
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.
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 .
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.1 Estimation:-
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.
Application.
3. ANALAYSIS
3.1 DATA FLOW DIAGRAM
3.1.1 Level 0
3.1.2 Level 1
login page
update imformation
profile updated
click on photoupload
browes photo
click on upload
photo uploaded
click on search
search option
select option
Fill up information
required in given form
search according
click on search
given information
give result
3.4.2Display Records
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.
Matrimonial website which will provide platform to a lot of Bride/Groom for finding perfect match.
There are different sectors like Registration, Partener , 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 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.
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.
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.
Table of Contents
1. Introduction 12925
1.1 Purpose 12925
1.2 Scope 12925
1.3 Definitions, Acronyms and Abbreviations 12925
1.4 References 13025
1.5 Overview 13026
4. Interfaces 130
4.1 User and Software Interfaces 130
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.
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.
Records Employee: This is an employee who works for the Records office and handles official
transcript requests.
Patel Vatsal R. [15012021035] 129
2IT602: Software Engineering Practical - 4
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.
2. Overall Description
The user would be directed to the appropriate page depending on whether the user is a student
or records staff.
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.
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.
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.2 Usability
3.2.1 Usability Requirement 1 (FR) - Single Sign-on
The system checks if the entered student number and password are valid.
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:
- 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
The new system will also allow records employees to log into the system, view and
process transcript requests
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.
3.3 Reliability
3.4 Performance
When brought up in the interview the response from UVic web systems was “Basically
we want the system to handle errors gracefully, like crashes.”
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
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.”
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”.
4. Interfaces
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 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.
The Course Time-Tables page basically displays information (timings, instructor, class size,
pre-requisites) of all the courses offered at UVic.
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.
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.