Executive Summary:

The purpose of the new system is to create a new database system for the State
firefighters association. This new system will facilitate the association to store the
information about the donors and their history of donation. It will also be able to
add any new donors and update any information as required. The new system will
help keep track of the funds being delivered to the receiving family which makes it
possible to process queries asked by a particular family about the status. This also
helps minimize any fraud activity. The system will be able to generate a report
which includes the number of donations made, names of the donors and the family
members who are receiving the donations. The new system will help the association
to keep track of all the donations being made and will be able to efficiently work.
System Request:

System Request
System Request:

Project Sponsor:

Business Need:

Business Requirements:

Name of project

State Firefighters Association

This project has been initiated to develop a new

system which stores and processes information
about the state firefighters association. To develop a
new efficient database system which stores and
processes information about different types of
donors, their history The system should be able to
generate reports. System should be able to show the
current status of the support the families are about
to get and it should effectively process a query asked
by the funds receiving family.
Storing data about donors.
Shows status of the support being received by a
family
Should add new information about members
To be able to generate reports
Should efficiently process a query

Should store and retrieve the statistics of donation

Business Value:

We expect the new system would resolve issues of

the old system and boost the associations efficiency
by processing information faster.
Conservative estimates of value include
Able to process a query fast within seconds
Will help association to keep track of all the donors
and their donations
Will store and retrieve information which can be
analyzed to improve the current scenario
Will help keep track the status of funds delivered to
the receiving family.

Staff currently has little knowledge about new

Special Issues or
technologies needed for the system to be developed.
Constraints:
Have to successfully migrate the past information to
the new database without any loss of data
Should be able to incorporate the new system within
a specific budget
While the system is being developed, current
information should be successfully stored in some
place and needs to be migrated to the new system
safely.

Feasibility Analysis:
Technical:
Familiarity with the functional area: The association staff have been working on
storing and retrieving information for more than a decade. So the confusion in the
new system will be minimal.

Familiarty with technology: The new system will be developed using MYSQL
database on which they have little knowledge on. But they can hire third parties to
design the system.
Project Size: This system project is a large database creation that will use the
previous information stored and also should be able to perform few new activities.
Compatibility: The old version is in MS DOS and the new system will be on MYSQL.
Whole compatibility needs to be changed and proper care needs to be taken.
Economic:
Total Tangible benefits:

Reduction in fraud
Improving the cost of processing a query
Reduction in time to process a query

Total Intangible benefits

Improve in members satisfaction

Efficient Association
Keeping track of the current status
Able to analyze and gain insights about the donors and the members

Total Cost over 5 years:

NPV after 5 years:
ROI after 5 years:
Breakeven point:
Organizational:
Strategic alignment:
With reduction in to process a query the association will be able to answer the
inquiries made by the members. With the new system the association will be able to
track all the funds which are being transferred to the families.
Project Champions:
Bob Smith
Third parties who help in designing the system
Users:
Association Staff

Association members
Other Stakeholders:
None
Work Plan:
Project effort estimation:
Unadjusted Actor Weighting Table:
Simple actors: 2
Average actors: Members
Complex Actors:
Database Administrator
Unadjusted Use Case Weighting Table:
Simple: 1
The database which interacts with admin and members
Average: 2
Complex: 1
Database Admin

The other details pertaining to Technical complexity and Environmental factors are
listed in the Excel Workbook.

Task Breakdown:
o Acquire information that will be included in the database
o Brainstorm the association of the database
o Brainstorm how queries will be issued
o Design logic for database operations basis
o Create a database
o Input
o Create tables
o Merge and view data
Timeline:
o Acquire info/brainstorm organization of database and queries -- 2 weeks
o Design logic for database operations basis -- 2 weeks
o Creating a database/input/table/Merge and view data -- 1 month
o Testing the designed database -- 1 week
Staff Capabilities Required:
o Understanding of Database architecture
o Working knowledge of database GUI environment (MySQL)
o Knowledge of programming

Requirements Definition:
Nonfunctional Requirements
1. Operational
1. The system will operate in Oracles MySQL
2. The system should be accessible to all association members
3. Admin should be notified when changes are made to database
4. An email should be sent out to the requestor of a query for ID verification, as well
as to the donors.
2. Performance
1. The system must accommodate the current donor information and accommodate
increases in the size of the association
2. Input and output of data must occur within a tolerance of 10-30 seconds
3. Generate Quarterly and Annual reports
4. Should provide the status of funds being transferred
3. Security
1. Only admins should have access to the database.
2. Anyone who needs access to the database will have to ask the president of the
association.
4. Cultural and Political
1. No special cultural and political requirements are anticipated.
Functional Requirements
1. Input Data
1. Data will be fact checked before insertion into database
2. Admin
2. Resolving Queries

1. User makes request to a particular query

