Software Requirements

Specification
HOSPITAL MANAGEMENT SYSTEM

JANESH KUMAR CHHANIWAL– PIET18CS066

JATIN TAK – PIET18CS067

LOKENDRA ARYA – PIET18CS082

Table of Contents

1. Introduction 1
1.1 Purpose 1
1.2 Scope 1
1.3 Definitions, acronyms, and abbreviations 1
1.4 References 2
1.5 Overview 2
2. Overall description 3
2.1 Product perspective 3
2.2 Product functions 3
2.3 User characteristics 4
2.4 Constraints 4
2.5 Assumptions and dependencies 4
2.6 Apportioning of requirements 4
3. Specific requirements 5
3.1 External interface Requirements 5
3.1.1 User interfaces 5
3.1.2 Hardware interfaces 5
3.1.3 Software interfaces 5
3.1.4 Communications interfaces 6
3.2 Functional requirements 6
3.2.1 User Class 1 - The User 6
3.3 Performance requirements 8
3.4 Design constraints 9
3.5 Software system attributes 10
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.

1.1 Purpose

The purpose of this document is to give a detailed description of the requirements for the
“Career and Job Opportunities” (C&JO) software. It will illustrate the purpose and complete
declaration for the development of system. It will also explain system constraints, interface
and interactions with other external applications. This document is primarily intended to be
proposed to a customer for its approval and a reference for developing the first version of the
system for the development team.

1.2 Scope

The “Career and Job Opportunities” is a website which helps people to find the better career
options and suitable jobs. The website should be free to use either from a mobile phone or a
PC.

Companies can provide their vacancies using the web-portal. This information will act as the
bases for the search results displayed to the user. An administrator also uses the web-portal in
order to administer the system and keep the information accurate. The administrator can, for
instance, verify company and information.

Furthermore, the software needs Internet to fetch and display results. All system information is
maintained in a database, which is located on a web-server. The software also interacts with
the Company software which is required to be an already installed application on the user’s
mobile phone. By using company software, users can view desired vacancies with date and
time. The application also has the capability of representing both summary and detailed
information about the company.

1.3 Definitions, acronyms, & abbreviations

Term Definition

User Someone who interacts with the website

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

Company Someone who wants to give the job

Web - Portal A web application which present special facilities for company and
admin
1.4 References

[1] Software Requirements Specification – Amazing launch Indicator , 2010

[2] IEEE Software Engineering Standards Committee, “IEEE Std 830-1998, IEEE
Recommended Practice for Software Requirements Specifications”, October 20, 1998

1.5 Overview

The remainder of this document includes three chapters . The second one provides an
overview of the system functionality and system interaction with other systems. This chapter
also introduces different types of users and their interaction with the system. Further, the
chapter also mentions the system constraints and assumptions about the website.

The third chapter provides the requirements specification in detailed terms and a
description of the different system interfaces. Different specification techniques are used
in order to specify the requirements more precisely for different audiences.
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 users 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 website and one database. The website will be used
to find vacancies and view information about the job while the database will be used for
managing the information about the companies and the system as a whole.

The website will need to communicate to the database within the system which in turn
communicates with the company and find the vacancies. The database will provide the website
with information of both the user and the company and will tell about the vacancies, but it will
also tell about the features of job like time duration and salary etc. The functionality provided
by the company will be embedded into the application in order for the user to be able to use
the function in the application in the seamlessly manner.

Since this is a product it will need somewhere to store the data. For that, a database will be
used. Both the website and web portal will communicate with the database, however in slightly
different ways. The website will only use the database to get data while the web portal will also
add and modify data. All of the database communication will go over the Internet.

The website has some restrictions about the resource allocation. To avoid problems with
overloading the operating system the website is only allowed to use 20 megabytes of
memory while running the application. The maximum amount of hard drive space is also 20
megabytes.

2.2 Product functions

With the website, the users will be able to search for jobs. The result will be based on the
criteria the user inputs. There are several search criteria and it will be possible for the
administrator of the system to manage the options for those criteria that have that.

The result of the search will be viewed in a list view, depending on what criteria included in
the search. The list view will have one list item for each job matching the search criteria and
show a small part of the job information so the user can identify the company.

The web portal will provide functionality to manage the system and the company information.
It will also provide information about the system, for example show when there is a new
update.
2.3 User characteristics

There are three types of users that interact with the system: users of the website, company
owners and administrators. Each of these three types of users has different use of the
system so each of them has their own requirements.

The website users can only use the website to find a job. This means that the user have to
be able to search for jobs, choose a company from that search and then navigate to it. In
order for the users to get a relevant search result there are multiple criteria the users can
specify and all results matches all of those.

The company owners will not use the website but the web portal instead. There they will
manage the information about their company and information about the job.

The administrators also only interact with the web portal. They are managing the overall
system so there is no incorrect information within it. The administrator can manage the
information for each company as well as the options for both the website users and the
company owners.

2.4 Constraints

