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 63
Sameer Meshram TY_IT_A 76
Approvals Signature Block

Software Requirements Specification
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 v. 1.0 2006
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
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
4 v. 1.0 2006
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.
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,
IEEERecommended 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:
5 v. 1.0 2006
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
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 Management of data through databases
would 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.
6 v. 1.0 2006
PRODUCT POSITION STATEMENT
[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.
2.1.3 Hardware Interfaces
● 1GHz or High processor
● 512 MB RAM
7 v. 1.0 2006
● 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

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.
8 v. 1.0 2006
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.
● 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
througheither an application browser or similar service on the mobile phone or
computer.
There should not be any limitation to access web-application.
9 v. 1.0 2006
2. User Registration: Given that the user has accessed web-application, then
theuser 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 tologin 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
elementin 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
anemergency 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
andthen 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
bloodstock 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
10 v. 1.0 2006
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
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.
11 v. 1.0 2006
● 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:
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.
12 v. 1.0 2006
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
3.4 LOGICAL DATABASE REQUIREMENTS
1. Donor Database : The receptionist at the Blood Donation Camp will
maintainthe 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
unitscollected. 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

wherehe 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

occupiedby 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:
13 v. 1.0 2006
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.
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
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
14 v. 1.0 2006
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.
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
15 v. 1.0 2006
3.8 ADDITIONAL COMMENTS

Introduction: Blood bank management website.
Inputs: Details of the patients and donors 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
16 v. 1.0 2006
Tables on the following pages provide alternate ways to structure section 3 on the specific
requirements.
DOCUMENT C ONTROL
C HANGE H ISTORY
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.
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
.....
17 v. 1.0 2006
3.2.m Mode m
3.2.2.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
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
18 v. 1.0 2006
Outline for SRS Section 3: Organized by user class
3.2.1 User class 1 3.2.1.1 Functional requirement 1.1
.....
3.2.2 User class 2
.....
3.2.m User class m 3.2.m.1

Functional requirement m.1
.....
3.2.2.n Functional requirement m.n
19 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
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
3.1.1.2.1 Functional requirement 1 Use
case for functional requirement 1
.....
3.1.1.2.n Functional requirement n Use
case for functional requirement n
20 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.1.3.1 Functional requirement 1
.....
3.2.1.3.n Functional requirement n
3.2.2 System Feature 2
.....
3.2.m System Feature m
.....
21 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 3.2.m.1 Functional
requirement m.1
.....
3.2.2.n Functional requirement m.n
22 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
3.2.2.1 Functional requirement m.1
.....
3.2.m.n Functional requirement m.n
23 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 type3.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
3.2.4.2 Data element 2
3.2.4.2.1 Name
24 v. 1.0 2006
3.2.4.2.2 Representation
3.2.4.2.3 Units/Format
3.2.4.2.4 Precision/Accuracy3.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
25 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 sequence3.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
.....
26 v. 1.0 2006

SDM LAB 2-Software - Requirements - Specification

Uploaded by

Document Information

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

Prajwal Atram TY_IT_A 06

Approvals Signature Block

Project Responsibility Signature Date

Project Guide (External)

Department of Information Technology

1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS 4

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.8 Site Adaptation Requirements 6

2.2 PRODUCT FUNCTIONS 7

2.3 USER CHARACTERISTICS 7

2.5 ASSUMPTIONS AND DEPENDENCIES 7

2.6 APPORTIONING OF REQUIREMENTS 7

3.1 EXTERNAL INTERFACES 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.7 ORGANIZING THE SPECIFIC REQUIREMENTS 11

3.7.1 System Mode 11

3.7.2 User Class 11

3.7.6 Functional Hierarchy 12

3.8 ADDITIONAL COMMENTS 12

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

Main modules of the project:

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

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.

● 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

Particulars Client system server system

Operating System Windows Linux

Processor Pentium 4 Pentium 4

Hard Disk 40GB 100GB

RAM 256MB 512GB

● Change login password.

● Edit donor profile details.

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

● Update the database.

● Send blood testing details.

● Change login passwords.

● Edit personal .contact details