2. Admin checks if request is possible
3. Admin executes the query
4. Admin notifies the members the information asked
5. New members can be added
6. Statistics and reports are presented to the association heads
3. Track Status
1. Admin searches for the Recipient ID
1. Recipient name, donation made and current status is shown
2. If any additional information such as donors name is shown
2. Admin searches ID
1. All information regarding a particular member is shown
4. Storing Donor details
1. The history of a donor is stored
2. The statistics of donations and donors is shown
5. Report Generation
1. A Quaterly report showing the donations is generated
2. A annual report showing the donations is generated
Functional Modelling:
Use case diagram:

Activity Diagram:

Use Case Description

Use Case Name:
donors

Storing Information in

Primary Actor:Admin

Stakeholders and Interests:

New members become donors
Different types of donors are categorized
History of donations is saved

ID:

Use Case Type:

Importance Level: Imp

Storing, Essential

Brief Description:

This use case describes how donors information is stored

Trigger:
Type: Association heads ask for the information of donors
Relationships:
Association:

Admin, Association heads, Donors

Include:
Extend:
Generalization:
Normal Flow of Events:
1.
SubFlows:
S-1:
Alternate/Exceptional Flows:

Use Case Description

Use Case Name:

Status Query

Primary Actor:Members

ID:

Importance Level: 2

Use Case Type:

essential

Answering query,

Stakeholders and Interests:

Members ask for a particular query regarding the status of the funds
Admin searches the database and answer the query

Brief Description:

This use case makes the admin answer the queries made by the
members

Trigger: When a member asks a query

Type:
Relationships:
Association:

Members, Admin

Include:
Extend:
Generalization:
Normal Flow of Events:
2.
SubFlows:
S-2:
Alternate/Exceptional Flows:

Use Case Description

Use Case Name:

Report generation

Primary Actor:Admin, Association heads

ID:

Importance Level:
Average

Use Case Type:

Not so essential

Generating reports,

Stakeholders and Interests:

Admin generates the quarterly or annual reports of the donations
Heads analyze the information

Brief Description:

This use case helps admin to generate the reports which are
utilized by the heads

Trigger:
Type: Have to generate quarterly and yearly
Relationships:
Association:

Admin, association heads

Include:
Extend:
Generalization:
Normal Flow of Events:
3.
SubFlows:
S-3:
Alternate/Exceptional Flows:

CRC Card
Front:
Class Name: Member

ID: 1

Description: An individual family member who

are the part of the association

Responsibilities
Responsibility1
Ask any query
Request status of the funds

Type: Concrete Domain

Associated Use Cases: 1

Collaborators
Collaborator1
Inquiry
Status

Back:
Attributes:
Storing and updating any change in information

Relationships:
Generalization (a-kind-of):

Generalization1,

Aggregation (has-parts):

Aggregation1

Other Associations:

Query, Status, updating any information

CRC Card
Front:
Class Name: Query

ID: 2

Description: Set of questions asked by

members

Responsibilities
Responsibility1

Type: Concrete Domain

Associated Use Cases: 2

Collaborators
Collaborator1

Resolve query

Query answered

Back:
Attributes:
Resolving Query

Relationships:
Generalization (a-kind-of):

Generalization1,

Aggregation (has-parts):

Aggregation1

Other Associations:

CRC Card
Front:

Member, Admin

Class Name: Report

ID: 3

Type: Concrete Domain

Description: This generates reports which can

be analyzed

Associated Use Cases: 3

Responsibilities

Collaborators

Responsibility1

Collaborator1

Generate Quarterly Reports

Analyze quarterly reports

Generate Annual reports

Analyze annual reports

Back:
Attributes:
Report Generation

Relationships:
Generalization (a-kind-of):

Generalization1,

Aggregation (has-parts):

Aggregation1

Other Associations:

Class Diagram:

Admin, Association Heads

Sequence Diagram:

Communication Diagram:

Behavioral Diagram:

Actor: Use Case \ Data Object

Instance

database

Admin Enter New/ Update members

Info
Admin: Answer Query

CURD

Admin: Generate report

CURD

Head: Analyze report

CURD

Report
CURD
CUR
CUD

Query
CURD
CUR
CR

CURD

Member: ask query

Member: status

CR

Package Diagram:

Class and Method Diagram:

3NF tables and Relational schema:

member(user_id(PK), user_name, user_phone,user_mail)
Data admin (id(PK),query_id(FK),report_id(FK),Donation_ID(FK))
Donation (donation_id(PK), user_id(fk),donation_details)
Staff(staff_id(PK),Name,Phone_number,Report_ID(FK))
Report(Report_ID(PK),Report_details,Staff_ID(FK))
Query(Query_ID(PK),Member_ID(FK),Staff_ID(FK))

Page navigation and input output diagram: