SDM LAB 2-Software - Requirements - Specification

Vishwakarma Institute of Technology, Pune-37.
Blood Donation Website
Software Requirements Specification
Prajwal Atram TY_IT_A 06

Hitashri Patil TY_IT_A 40
Nupur Shinde TY_IT_A 54
Vishal Singh TY_IT_A 65
Sameer Meshram TY_IT_A 76
Approvals Signature Block
Project Responsibility Signature Date

Project Guide (Internal)
Project Guide (External)
Documentation Leader
Department of Information Technology

The document in this file is adapted from the IEEE standards for Software Project
Requirements Specifications, 830-1998, which conforms to the requirements of ISO
standard 12207 Software Life Cycle Processes.
Items that are intended to stay in as part of your document are in bold; blue italic text is
used for explanatory information that should be removed when the template is used.
2 v. 1.0 2006
Table of Contents
1. INTRODUCTION 4
1.1 PURPOSE 4
1.2 SCOPE 4
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS 4
1.4 REFERENCES 4
1.5 OVERVIEW 4
2. OVERALL DESCRIPTION 5
PROBLEM STATEMENT 5
2.1 PRODUCT PERSPECTIVE 5
PRODUCT POSITION STATEMENT 5
2.1.1 System Interfaces 5
2.1.2 User Interfaces 6
2.1.3 Hardware Interfaces 6
2.1.4 Software Interfaces 6
2.1.5 Communications Interfaces 6
2.1.6 Memory Constraints 6
2.1.7 Operations 6
2.1.8 Site Adaptation Requirements 6
2.2 PRODUCT FUNCTIONS 7
2.3 USER CHARACTERISTICS 7
2.4 CONSTRAINTS 7
2.5 ASSUMPTIONS AND DEPENDENCIES 7
2.6 APPORTIONING OF REQUIREMENTS 7
3. SPECIFIC REQUIREMENTS 7
3.1 EXTERNAL INTERFACES 8
3.2 FUNCTIONS 8
3.3 PERFORMANCE REQUIREMENTS 9
3.4 LOGICAL DATABASE REQUIREMENTS 9
3.5 DESIGN CONSTRAINTS 9
3.5.1 Standards Compliance. 9
3.6 SOFTWARE SYSTEM ATTRIBUTES 10
3.6.1 Reliability 10
3.6.2 Availability 10
3.6.3 Security 10
3.6.4 Portability 10
3.7 ORGANIZING THE SPECIFIC REQUIREMENTS 11
3.7.1 System Mode 11
3.7.2 User Class 11
3.7.3 Feature 11
3.7.4 Stimulus 12
3.7.5 Response 12
3.7.6 Functional Hierarchy 12
3.8 ADDITIONAL COMMENTS 12
3 v. 1.0 2006
4. SUPPORTING INFORMATION. 12
DOCUMENT CONTROL 13
CHANGE HISTORY 13
DOCUMENT STORAGE 13
DOCUMENT OWNER 13
APPENDICES 14
1. INTRODUCTION
● The project blood bank management system is known to be a pilot project

that is designed for the blood bank to gather blood from various sources
and distribute it to the needy people who have high Requirements for it.
● The Software is designed to handle the daily transaction of the blood bank
and Search the details when required.
● It also helps to register the details of donors, blood collection details as

well as blood reports.
● The software Application is designed in such a manner that it can suit the
needs of all the blood bank requirements in the course of future.
● It will help us to find the Blood group with its most efficient time to take
care of the blood and it is more easy to hand over the blood to the hospital
to help people to get blood on time.
● Everything is being stored in this blood bank management system to help

more people trying their best to do so.
1.1 PURPOSE
The basic building aim is to provide blood donation service to the city. Blood
Bank Management system is a web-based application that is designed to store,
process, retrieve and analyzeProject aim is to provide transparency in this field,
make the process of obtaining blood from a Blood Bank hassle-free and
corruption-free and make the system of Blood Bank Management effective.
information concerned with the administrative and inventory management within
a Blood Bank.This project aims at maintaining all the information pertaining to
blood donors, different blood groups available in every Blood Bank and help
them manage in a better way.
4 v. 1.0 2006
1.2 SCOPE
The specification builds on the experience of IT technology in blood transfusion

