<Company Name>

<Blood Donation Management>

Version <1.0>

Blood Bank Management System <Blood Donation Management> <vision document >

Version: <1.0> Date: 10/jan/2012

Revision History
Date Version Description Author

11/jan/2012

1.0

Blood Bank Management System

C Jayagowri Darisa Bhavana

Confidential

<Company Name>, 2002

ii

Blood Bank Management System <Blood Donation Management> <vision document >

Version: <1.0> Date: 10/jan/2012

Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 1.4 References 1.5 Overview 2. Positioning 2.1 Business Opportunity 2.2 Problem Statement 2.3 Product Position Statement 3. Stakeholder and User Descriptions 3.1 Market Demographics 3.2 Stakeholder Summary 3.3 User Summary 3.4 User environment 3.5 Stakeholder Profiles 3.5.1 <Stakeholder Name> 3.6 User Profiles 3.6.1 <Hospital management> 3.7 Key Stakeholder / User Needs 3.8 Alternatives and Competition 3.8.1 <Other online blood banks> 4. Product Overview 4.1 Product Perspective 4.2 Summary of Capabilities 4.3 Assumptions and Dependencies 4.4 Cost and Pricing 4.5 Licensing and Installation 5. Product Features 5.1 <Searching> 6. Constraints 7. Quality Ranges 8. Precedence and Priority 9. Other Product Requirements 9.1 Applicable Standards 9.2 System Requirements 9.3 Performance Requirements 9.4 Environmental Requirements 1 1 1 1 1 1 1 1 2 2 2 2 2 3 3 3 3 3 3 4 4 4 4 4 4 5 5 5 5 5 5 6 6 6 6 6 6 6

Confidential

<Company Name>, 2002

iii

Blood Bank Management System <Blood Donation Management> <vision document >
10. Documentation Requirements 10.1 User Manual 10.2 Online Help 10.3 Installation Guides, Configuration, Read Me File 10.4 Labeling and Packaging 11. Appendix 1 - Feature Attributes 11.1 Status 11.2 Benefit 11.3 Effort 11.4 Risk 11.5 Stability 11.6 Target Release 11.7 Assigned To 11.8 Reason

Version: <1.0> Date: 10/jan/2012

6 6 6 7 7 7 7 7 7 7 7 7 8 8

Confidential

<Company Name>, 2002

iv

Blood Bank Management System <Blood Donation Management> <vision document >

Version: <1.0> Date: 10/jan/2012

<Blood Donation Management>

1. Introduction The purpose of this document is to collect, analyze and define high-level needs and features of the Blood Bank Management System. It focuses on the capabilities needed by the stakeholders, and the target users, and why these needs exist. The details of how the Blood Bank Managemen Systemt fulfils these needs are detailed in the use-case and supplementary specifications.
1.1 Purpose

The purpose of this vision is to develop a clear understanding of the problem statement, who will be benifited by this project, the advantages of this over the prevailing one and the different requiremnts to accomplish this.
1.2 Scope

The scope of this vision is to associate it with the project - Blood Bank Management System. This document influences the design and implementation of the project.
1.3 Definitions, Acronyms and Abbreviations

All the terms are properly abbreviated and therefore there is no need of definitions, acronyms and abbreviations.
1.4 References

Product : Online Shopping Organisation : ASE Authors : Santhosh D, Arun S, Sandeep A, Jaswanth A.
1.5 Overview

This document contains problem statement, list and responsibilities of the stakeholders, requirements for the project, the improvements over the existing system. It is organised in systematic manner starting with the problem description, stakeholders information and requirements. 2. Positioning
2.1 Business Opportunity

The bussiness opppurtunity that can be met by this project is mainly with regards to the hospitals where they can easily get accessed to the details of available units of blood in a particular blood bank of a certain group and this will be a great help to save many lives.

Confidential

<Company Name>, 2000

Blood Bank Management System <Blood Donation Management> <vision document >
2.2 Problem Statement

Version: <1.0> Date: 10/jan/2012

