Software Requirements

Specification

Table of Contents

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definition, acronyms and abbreviations
1.4 References
1.5 Overviews
1.6 Additional Information
1.7 Intended Audience
1.8 Tools Used
2. Overall Description
2.1 Product Perspective
 2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 External Interface Requirement
3.1.1 User Interfaces
3.1.2 Hardware Interface
3.1.3 Software Interface
3.1.4 Communication Interfaces
3.2 Functional Requirement
3.2.1 Performance Requirement
3.2.2 Hardware Requirement
3.2.3 Software Requirement
3.3 Non-Functional Requirement
3.3.1 Security
3.3.2 Reliability
3.3.3 Availability
3.3.4 Maintainability
3.3.5 Portability
4. Diagrams

4.1 Use Case Diagram

4.2 Dataflow Diagram
4.3 Sequence Diagram
4.4 Activity Diagram
4.4.1 For User
4.4.2 For Admin
4.5 Class Diagram
4.6 ER Diagram
4.7 Database Schema
4.7.1 Admin Schema
4.7.2 User Schema

1. Introduction

This section gives a scope description and overview of everything included in this SRS
document. Also, the purpose for this document is described and a list of abbreviations and
definitions is provided for proper understanding.

1.1 Purpose
The purpose of this document is to provide a consistent and complete description of the
requirements for the web application software “Examify”. The requirements will be presented
using textual descriptions to explain concepts, different types of diagrams to illustrate
complicated interactions, and tables to relate relevant information. In short, the purpose of this
SRS document is to provide a detailed overview of our software product, its parameters and
goals. This document describes the project's target audience and its user interface, hardware
and software requirements. It defines how our client, team and audience see the product and
its functionality.
1.2 Scope
The project aims at providing the user (students/technology aspirants) a common competitive
platform where they can enhance their knowledge while practicing and competing with their
peers. Based on performance in competitions held, participants would be rewarded. The tag-
line of this project says, “Earn while you learn”. This web application can also be used in
educational institutions. Since this software has a built-in anti cheating precautions, there is no
need of examiner while attending competitive tests. This project also overcomes the
conventional problem of manual checking and tedious work in preparing the final result. Here,
participants are getting a chance to earn while learning on the platform, this will motivate them
to a greater extent.

1.3 Definitions, acronyms, and abbreviations

Table 1 - Definitions

Term Definition

User Someone who interacts with the mobile phone application

Admin/Administrator System administrator who is given specific permission for managing and
controlling the system

Stakeholder Any person who has interaction with the system who is not a developer.

1.4 References

1. IEEE Software Engineering Standards Committee, “IEEE Std 830-1998,

Recommended Practice for Software Requirements Specifications”, October 20,
1998.
2. Object Oriented Modelling and Design with UML-Michael Blaha
3. Software Engineering, Seventh Edition, lan Sommerville

1.5 Overview
The rest of this SRS document contains all of the requirements for the Examify presented in
several ways and organized into different sections.
The following SRS contains the detail product perspective from different stakeholders. It
provides the detail product functions of Examify with user characteristics permitted
constraints, assumptions and dependencies and requirements subsets.
The remaining sections of this document provide a general description, including
characteristics of the users of this project, the product's hardware, and the functional and data
requirements of the product. General description of the project is discussed in section 2 of this
document. Section 3 gives the functional requirements, data requirements and constraints and
assumptions made while designing the Web application. It also gives the user viewpoint of
product. Section 3 also gives the specific requirements of the product. Section 3 also discusses
the external interface requirements and gives detailed description of functional requirements.
Section 4 is for supporting information.

1.6 Additional Information

The system work on internet server, so it will be operated by any end user for the selling-buying
purpose.

1.7 Intended Audience

This document is to be read by the development team, the project managers, marketing staff,
testers and documentation writers. Our stakeholders, may review the document to learn about
the project and to understand the requirements. The SRS has been organized approximately in
order of increasing specificity. The developers and project managers need to become intimately
familiar with the SRS.

1.8 Tools Used

AngularJS
NodeJS
ReactJS
MongoDB