The website is constrained by the system interface to the company software within the
system .Since there are multiple system. The interface will most likely not be the same for
every one of them.

The Internet connection is also a constraint for the website. Since the website fetches data from
the database over the Internet, it is crucial that there is an Internet connection for the website to
function.

Both the web portal and the website will be constrained by the capacity of the database. Since
the database is shared between both website it may be forced to queue incoming requests and
there for increase the time it takes to fetch data.

2.5 Assumptions and dependencies

One assumption about the product is that it will always be used on systems that have
enough performance. If the system does not have enough hardware resources available for
the website, for example the users might have allocated them with other websites; there may
be scenarios where the website does not work as intended or even at all.

2.6 Apportioning of requirements

In the case that the project is delayed, there are some requirements that could be transferred
to the next version of the website.
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

A first-time user of the website should see the log-in page when he/she opens the website, If
the user has not registered, he/she should be able to do that on the log-in page. If the user is
not a first-time user, he/she should be able to see the search page directly when the website is
opened, here the user chooses the type of search he/she wants to conduct. Every user should
have a profile page where they can edit their e-mail address, phone number and password.
Also, the user can set the website to his/her preferred language.

When a user searches for a job he/she have to select the category of the job. For example
household jobs, marketing jobs, transcript jobs etc. Then from these categories the user has to
select the most appropriate job for him/her. There he/she have to see all the details about the
job like time duration, salary, place etc. The user can also select jobs in which he/she can
work from home. Then a list of companies will appear on the website from which the user can
select the company and the link is provided which will redirect the user to the company’s
website.

The company and administrator interact with the system through a web portal. A company
owner should be able to register on the web-portal in order to log in and manage the company
information. An administrator should also be able to log in to the web-portal where he/she can
administer the system by for instance editing company or user information.

3.1.2 Hardware interfaces

Since neither the website nor the web portal have any designated hardware, it does not have
any direct hardware interfaces. The database server is managed by the underlying operating
system on the website and the web server.

3.1.3 Software interfaces

The website communicates with the database in order to save or fetch the information.
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 website 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 User Class 1 - The User

3.2.1.1 Functional requirement 1

ID: FR1
TITLE: Open website
DESC: A user should be able to load the website through internet service on the system.
RAT: In order for a user to load the website.
DEP: None

3.2.1.2 Functional requirement 2

ID: FR2
TITLE: Notify users of new updates
DESC: When the website is updated, the user should check for these manually.
RAT: In order for a user to check the website regularly.
DEP: FR1

3.2.1.3 Functional requirement 3

ID: FR3
TITLE: User registration-Website
DESC: Given that a user has checked the website, then the user should be able to register
through the website. The user must provide user-name, password and e-mail address. The
user can choose to provide a regularly used phone number.
RAT: In order for a user to register the website.
DEP: FR1

3.2.1.4 Functional requirement 4

ID: FR4
TITLE: User login-Website
DESC: Given that a user has registered, the user should be able to login to the website. The
user must provide user-name, password and e-mail address. The log-in information will be
stored on the database and in the future the user should be logged in automatically.
RAT: In order for a user to register the website.
DEP: FR1, FR3

3.2.1.5 Functional requirement 5

ID: FR5
TITLE: Retrieve Password
DESC: Given that a user has registered, the user should be able to retrieve his/her password
by e-mail.
RAT: In order to retrieve his/her password.
DEP: FR1

3.2.1.6 Functional requirement 6

ID: FR6
TITLE: Website – Search
DESC: Given that a user is logged in to the website, then the first page that is shown should
be the search page. The user should be able to search for a job, according to several search
options. The search options are Part-time jobs or data entry jobs etc. There should also be a
free- text search option. A user should be able to select multiple search options in one
search.
RAT: In order for a user to search for a job.
DEP: FR1

3.2.1.7 Functional requirement 7

ID: FR7
TITLE: Website – Search result in a list view
DESC:

• Search results can be viewed in a list. Each element in the list represents a specific
company. Each element should include the company name, telephone number, type of
company, distance according to the user’s position, average salary, a short two-line
description, a link to the company’s web-page and an information link.
• There should be maximally 100 results displayed. If the result contains more companies
than what can be displayed on the screen at one time, the user should be able to scroll
through them.
• When searching by salary the companies should be sorted according to the
following order:
1. Average salary
2. Distance
3. Company type
4. Specific job
• When searching by a search option, other than salary, the companies should be sorted
according to the following order:
1. Distance
2. Average salary
 3. Company type
4. Specific job
• The list view should include a header with different selectable sorting
options.
• The list view should include a button that, when selected, should display different
filtering options in a filtering menu.
RAT: The way result should be displayed in a list.
DEP: FR6

3.2.1.8 Functional requirement 8

ID: FR8
TITLE: Website - Profile page
DESC: On the website, a user should have a profile page. On the profile page a user can
edit his/her information, which includes the password, e-mail address and phone
number. A user should also be able to choose what language the mobile application
should be set to. The different language choices are Swedish, English, Spanish and
French.
RAT: In order for a user to have a profile page on the website.
DEP: FR1