The problem of

Maintaining the record of available units of blood and who are registered in the file system Patients, hospital management Lose of records Effective retrieval of the required records in the required time.

Affects The impact of which is A successful solution would

2.3

Product Position Statement

For Who The (product name) That Unlike Our product 3.

The Hospitals and patients Are in need of a certain group of blood is an online service Helps in getting the details of required units of blood Manual records and file structures Is efficient and high performance product

Stakeholder and User Descriptions

3.1 Market Demographics

The key market demographics that motivated our product decision is to make our product more effective and efficient than the existing systems. By using this system the needs of many hospitals are met in no time so the market demographics of this system is certainly very good. Our product is also strong on the social grounds so it will be a great help for the stakeholders.
3.2 Name Stakeholder Summary Represents Role

Developer

Sophisticated user

The developer is responsible for designingand developing the product with the required functionalities. 2

Confidential

<Company Name>, 2000

Blood Bank Management System <Blood Donation Management> <vision document >

Version: <1.0> Date: 10/jan/2012

3.3 Name

User Summary Description Stakeholder

Casual user

They represent the users of the system

The user is represented by the stakeholder as the blood bank management unit.

3.4

User environment

The number of people involved in completing the task will be two and this will not be subjected into any changes. The task cycle may take up to 12 weeks time. The time required for each phase of the project may differ accordingly. The product can run on any browser and it needs a database support.
3.5 3.5.1 Stakeholder Profiles <Stakeholder Name>

Representative Description Type Responsibilities Success Criteria Involvement Deliverables Comments / Issues
3.6 3.6.1

The stakeholder representative is the developer itself. The developer is expert in the technical side. Technical expert The developer is responsible in designing and developing the product The developer defines success as being able to make the product work efficiently. The developer is very much involved into the product because the major success criteria for the product is the work of the developer. The only deliverable from the developer is well functioning product. Time taken by the search algorithm and storage of the numerous records for effective retrieval.

User Profiles <Hospital management>

Representative Description

Each hospital registered is a user. The hospital registers with the system so that it can get access to the details of the available units of blood. Type The hospital management is the nave user. Responsibilities The responsibility of the hospital is to give thee correct details. Success Criteria The user defines success when he comes across correct requirement and a feasible one. Involvement The user is very much involved with the product because it is this user which makes use of this system more than any other user. Deliverables Deliverables of the user will be the details for registration and providing the correct search criteria. Confidential <Company Name>, 2000 3

Blood Bank Management System <Blood Donation Management> <vision document > Comments / Issues
3.7 Need

Version: <1.0> Date: 10/jan/2012

The problems that we can come across are wrong details and incorrect search criteria.

Key Stakeholder / User Needs Priority Concerns Current Solution Proposed Solutions

Efficiency and speed in finding the appropriate units of blood.

Not computeriz ed so it is difficult to find the available units of blood from existing file structures and written records.

An efficient database and an effective search algorithm.

A database to store all the details about available blood units and registered hospitals and search for the availability of the blood units.

3.8 3.8.1

Alternatives and Competition <Other online blood banks>

Other online blood banks available can be of major competition to our product and this can be overcome only by making it more efficient. 4. Product Overview
4.1 Product Perspective

The product is independent and totally self-contained. From the perspective of the other products this product is much better performing and robust.
4.2 Summary of Capabilities

Our product helps in efficient and quick retrieval of availability of blood units.

Confidential

<Company Name>, 2000

Blood Bank Management System <Blood Donation Management> <vision document > Customer Benefit Hospital registration

Version: <1.0> Date: 10/jan/2012

Customer Support System Supporting Features It helps the product to inform the hospitals about the availability of blood units. Hospital management It helps the hospital management requirements are met on time to meet their requirements on time by informing about the availability of blood units. Details are stored in database Helps in organizing the details and manipulations easy. Distributed servers Replication server allows current database information to be shared across the enterprise. Customers can help Knowledge base can be made themselves, lowering support available over the internet. Includes costs and improving response hypertext search capabilities. time
4.3 Assumptions and Dependencies