that is currently available and informs both Connecting for Health (CfH) and
commercial companies producing both hardware and software.
The main objective of this specification is to manage the records in blood
donation, useful in emergency situations. All records are computerized and a
database is used to store the records and display and sort the data efficiently.
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS
Term or Acronym Definition

_id unique id assigned to donor
blood_type blood type of donor
donar_name name of donor
donar_dob birth date of donor
donar_mobno contact number of donor
patient_name name of patient
Table x. Definitions and Acronyms
1.4 REFERENCES
1. References provided by Prof. Bibhudatta Sahoo.

2. IEEE Software Engineering Standard Committee, “IEEE Std 830-1998, IEEE
Recommended Practice for Software Requirement Specifications”.
3. Class Diagram and Use Case Diagram made on https://creately.com/.
1.5 OVERVIEW
This application is built in such a way that it suits all types of blood banks in
future, so every effort is taken to implement this project in this blood bank. On
successful implementation in this blood bank, we can target other blood banks in
the city.
Main modules of the project:
This project has the following modules, to manage all the requirements of the
blood bank.
1. Blood donor details
2. Donor details
3. Recipient details
4. Blood collection details
5. Blood issued details
6. Stock details
5 v. 1.0 2006
7. Camp details
8. Reports
To manage employees in the blood bank it had the following modules:
1. Employee details
2. Employee attendance details
3. Employee salary generation
4. Employee salary payment
5. Report
2. OVERALL DESCRIPTION
This section will give an overview of the entire system. System will be explained
in its context to show how the system will work and introduce the basic
functionality of it. It will describe all the stakeholders who will access the system
and what functionality is available for each type. The constraints and
assumptions for the system will be explained.
PROBLEM STATEMENT
[Provide a statement summarizing the problem being solved by this project. The following
format may be used:]
The problem of Maintaining records of donors and patients in file
format.
Affects Data processing and retrieval
The impact of which is Life of a patient is in danger in crucial situations .
A successful solution would Management of data through databases
efficiently.
2.1 PRODUCT PERSPECTIVE
This system includes both offline and online components. The collection of blood
will be manual 8
through Blood Donation Camp.
The donor can either register on the Blood Bank website on his own or can visit
the Blood Donation Camp and the responsible authority at the camp can do the
registration for the donor. An online database is maintained with all the
information about the donors.
PRODUCT POSITION STATEMENT
6 v. 1.0 2006
[Provide an overall statement summarizing at the highest level, the unique position the
product intends to fill in the marketplace. The following format may be used:]
For Patients
Who require blood
The (product name) is a (product category)
That (statement of key benefit - that is - compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary differentiation)
[A product position statement communicates the intent of the application and the
importance of the project to all concerned personnel.]
2.1.1 System Interfaces
Server Side
● Database Connection.
● Request Handling.
● Notification service.
● Report generation for Donor and Patient
2.1.2 User Interfaces
Client Side
1. Login Module (Donor & Patient)
● User login
● New user registration
● Password authentication
● Forgot password
● Change password
2. Donor Module
● Add /Edit/Delete Personal details.

● Add /Edit/Delete Blood details.
● Upload Blood reports.
3. Patient / Blood Bank Module
● Add /Edit/Delete Personal or organizational details.

● Search for a Donor / Blood group.
● Contact Donor By email/ SMS/ Notification/ Call.
7 v. 1.0 2006
2.1.3 Hardware Interfaces
● 1GHz or High processor
● 512 MB RAM
● 500 MB Hard Disk
2.1.4 Software Interfaces
Windows
Chrome, Internet Explorer, Mozilla Firefox
2.1.5 Communications Interfaces
The website should :
● Should run on 500GHz, 64MB Machine.
● Should have a proper internet connection.
● The response time for a change will be more than 4 seconds.
● The response time for accessing the database will be no more than 5
seconds.
2.1.6 Memory Constraints
RAM : Minimum 4GB