2. Overall description
This section will give an overview of the whole system. The system will be explained in its
context to show how the system interacts with other systems and introduce the basic
functionality of it. It will also describe what type of stakeholders that will use the system and
what functionality is available for each type. At last, the constraints and assumptions for the
system will be presented.

2.1 Product perspective

This system will consist of two parts: one mobile application and one web portal. The mobile
application will be used to as portable option of the web portal while the web portal will be
used for user registration, attending tests, modifying information, and providing
administrators with admin panel to modify system as a whole.
Since this is a data-centric product it will need somewhere to store the data. For that, a database
will be used. Both the mobile application and web portal will communicate with the database.
All of the database communication will go over the Internet.

2.2 Product functions

The function of this product is divided into two categories –
Administrators
The function of administrators to is add/edit/modify/update/delete tests in the test modules.
Administrators will also monitor the overall transactions (rewards).
Participants
The function of the participants is to acquire knowledge, practice tests, register themselves for
the upcoming and latest competitive exams and to enhance their public profile.

2.3 User characteristics

There are two types of users that interact with the system: User (Students/Technology
Aspirants) and Administrators (Persons with administrative privileges).
In order to get proper benefits from this software, it is understood that user must have basic
knowledge of English language and computer systems. The administrators only interact with
the web portal. They are managing the overall system so there is no incorrect information
within it. If the user is unfamiliar to the web portal, he/she has to follow the proper guidelines
& instructions provided on the portal.

2.4 Constraints
The candidate is allowed to give practice test as many times as they wish but they will be
allowed to give registered test only once.
The Internet connection is also a constraint for the application. Since the application fetches
data from the database over the Internet, it is crucial that there is an Internet connection for the
application to function.
Multiple user interface will be constrained by the capacity of the database. Since the database
is common to all users, it may be forced to queue incoming requests and therefor increase the
time it takes to fetch data.

2.5 Assumptions and dependencies

Proper working of this web application depends on the internet connectivity of the user’s
computer and mobile. It is assumed that the user has basic knowledge of the system and if not,
he/she must follow the guidelines provided. It is assumed that the data entered by the user while
registration is true else may lead to deactivation of the account.

3. Specific requirements
This section contains all of the functional and quality requirements of the system. It gives a
detailed description of the system and all its features.
3.1 External interface Requirements
This section provides a detailed description of all inputs into and outputs from the system. It also gives
a description of the hardware, software and communication interfaces and provides basic prototypes of
the user interface.

3.1.1 User interfaces

Landing Page
When user firstly visits the website, he/she would be taken to landing page (Figure 1). On landing page,
user will see login and signup buttons. Landing page will also consist of navigation bar and some basic
statistics.

Registration/Login Page
This page will be navigated from the landing page which is the first page that user will see. The layout below will
illustrate the fields and requirements of login & signup page.

Home Page
This is the personal page that user will see when his credentials are validated successfully. The page will consist
of list of Tests, Upcoming contests, Practice tests, User profile, Performance analysis and other relevant
information.

3.1.2 Hardware interfaces

Since web portal do not have any designated hardware, it does not have any direct hardware
interfaces The hardware connection to the database server is managed by the underlying
operating system on the mobile phone and the web server.

3.1.3 Software interfaces

The web application will require any web browser (preferably Google Chrome). It’s portable
version will run on mobile (Android based).

3.1.4 Communications interfaces

The communication between the different parts of the system is important since they depend
on each other. However, in what way the communication is achieved is not important for the
system and is therefore handled by the underlying operating systems for both the mobile
version and the web portal.

3.2 Functional requirements

This section includes the requirements that specify all the fundamental actions of the software
system.
3.2.1 Performance Requirement

User Satisfaction : The web portal and its user interface is such that is make user very
comfortable
Response Time : The response of all web pages is good. This will be made possible by proper
database schema and data retrieving functions.
Error Handling : Response to user errors and undesirable conditions has been taken proper
care to ensure that system operates without halting and in a user friendly manner.
Safety & Robustness : The system is able to avoid/tackle foul actions. The system safeguards
against any undesirable event without any human interventions.
Portability : The software should not be architecture specific. It can be easily transferable to
any other platform if needed.
User friendliness : The system is easy to learn and understand. A native user can also use the
system effectively, without any difficulty.