This whole product is mainly dependent on the database. If a proper storage unit is not available then all the functionalities of the product gets effected there by effecting the vision.
4.4 Cost and Pricing

As this is a normal database based product it just requires a database on the server system and a cd to install the product.
4.5 Licensing and Installation

Network licensing is an additional requirement for this software. Installation requirements may also affect coding, or create the need for separate installation software. 5. Product Features This product is intended to help the hospital management in acquiring the details of the available units of blood on time.
5.1 <Searching>

This feature of the product helps the user in searching for the availability of blood units using some search criteria.

6.

Constraints If the software is run on a system where Windows is not installed some features may not be available. A minimum amount of 5GB space must be available in each individual system in order to store the details before it is updated in the main database server.

Confidential

<Company Name>, 2000

Blood Bank Management System <Blood Donation Management> <vision document > 7. 8.

Version: <1.0> Date: 10/jan/2012

Quality Ranges This product is efficient and robust in searching and is very user friendly. Precedence and Priority In this product the high priority will be given to the features like registration and searching of blood units in the blood bank. Other Product Requirements A oracle database(back end). Windows OS A front end platform.
9.1 Applicable Standards

9.

Platform compliance standards: Windows. Network permissions.

9.2 System Requirements

Hardware Platform 80486/Pentium or Higher Series Processor. 64 MB or Higher RAM. 1GB or Higher Hard Disk. VGA/SVGA or Higher Color Monitor. 32x or Higher CD-ROM Drive. Key Board. Mouse Printer
9.3 Performance Requirements

For the product to provide high performance it should always have a minimum bandwidth and all the resources that are required for the quick access of the database.
9.4 Environmental Requirements

User environment, resource availability, maintenance issues, error handling and recovery. 10. Documentation Requirements User manuals, online help, Installation guides, configuration and read me files should be provided to the user so that the product becomes more user friendly and user makes less errors.
10.1 User Manual

The user manual for this product should contain the details about all the features of the product so that the user can use it to the fullest. The details of what type of input should be given to the system can also be included to make the product less prone to errors.
10.2 Online Help

The online help for this product can contain all the details of user manual along with the installation guides and steps for configuring the software along with some hyperlinks of similar products. Confidential <Company Name>, 2000 6

Blood Bank Management System <Blood Donation Management> <vision document >
10.3 Installation Guides, Configuration, Read Me File

Version: <1.0> Date: 10/jan/2012

The installation guides, Configuration, Read Me file for the product should contain all the basic details and it should mainly focus on the extra features and requirements of the product.
10.4 Labeling and Packaging

Include copyright, patent notices, logos and trademarks. 11. Appendix 1 - Feature Attributes
11.1 Status

Proposed Approved Incorporate d

Each system has its own database and the main database is updated after each transaction. A decentralized database. The main database is operated on each transaction, if there are any changes the database is reverted back to its previous stable state.

11.2

Benefit

Critical Importan t Useful

Decentralized database, Registration module, Billing module. Searching module Upcoming events and tips module.

11.3

Effort

Designing phase: 1 month Coding: 3 months Testing: 15 days

11.4 Risk

The software comes with a risk that the database details may be accidentally deleted, in order to avoid such risks we use a decentralized database. System crash is another risk involved in order to overcome this risk a regular backup of data must be done.
11.5 Stability

The stability of the software depends on the stability of the database hence an efficient, consistent and decentralized database must be developed.
11.6 Target Release

Version 1.1: Registration module Version 2.1: Searching module Version 3.1: Billing module Confidential <Company Name>, 2000 7

Blood Bank Management System <Blood Donation Management> <vision document > Version 3.2: Complete product
11.7 Assigned To

Version: <1.0> Date: 10/jan/2012

The group for this product consists of two people and both of them are responsible for each phase of the product development.
11.8 Reason

The reason for taking up this product is to make the job of information retrieval easy.

Confidential

<Company Name>, 2000