Hard Disk : Minimum 500GB
2.1.7 Operations
Particulars Client system server system
Operating System Windows Linux
Processor Pentium 4 Pentium 4
Hard Disk 40GB 100GB
RAM 256MB 512GB
8 v. 1.0 2006
2.1.8 Site Adaptation Requirements
In order to use the product, modifications can be done to the database section, if
the hospital wants to add certain fields to the database.
Forms added if any can be modified according to the requirements of the user
and hospital.
2.2 PRODUCT FUNCTIONS
Class of use cases Use cases Description
Use cases related to 1.Login of admin. 1.Log admin into the

system authorization of 2.Change password of system.
system administrator admin 2.Change the login
password ofthe admin of
the system.
Use cases related to 1. Enter name 1. Donor will enter

registration of donors. 2. Enter DOB his/her name
3. Enter blood group 2. User will enter
his/ her DOB and
blood group.
Use cases related to 1. Login of donor 1. Donor will login

system authorization of 2. Change password into system
the donor. of donor 2. Donor can
change password
2.3 USER CHARACTERISTICS
Here the system admin & the donor are the system users. According to my
assumptions the donor who will register to the system from the website will
understand easy questions which are in English & he/she has the ability to
realize small instructions & fill the application without any errors & a small
knowledge of computers to upload the health condition certificate to the systems.
Users are very generous to attend the donation with such a small announcement.
(Email & SMS Messages)
2.4 CONSTRAINTS
● The Donor and the acceptor are constrained to create an account first to
avail the services.
● The internet connection is also a constraint for this web application.
9 v. 1.0 2006
● The web application is also constrained by the database capacity so it

works well with a smaller number of donors and hospitals.
● The access to manage the databases are different for different people.
● The receptionist is given the access to maintain the database of the
registered donors and hospitals.
● The inventory manager is allowed access to update the inventory details
and payment of the order placed by the hospitals.
2.5 ASSUMPTIONS AND DEPENDENCIES
It is assumed that the users have enough resources to run the web application i.e
a mobile phone or a computer that supports the required functions.It is assumed
that the online payments carried out are looked at by the respective bank
administrators.
The web application depends on the application such as MongoDB for creating
and managing the database.
The front end is designed with the help of HTML, JavaScript and React.
2.6 APPORTIONING OF REQUIREMENTS
1. Access Website:Users should be able to access web-application through