3.2.2 Hardware Requirement

For the hardware requirement of the SRS specifies the logical characteristics of each interface
between the software product and the hardware components. It specifies the hardware
requirements like memory restrictions, cache size, processor, RAM etc. those are required for
this web-application to learn.
MINIMUM HARDWARE REQUIREMENT

Processor Core i3
Hard Disk Drive 40GB
RAM 512 MB
Cache 512 kb

PREFFERED HARDWARE REQUIREMENT

Processor Core i5
Hard Disk Drive 100GB
RAM 2 GB
Cache 1 mb

3.2.3 Software Requirement

Any cross platform-based operating system is the primary requirement for software to work.
The system must be connected to internet.

3.3 Non-Functional requirements

3.3.1 Security
The system uses SSL (secured socket layer) in all transactions that include any
confidential customer information.
The system must automatically log out all customers after a period of inactivity.
 The system should not leave any cookies on the customer’s computer containing the
user’s password.
The system’s back-end servers shall only be accessible to authenticated administrators.
Sensitive data will be encrypted before being sent over insecure connections like the
internet.
The system shall use secure sockets in all transactions that include any confidential
customer information.
The system shall automatically log out all customers after a period of inactivity.
The system shall confirm all transactions with the customer’s web browser.
The system shall not leave any cookies on the customer’s computer containing the
user’s password.
The system shall not leave any cookies on the customer’s computer containing any of
the user’s confidential information.
The user’s web browser shall never display a user’s password. It shall always be echoed
with special characters representing typed characters.
The system’s back-end servers shall never display a user’s password. The user’s
password may be reset but never shown.
The system’s back-end servers shall only be accessible to authenticated administrators.
The system’s back-end databases shall be encrypted.

3.3.2 Reliability
The system provides storage of all databases on redundant computers.
The reliability of the overall program depends on the reliability of the separate
components. The main pillar of reliability of the system is the backup of the database
which is continuously maintained and updated to reflect the most recent changes.
Thus, the overall stability of the system depends on the stability of container and its
underlying operating system.

3.3.3 Availability
The system should be available at all times, meaning the user can access it using a web
browser, only restricted by the down time of the server on which the system runs. In
case of a of a hardware failure or database corruption, a replacement page will be
shown. Also, in case of a hardware failure or database corruption, backups of the
database should be retrieved from the server and saved by the administrator. Then
the service will be restarted. It means 24 X 7 availability.
The system shall provide storage of all databases on redundant computers with
automatic switchover.
The system shall provide for replication of databases to off-site storage locations.
The product shall be based on web and has to be run from a web server.
The product shall take initial load time depending on internet connection strength
which also depends on the media from which the product is run.
The performance shall depend upon hardware components of the client/customer.

3.3.4 Maintainability
 A commercial database is used for maintaining the database and the application
server takes care of the site. In case of a failure, a re-initialization of the program will
be done. Also, the software design is being done with modularity in mind so that
maintainability can be done efficiently.

3.3.5 Portability
The application is HTML and scripting language based. So, the end-user part is fully
portable and any system using any web browser should be able to use the features of
the system, including any hardware platform that is available or will be available in the
future. An end-user can use this system on any OS; either it is Windows or Linux. The
system shall run on PC, Laptops, Mobiles etc.

4. Diagrams
4.1 Use Case Diagram
4.2 Data Flow Diagram

Context Level

Level 1 (For User)

 Level 2 (Profile for User)

Level 2 (Today’s Test for User)

Level 2 (Upcoming Test for User)

Level 2 (Practice Test for User)

 Level 1 (For Admin)

Level 2 (Profile for Admin)

Level 2 (Add Test for Admin)
4.3 Sequence Diagram
4.4 Activity Diagram

4.4.1 For User –

4.4.2 For Admin
4.5 Class Diagram
4.6 ER Diagram
4.7 Schema

4.7.1 Admin Schema

 4.7.2 User Schema