3.3 Performance requirement

The requirements in this section provide a detailed specification of the user interaction with the
software and measurements placed on the system performance.

3.3.1 Prominent search

ID: QR1
TITLE: Prominent search feature
DESC: The search feature should be prominent and easy to find.
RAT: In order to for a user to find the search feature easily.
DEP: none

3.3.2 Usage of the search feature

ID: QR2
TITLE: Usage of the search feature
DESC: The different search options should be evident, simple and easy to understand
RAT: In order to for a user to perform a search easily .
DEP: none

3.3.3 Usage of result in the list view

ID: QR3
TITLE: Usage of the result in the list view
DESC: The results displayed in the list view should be user friendly and easy to understand.
Selecting an element in the result list should only take one click.
RAT: In order to for a user to use the list view easily.
DEP: none

3.3.4 Usage of information link

ID: QR4
TITLE: Usage of the information link
DESC: The information link should be prominent and it should be evident that it is a usable
link. Selecting the information link should only take one click.
RAT: In order to for a user to use the information link easily.
DEP: none

3.3.5 Response time

ID: QR5

TAG: Response Time

GIST: The fastness of the search
SCALE: The response time of a search
METER: Measurements obtained from 1000 searches.
MUST: No more than 2 seconds 100% of the time.
WISH: No more than 1 second 100% of the time.

3.3.6 System Dependability

ID: QR6
TAG: System Dependability
GIST: The fault tolerance of the system.
SCALE: If the system loses the connection to the Internet the user should be informed.
METER: Measurements obtained from 1000 hours of usage during testing.
MUST: 100% of the time.

3.4 Design constraints

This section includes the design constraints on the software caused by the
hardware.

3.4.1 Hard Drive Space

ID: QR7
TAG: Hard Drive Space
GIST: Hard drive space.
SCALE: The website’s need of drive space.
METER: MB.
MUST: No more than 20 MB.
PLAN: No more than 15 MB.
WISH: No more than 10 MB.
MB: DEFINED: Megabyte
3.4.2 Application memory usage

ID: QR8
TAG: Website Memory Usage
GIST: The amount of Operate System memory occupied by the website.
SCALE: MB.
METER: Observations done from the performance log during testing
MUST: No more than 20 MB.
PLAN: No more than 16 MB
WISH: No more than 10 MB
Operate System: DEFINED: The mobile Operate System which the website is
running on.
MB: DEFINED: Megabyte.

3.5 Software system attributes

The requirements in this section specify the required reliability, availability, security and
maintainability of the software system.

3.5.1Reliability
ID: QR9
TAG: System
Reliability
GIST: The reliability of the system.
SCALE:Reliability that the system gives the right result on search.
METER: Measurements obtained from 1000 searches.
MUST: More than 98% of the searches.
PLAN: More than 99% of the searches.
WISH: 100% of the searches.

3.5.2Availability

ID: QR10
TAG: System Availability
GIST: The availability of the system when it is used.
SCALE: The average system availability.
METER: Measurements obtained from 1000 hours of usage.
MUST: More than 98% of the time.
PLAN: More than 99% of the time.
WISH: 100% of the time.

ID: QR11 TITLE: Internet Connection

DESC: The application should be connected to the Internet.
RAT: In order for application to communicate with database.
DEP: none
3.5.3Securiy

ID: QR12
TAG: Communication Security
GIST: Security of the communication between the system and server.
SCALE: The messages should be encrypted for log-in communications, so others cannot get
user-name and password from those messages.
METER: Attempts to get user-name and password through obtained messages on 1000 log-
in session during testing.
MUST: 100% of the Communication Messages in the communication of a log-in session
should be encrypted.
Communication Messages: Defined: Every exchanged of information between client and
server.

ID: QR13
TAG: Company Login Account Security
GIST: Security of accounts.
SCALE: If a company owner tries to log in to the web portal with a non-existing account then
the company should not be logged in. The company should be notified about log-in failure.
METER: 1000 attempts to log-in with a non-existing user account during testing.
MUST: 100% of the time.

ID: QR14
TAG: Admin Login Account Security
GIST: Security of accounts.
SCALE: If an admin tries to log in to the web portal with a non-existing account then the
admin should not be logged in. The admin should be notified about log-in failure.
METER: 1000 attempts to log-in with a non-existing user account during testing.
MUST: 100% of the time.

3.5.4Maintainability

ID: QR15
TITLE: Website extendibility
DESC: The website should be easy to extend. The code should be written in a way that it
favors implementation of new functions.
RAT: In order for future functions to be implemented easily to the website.
DEP: none

ID: QR16
TITLE: Website testability
DESC: Test environments should be built for the application to allow testing of the website
different functions.
RAT: In order to test the website.
DEP: none
3.5.5Portability

ID: QR17
TITLE: Website portability
DESC: The website should be portable with every OS.
RAT: The adaptable platform for the website to run on.
DEP: none