either an application browser or similar service on the mobile phone or computer.
There should not be any limitation to access web-application.
2. User Registration: Given that the user has accessed web-application, then the
user should be able to register through the web-application. The donor user must
provide first name, gender, blood group, location, contact , username and
password.
3. New Releases:When a new/update version of the web-application is released,
the appearance will automatically appear when the user accesses the
web-application.
4. User log-in: Given that the user has registered, then the user should be able to
login to the web-application. The login information will be stored on the database
for future use.
5. Search result in a list view:Search result can be viewed in a list. Each element
in the list represents a specific donor. Each element should include first name,
gender, blood group, 13
location, contact according to the user position. There should be a maximum of
ten result displays.
6. Request Blood: User(Hospital) should be able to request blood at an
emergency situation, user needs to define blood group, location, required date,
contact. The order requested will be sent to the blood bank and then to the
Inventory to check the availability. If available, the requested blood will be sent to
the requested donor(Hospital).
10 v. 1.0 2006
7. View Request: The Blood Bank should be able to view received requests and
then respond to them and can search requests by selecting two options: select
blood group and provision.
8. Search Blood Bank Stock:Receiving the order from the Hospital , the blood
stock in the Blood Bank Inventory will be searched to match the requested order.
Thus matched blood units will be sent to the Hospital
3. SPECIFIC REQUIREMENTS
● Login of admin.
● Blood Donor.
● Change the login password of the admin.
● Register the donor by himself.
● Register the donor by system admin
● Login of the donor.
● Change the login password of the donor.
● Change personal, contact details by the donors himself
● Change personal contact details by the system admin.
● Withdraw reg. details by the donor.
● Withdraw reg. details by the admin.
● Send blood donation details to the relevant donors.
● Send blood testing details.
● Information of all blood banks donor details, donate blood with their
interest and others will do in future.
● Interested in donating blood can register.
● General users want to contact blood donors by checking their interest in
donating blood, he can also take the help of this site.
● Rapid response of urgent requests for blood components.
● Checking pre-transfusion samples and request
● Assessing Immunological compatibility between donor and patient.
● Selecting suitable blood components of each clinical condition.
● Safe delivery and handling of blood components.
● Inventory and stock management.
● Interactions with the blood establishment
3.1 EXTERNAL INTERFACES
● The system is basically running on the official website of the govt, blood
bank. Mainly there are 2 actors in the system. The system provides some
advanced features to the system admin than the donor. If the system
11 v. 1.0 2006
admin logs in, the system interface provides some main command buttons
to the admin.
● Change login password.
● Edit donor profile details.
● Search donors for an exact blood group and send messages.
● Print statements.
● Update the database.
● Send blood testing details.
● Search details from the database.If the donors log in, the system will
provide another different interface with different commands.
● Change login passwords.
● Edit personal .contact details
● Details related to contributions to donations.
● Future blood donation details.
● Withdraw name from the system
3.2 FUNCTIONS
1. Access Website:
Users should be able to access web-application through either an application
browser or similar service on the mobile phone or computer. There should not be
any limitation to access web-application.
2. User Registration:
Given that the user has accessed the web-application, then the user should be
able to register through the web-application. The donor user must provide first
name, gender, blood group, location, contact , username and password.
3. New Releases:
When a new/update version of the web-application is released, the appearance
will be automatically appears when the user access the web-application
4. User log-in:
12 v. 1.0 2006
Given that the user has registered, then the user should be able to login to the
web-application. The login information will be stored on the database for future
use.
5. Search result in a list view:

Search results can be viewed in a list. Each element in the list represents a
specific donor. Each element should include first name, gender, blood
group,location, contact according to the user position. There should be a
maximum of ten result displays.
6. Request Blood:
User(Hospital) should be able to request blood at an emergency situation, user
needs to define blood group, location, required date, contact. The order
requested will be sent to the blood bank and then to the Inventory to check the
availability. If available, the requested blood will be sent to the requested
donor(Hospital)
7. View Request:
The Blood Bank should be able to view received requests and then respond to
them and can search requests by selecting two options: select blood group and
provision.
8.View Order Details:

The Hospital Blood Bank should be able to view the OrderId, time of the order
placed, name of the hospital, location and the address of the hospital. In addition
to this an additional feature of tracking the delivery person which includes his
location and the checkpoints passed.
9.View delivery status:

The Hospital, Blood Bank should be able to view the status of the delivery time. If
the delivery seems to be delayed then the hospital manager must be able to call
the delivery person to get the update on the delivery.
3.3 PERFORMANCE REQUIREMENTS
● The system is interactive and the delays involved are less.
● When connecting to the server the delays is based editing on the distance
of the two System configuration between them so there is high probability
that there will be or not a successful connection in less than 20 seconds
for the sake of good communications
13 v. 1.0 2006
3.4 LOGICAL DATABASE REQUIREMENTS
1. Donor Database : The receptionist at the Blood Donation Camp will maintain
the donor database which will contain all the information of the donors like donor
contact details, blood type, address, name, etc.
2. Patient Database : The patient database will maintain information of patients,

like health details, address, blood type needed, hospital, etc.
3. Blood Inventory DatabaseThis database has all the inventory of the blood units
collected. In certain cases when a blood unit is to be deleted or added the
updation is done in this database.
4. Order DatabaseThe Blood Bank Manager has access to this database where
he can view all the orders which are placed. This database contains all previous
and current orders which are placed.
3.5 DESIGN CONSTRAINTS
There will be a GUI having multiple functionalities.
3.5.1 Standards Compliance.
1. Hard Drive Space

PLAN: Not more than 15MB
MUST: Not more than 20MB
WISH: Not more than 10MB
2. Application Memory UsageThe amount of Operating System memory occupied

by the application when it is accessed.
PLAN: Not more than 16MB
MUST: Not more than 20MB
WISH: Not more than 10MB
3.6 SOFTWARE SYSTEM ATTRIBUTES
Attributes:
Login and registration of donors and patients.
Patients can efficiently search for the donor according to the blood type.
Donor details are made available to the patient.
14 v. 1.0 2006
3.6.1 Reliability
As the system provide the right tools for problem solving it is made in
such a way that the system is reliable in its operations and for securing the
sensitive details.
3.6.2 Availability
● The system should be available at all times, meaning the user can access
it using an application.
● 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 application data
folder and
● saved by the administrator.
● It means 24 x 7 availability.
3.6.3 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
3.6.4 Portability
ID Characteristic Rank
1 Correctness 1
2 Efficiency 1
3 Flexibility 2
4 Integrity 1
5 Interoperability 2
6 Maintainability 2
7 Portability 1
8 Reliability 2
9 Reusability 2
10 Testability 2
11 Usability 3
12 Availability 2
15 v. 1.0 2006
3.7 ORGANIZING THE SPECIFIC REQUIREMENTS
Requirements of the system are to enter the donor details and the patients
details by themselves by registering into the website and filling their respective
profiles. The patients can search for a donor of a specific blood type by using the
search bar available on the website and can also contact the donor by using the
donor details which are filled by the donor. The hospital incharge will post the
blood reports of each donor to them and maintain it in the database. The
administrator will manage all the records of each and every user of the website.
The chatbot will enable all the users to discuss among themselves regarding any
queries or emergencies.
3.7.1 System Mode
The proposed website works for the four modes like the administrator, donor,
patients and hospital incharge.
The administrator will manage the records of all types of users mentioned above
and authenticate their login.
The donor and patients will login into the system and enter their required details.
The hospital incharge will manage the blood reports of the patients and the
donors.
3.7.2 User Class
● System Owner: The Blood Bank System

● Users:
● Administrators: has full privilege on the system's functions
● Public: can view the blood donation events and donate or can make
requests for donation (Donor and Recipients fall under this category).
3.7.3 Feature
● Easy to Understand It is the basic model of all models.

● Errors are detected after each Phase of Development.
● It is a Single and Small Project.
3.7.4 Stimulus
In case of emergency, the patients can discuss their issues with other users
using the chatbot available. Also the chatbot will make other donors aware by
providing information regarding the blood donation camps available in the city.
16 v. 1.0 2006
3.7.5 Response
The hospital incharge will post the blood reports of donors to them and also save
them in the database for future use. Also can provide details to the required
patients. The patients can clear their queries using the chatbot available and can
also be made aware regarding the blood donation camps.
3.7.6 Functional Hierarchy
3.8 ADDITIONAL COMMENTS
Introduction: Blood bank management website.

Inputs: Details of the patients and donors
17 v. 1.0 2006
Processing: Searching for the donors of a specific type of blood group, inserting
the input records into the database.
Output: Showing the results to the specified users and discussing problems and
emergencies using the chatbot.
4. SUPPORTING INFORMATION.
Process Model
Tables on the following pages provide alternate ways to structure section 3 on the specific
requirements.
DOCUMENT CONTROL
CHANGE HISTORY
Release
Revision Description [list of changed pages and reason for change]
Date
DOCUMENT STORAGE
This document was created using . The file is stored .
DOCUMENT OWNER
is responsible for developing and maintaining this document.
18 v. 1.0 2006
APPENDICES
A.1 Outline for SRS Section 3: Organized by mode: Version 1
3 Specific Requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Functional requirements
3.2.1 Mode 1
3.2.1.1 Functional requirement 1.1
.....
3.2.1.n Functional requirement 1.n
3.2.2 Mode 2
.....
3.2.m Mode m
3.2.m.1 Functional requirement m.1
.....
3.2.m.n Functional requirement m.n
3.3 Performance Requirements
3.4 Design Constraints
3.5 Software system attributes
3.6 Other requirements
19 v. 1.0 2006
Outline for SRS Section 3: Organized by mode: Version 2
3.1 Functional Requirements
3.1.1 Mode 1
3.1.1.1 External interfaces
3.1.1.1 User interfaces
3.1.1.2 Hardware interfaces
3.1.1.3 Software interfaces
3.1.1.4 Communications interfaces
3.1.1.2 Functional Requirement
3.1.1.2.1 Functional requirement 1
.....
3.1.1.2.n Functional requirement n
3.1.1.3 Performance
3.1.2 Mode 2
.....
3.1.m Mode m
3.2 Design constraints
20 v. 1.0 2006
Outline for SRS Section 3: Organized by user class
3.2.1 User class 1
.....
3.2.2 User class 2
.....
3.2.m User class m

.....
21 v. 1.0 2006
Outline for SRS Section 3: Organized by object
3.2 Classes/Objects
3.2.1 Class/Object 1
3.2.1.1 Attributes (direct or inherited)
3.2.1.1.1 Attribute 1
.....
3.2.1.1.n Attribute n
3.2.1.2 Functions (services, methods, direct or inherited)

3.2.1.2.1 Functional requirement 1.1
.....
3.2.1.2.m Functional requirement 1.m
3.2.1.3 Messages (communications received or sent)
3.2.2 Class/Object 2
.....
3.2.p Class/Object p
22 v. 1.0 2006
Outline for SRS Section 3: Organized by use case
An alternative to embedding the use cases in line with the functional requirements (as shown
below) is to provide the use cases separately from the SRS and refer to the use case name or ID
for each functional requirement in the SRS.
3.2 Functional Requirements
3.1.1.2 Functional Requirement
Use case for functional requirement 1
.....
Use case for functional requirement n
23 v. 1.0 2006
Outline for SRS Section 3: Organized by feature
3.3 System features
3.2.1 System Feature 1
3.2.1.1 Introduction/Purpose of feature
3.2.1.2 Stimulus/Response sequence
3.2.1.3 Associated functional requirements
.....
3.2.2 System Feature 2
.....
3.2.m System Feature m
.....
24 v. 1.0 2006
Outline for SRS Section 3: Organized by stimulus
3.2.1 Stimulus 1
.....
3.2.2 Stimulus 2
.....
3.2.m Stimulus m
.....
25 v. 1.0 2006
Outline for SRS Section 3: Organized by response
3.2.1 Response 1
.....
3.2.2 Response 2
.....
3.2.m Response m
.....
26 v. 1.0 2006
Outline for SRS Section 3: Organized by functional hierarchy
3.2.1 Information flows
3.2.1.1 Data flow diagram 1
3.2.1.1.1 Data entities
3.2.1.1.2 Pertinent processes
3.2.1.1.3 Topology
3.2.1.2 Data flow diagram 2
3.2.1.2.1 Data entities
3.2.1.2.2 Pertinent processes
3.2.1.2.3 Topology
.....
3.2.1.n Data flow diagram n
3.2.1.n.1 Data entities
3.2.1.n.2 Pertinent processes
3.2.1.n.3 Topology
3.2.2 Process descriptions
3.2.2.1 Process 1
3.2.2.1.1 Input data entities
3.2.2.1.2 Algorithm or formula of process
3.2.2.1.3 Affected data entities
3.2.2.2 Process 2
3.2.2.2.1 Input data entities
3.2.2.2.2 Algorithm or formula of process
3.2.2.2.3 Affected data entities
.….
3.2.2.m Process m
3.2.2.m.1 Input data entities
3.2.2.m.2 Algorithm or formula of process
3.2.2.m.3 Affected data entities
3.2.3 Data construct specifications
3.2.3.1 Construct 1
3.2.3.1.1 Record type
3.2.3.1.2 Constituent fields
3.2.3.2 Construct 2
3.2.3.2.1 Record type
3.2.3.2.2 Constituent fields
…..
3.2.3.p Construct p
3.2.3.p.1 Record type
3.2.3.p.2 Constituent fields
3.2.4 Data dictionary
3.2.4.1 Data element 1
3.2.4.1.1 Name
3.2.4.1.2 Representation
3.2.4.1.3 Units/Format
3.2.4.1.4 Precision/Accuracy
3.2.4.1.5 Range
27 v. 1.0 2006
3.2.4.2 Data element 2

3.2.4.2.1 Name
3.2.4.2.2 Representation
3.2.4.2.3 Units/Format
3.2.4.2.4 Precision/Accuracy
3.2.4.2.5 Range
…..
3.2.4.q Data element q
3.2.4.q.1 Name
3.2.4.q.2 Representation
3.2.4.q.3 Units/Format
3.2.4.q.4 Precision/Accuracy
3.2.4.q.5 Range
28 v. 1.0 2006
Outline for SRS Section 3: Showing multiple organizations
3.2.1 User class 1
3.2.1.1 Feature 1.1
3.2.1.1.1 Introduction/Purpose of feature
3.2.1.1.2 Stimulus/Response sequence
3.2.1.1.3 Associated functional requirements
3.2.1.2 Feature 1.2
3.2.1.2.1 Introduction/Purpose of feature
3.2.1.2.2 Stimulus/Response sequence
3.2.1.2.3 Associated functional requirements
…..
3.2.1.m Feature 1.m
3.2.1.m.1 Introduction/Purpose of feature
3.2.1.m.2 Stimulus/Response sequence
3.2.1.m.3 Associated functional requirements
3.2.2 User class 2
.....
3.2.n User class n
.....
29 v. 1.0 2006

SDM LAB 2-Software - Requirements - Specification

Uploaded by

Copyright:

Available Formats

SDM LAB 2-Software - Requirements - Specification

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SDM LAB 2-Software - Requirements - Specification

Uploaded by

Copyright:

Available Formats

Vishwakarma Institute of Technology, Pune-37.

Blood Donation Website

Software Requirements Specification

Prajwal Atram TY_IT_A 06

Approvals Signature Block

Project Responsibility Signature Date

Project Guide (External)

Department of Information Technology

● The project blood bank management system is known to be a pilot project

● It also helps to register the details of donors, blood collection details as

● Everything is being stored in this blood bank management system to help

The specification builds on the experience of IT technology in blood transfusion

1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS

Term or Acronym Definition

1. References provided by Prof. Bibhudatta Sahoo.

Main modules of the project:

To manage employees in the blood bank it had the following modules:

2.1 PRODUCT PERSPECTIVE

PRODUCT POSITION STATEMENT

2.1.1 System Interfaces

2.1.2 User Interfaces

1. Login Module (Donor & Patient)

● Add /Edit/Delete Personal details.

3. Patient / Blood Bank Module

● Add /Edit/Delete Personal or organizational details.

2.1.3 Hardware Interfaces

● 1GHz or High processor

● 500 MB Hard Disk

2.1.4 Software Interfaces

2.1.5 Communications Interfaces

The website should :

● Should run on 500GHz, 64MB Machine.

● Should have a proper internet connection.

● The response time for a change will be more than 4 seconds.

2.1.6 Memory Constraints

RAM : Minimum 4GB

Particulars Client system server system

Operating System Windows Linux

Processor Pentium 4 Pentium 4

Hard Disk 40GB 100GB

RAM 256MB 512GB

2.1.8 Site Adaptation Requirements

2.2 PRODUCT FUNCTIONS

Class of use cases Use cases Description

Use cases related to 1.Login of admin. 1.Log admin into the

Use cases related to 1. Enter name 1. Donor will enter

Use cases related to 1. Login of donor 1. Donor will login

2.3 USER CHARACTERISTICS

● The web application is also constrained by the database capacity so it

2.5 ASSUMPTIONS AND DEPENDENCIES

2.6 APPORTIONING OF REQUIREMENTS

1. Access Website:Users should be able to access web-application through

3.1 EXTERNAL INTERFACES

● Change login password.

● Edit donor profile details.

● Search donors for an exact blood group and send messages.

● Update the database.

● Send blood testing details.