Elaboration Spec · 2018. 11. 30. · Stable Geniuses @HOOF KY, 2018 Page 11 Trace Matrix Trace...

Elaboration Spec

Luke Fougerouse, Matthew Volpert, Tyler Martin, Jai Nigam, Patrick Mohr

Table of Contents

Stable Geniuses

@HOOF KY, 2018

Page 1

System Requirements……………………………………………………………………………………………………………2

Use Case Diagrams...…………………………………………………………………………………….……………………….3

Trace Matrix…………………………………………………………………………………………………….………………….11

Use Cases and Sequence Diagrams……………..……………………………………………………..………………..14

Class Diagram…………………………………………..………………………………………………………………………….92

Database Design……….………………………………………………………………………………………………………...94

Data Definitions……………….………………………………………………………………………………………….……...95

User Interface Navigation Diagram……………………………………………………………………………….……121

Screen Layout…………………………………………………………………………………………………………………….123

Physical Architecture Design…………………….…………………………………………………….………………….124

Design Procedures for Security Design……………………………………………………………………….……...125

Gantt Chart….………………………………………………………………………………......................................126

Elaboration Phase Prototypes……………….……………………………………………………………………………127

Stable Geniuses

@HOOF KY, 2018

Page 2

System Requirements

The System Requirements provide a description of all the requirements that the HOOF IT system

will have. The requirements are statements of what the HOOF IT system will do and the characteristics

that it will have. These requirements are things that will be found on the HOOF website, that database,

server, etc. and relate to users such as the board members, volunteers, camp participants, and potential

donors. The requirements are both functional and nonfunctional. Functional requirements relating to

processes that the system/database will do and the information it will contain. Nonfunctional

requirements describing more of the characteristics of the system.

The new system shall:

1. contain an administrator login for each board member.

2. allow administrators(board members) to add, modify, and delete data.

3. enroll new campers.

4. provide a camper application form through the website.

5. allow a parent to input their contact information into the camper application form.

6. store/manage camper information.

7. enroll new volunteers.

8. provide a volunteer application form through the website.

9. manage/store volunteer contact information.

10. enroll donors.

11. manage/store donor information into a database.

12. allow donors to donate money on the website.

13. provide all the tax deductible sponsorship options for the donors.

14. provide the electronic payment options through PayPal.

15. The system shall provide information on HOOF fundraising events.

16. The system shall allow HOOF administrators to display fundraiser event details through the

website.

17. store/manage silent auction items in a database.

18. have a cloud computing service, Microsoft Azure.

19. store data in one secure location.

20. provide universal data access for the board members.

21. store all HOOF’s financial data includes balance sheets, expenses, income statements, etc.

22. store all of the data pertaining to grants.

23. let the board directors produce financial reports from the database.

24. provide links to the various HOOF social media platforms such as Twitter, Facebook, and

Instagram.

25. provide detailed information on HOOF’s mission.

26. add new auction items into the database.

27. have merchandise available to order.

28. store data on merchandising sales.

Stable Geniuses

@HOOF KY, 2018

Page 3

Use Case Diagrams

What is a Use Case Diagram?

A use case diagram is a visual representation of the interactions between the user and the system. The

descriptions in the circles are specific actions that the system can execute. Each action has an actor who

interacts with it, depicted by a stick figure outside the borders.

Diagrams

Camper Information

This use case diagram depicts a volunteer or an agency will be the ones to add the campers information into

HOOFs system along with the HOOF admin who will be in control of modifying or deleting information regarding a

camper.

Stable Geniuses

@HOOF KY, 2018

Page 4

Donor Information

This use case demonstrates how donor information is captured and recorded in the HOOF system.

Volunteer Information

This use case is associated with a HOOF admin adding, editing, or deleting an active Volunteer in the HOOF system.

Adding volunteer information is used after an application is accepted and the individual is being added as an

official volunteer for the organization.

Stable Geniuses

@HOOF KY, 2018

Page 5

Volunteer Application

This allows a volunteer, and in some cases a HOOF admin, to add, modify, and delete a Volunteer’s application.

Since applying for a position is mainly the responsibility of the volunteer, they are the ones to add and edit

applications. The HOOF Admin has the authority to delete applications as they are accepted, declined, or

cancelled.

Collect Donation

This use case demonstrates the donation process, Donor information is captured upon collection if not already

recorded in the system.

Stable Geniuses

@HOOF KY, 2018

Page 6

Add/Edit/Delete Sponsorship

This use case goes through the process of finding sponsors, and what is done when sponsorships are collected.

Volunteer Hours

This allows either a HOOF admin or volunteer to add, modify, or delete the hours of service completed. They are

able to submit the hours and duties of the service directly into the HOOF website. Volunteers are typically

expected to enter hours worked; however, the admin staff has access to make changes, if needed.

Stable Geniuses

@HOOF KY, 2018

Page 7

Database

Since the database is a vital part of HOOF’s business, it’s important to have creation, update and deletion of these

databases kept to board members as to avoid accidental addition or deletion of materials.

Financial Data

Like the databases, financial data is something that needs to be accessible to volunteers and board members, but

the manipulation of data should be kept under close supervision.

Stable Geniuses

@HOOF KY, 2018

Page 8

Financial Reports

The ability to add financial documents/reports to the database is a key feature of the database system, that should

be limited to only HOOF Board Members.

Social Media

Social Media is a powerful tool for business and marketing purposes, this database gives both Board Members and

Volunteers the ability to add and access the HOOF social media accounts and manage them in the system.

Stable Geniuses

@HOOF KY, 2018

Page 9

Mission Statement

The system allow Board Members to be able to access the website and enter the mission statement so that it will

appear on a web page on the website

Fundraiser

It is important to allow both Board Members and Volunteers to be able to access information regarding fundraiser

data and add or update any details regarding fundraiser time, location, etc.

Stable Geniuses

@HOOF KY, 2018

Page 10

Auction Items

In order to make operations easier on staff, having the ability to add auction items should be available to anyone

who wants to donate or staff, though these should only be modifiable and deletable by staff.

Login

Logging in to the website should be accessible to everyone using the site with different levels of

accessibility given to different groups. These should be modifiable and deletable in case a user forgets

their username, password, or wants to get rid of their account.

Stable Geniuses

@HOOF KY, 2018

Page 11

Trace Matrix Trace Matrix

The Trace Matrix shows the relationship between the use case’s and system requirements by showing which use cases are dependent on the system requirements with an X.

UC.1

UC.2

UC.3

UC.4

UC.5

UC.6

UC.7

UC.8

UC.9

UC.10

UC.11

UC.12

UC.13

UC.14

UC.15

UC.16

UC.17

UC.18

UC.19

UC.20

SR.1 X X SR.2 X X X X X X X X X X X X X X X X X X X SR.3 X SR.4 X SR.5 X SR.6 X X X SR.7 X SR.8 X SR.9 X X X X X X X X X SR.10 X X X SR.11 X X X SR.12 X X X X X SR.13 SR.14 SR.15 SR.16 SR.17

Stable Geniuses

@HOOF KY, 2018

Page 12

SR.18 SR.19 SR.20 SR.21 SR.22 SR.23 SR.24 SR.25 SR.26 SR.27 X SR.28

UC.21

UC.22

UC.23

UC.24

UC.25

UC.26

UC.27

UC.28

UC.29

UC.30

UC.31

UC.32

UC.33

UC.34

UC.35

UC.36

UC.37

UC.38

SR.1

SR.2 X X X X X X X X X X X X X X X X X X

SR.3

SR.4

SR.5

SR.6

SR.7

SR.8

SR.9

SR.10 SR.11

Stable Geniuses

@HOOF KY, 2018

Page 13

SR.12 X SR.13 X X X SR.14 X X X SR.15 SR.16 SR.17 SR.18 X X X SR.19 X X X X X X X X X X X SR.20 X X X X X X X X X X X SR.21 X X SR.22 X X X SR.23 X X X X X SR.24 SR.25 SR.26 SR.27 SR.28 X X X X X

UC.39

UC.40

UC.41

UC.42

UC.43

UC.44

UC.45

UC.46

UC.47

UC.48

UC.49

UC.50

UC.51

UC.52

UC.53

UC.54

SR.1 X X X

SR.2 X X X X X X X X X X X X X X X X

SR.3

SR.4

SR.5

SR.6

SR.7

SR.8

SR.9

SR.10

SR.11

Stable Geniuses

@HOOF KY, 2018

Page 14

SR.12

SR.13

SR.14

SR.15 X X X

SR.16 X X X

SR.17 X X X

SR.18

SR.19 X

SR.20 X

SR.21 X

SR.22

SR.23 X

SR.24 X X X

SR.25 X X X

SR.26 X X X

SR.27

SR.28 X

Stable Geniuses

@HOOF KY, 2018

Page 15

Use Cases

Use Cases are used to explain and document the interactions between the user and the system to

accomplish the user’s task. These are made to help understand more fully the steps that are involved in

accomplishing the user’s goals. We have also labeled the Use Cases that have the highest and lowest risk

in the far-right column.

Name: Add Camper

● Brief Description: ○ This use case describes the process of the Agency or Volunteer to add a new camper’s

information to the system. ● Actor(s):

○ Agency ○ Volunteer

● Basic Flow ○ User enters first name. ○ User enters middle initial. ○ User enters last name. ○ User enters gender. ○ User enters ethnicity. ○ User enters date of birth. ○ User enters street address. ○ User enters city. ○ User enters state. ○ User enters zip code. ○ User enters country. ○ User enters school name. ○ User enters grade. ○ User enters district. ○ User enters Agency/Volunteer name. ○ User uploads parent waiver. ○ User enters shirt size. ○ User hits submit button.

● Pre-conditions: ○ User has access to the HOOF website.

● Post-conditions: ○ The camper will be added to the system

Stable Geniuses

@HOOF KY, 2018

Page 16

Stable Geniuses

@HOOF KY, 2018

Page 17

Name: Modify Camper ● Brief Description:

○ This Use Case describe the process of a camper being modified within the system. ● Actor(s):

○ Administrative Staff ● Basic Flow:

○ User logs into account. ○ User edits first name. ○ User edits middle initial. ○ User edits last name. ○ User edits gender. ○ User edits ethnicity. ○ User edits date of birth. ○ User edits street address. ○ User edits city. ○ User edits state. ○ User edits zip code. ○ User edits country. ○ User edits school name. ○ User edits grade. ○ User edits district. ○ User edits Agency/Volunteer name. ○ User edits parent waiver. ○ User edits shirt size. ○ User hits submit button.

● Alternative Flows: ○ The information entered could contain missing information ○ The information entered could have the wrong information.

● Pre-conditions: ○ User must have access to HOOF’s website. ○ User must log into their account.

● Post-conditions: ○ The camper’s information is updated.

● Extension Points: ○ A camper must be added to the system before the camper can be modified.

Stable Geniuses

@HOOF KY, 2018

Page 18

Name: Delete Camper

● Brief Description:

○ This use case describes the process of a camper being removed from the system.

● Actor(s):

○ Administrative Staff

● Basic Flow:

○ User logs into account.

○ User deletes first name.

○ User deletes middle initial.

○ User deletes last name.

○ User deletes gender.

○ User deletes ethnicity.

○ User deletes date of birth.

○ User deletes street address.

○ User deletes city.

○ User deletes state.

○ User deletes zip code.

○ User deletes country.

○ User deletes school name.

○ User deletes grade.

○ User deletes district.

○ User deletes Agency/Volunteer name.

○ User deletes parent waiver.

○ User deletes shirt size.

○ User hits submit button.

● Pre-conditions:

○ User must have access to HOOF’s website.

○ User must log into their account.

● Post-conditions:

○ The camper is removed from the system.

● Extension Points:

○ A camper must be added to the system before it may be removed.

Stable Geniuses

@HOOF KY, 2018

Page 19

Stable Geniuses

@HOOF KY, 2018

Page 20

Name: Add Volunteer Information

● Brief Description: This allows a user to add a new volunteer’s information

● Actor: Administrative staff

● Basic Flow

○ User logs in

○ User enters Volunteer’s first name

○ User enters Volunteer’s last name

○ User enters Volunteer’s Middle Initial

○ User enters Volunteer’s Address

○ User enters Volunteer’s City

○ User enters Volunteer’s State

○ User enters Volunteer’s Zip code

○ User enters Volunteer’s Phone Number

○ User selects Submit

● Exception Flow

○ User cancels addition of volunteer information

● Precondition

○ User has access to the HOOF website

○ Volunteer is a US resident

● Postcondition

○ Volunteer is added to the system

Stable Geniuses

@HOOF KY, 2018

Page 21

Name: Modify Volunteer Information

● Brief Description: This allows a user to edit already existing volunteer information

● Actors: Administrative staff

● Basic Flow

○ User logs into volunteer’s profile

○ User modifies Volunteer’s first name

○ User modifies Volunteer’s last name

○ User modifies Volunteer’s Middle initial

○ User modifies Volunteer’s Address

○ User modifies Volunteer’s City

○ User modifies Volunteer’s State

○ User modifies Volunteer’s Zip code

○ User modifies Volunteer’s Phone Number

○ User selects Save

● Exception Flow

○ User no longer needs to update volunteer information

● Precondition

○ User has access to volunteer’s information

○ User is authorized to update information

● Postcondition

○ Volunteer’s information is updated

Stable Geniuses

@HOOF KY, 2018

Page 22

Name: Delete Volunteer Information

● Brief Description: This allows a user to remove a volunteer from the system


● Basic Flow:

○ User logs into HOOF website

○ User accesses volunteer’s profile

○ User selects Delete information

○ User selects yes when prompted with a warning message

● Alternative Flow

○ User deletes each piece of information one at a time

● Exception Flow

○ User decides not to delete the volunteer’s information

● Precondition

○ User is authorized to log into HOOF website

○ User is authorized to delete Volunteers

● Postcondition

○ Volunteer is deleted

Stable Geniuses

@HOOF KY, 2018

Page 23

Name: Add Volunteer application

● Brief Description: This allows the user to create and submit a volunteer application on the HOOF website

● Actors: Volunteer

● Basic Flow

○ User selects Volunteer application

○ User enters Volunteer’s first name

○ User enters Volunteer’s last name

○ User enters Volunteer’s Middle Initial

○ User enters Gender

○ User enters Volunteer’s Address

○ User enters Volunteer’s City

○ User enters Volunteer’s State

○ User enters Volunteer’s Zip code

○ User enters Volunteer’s Phone Number

○ User enters Volunteer’s Availability days and hours


● Exception Flow

○ User cancels application

● Preconditions

○ User has access to HOOF’s website

○ User is a US resident

● Postconditions

● A volunteer application is submitted

Stable Geniuses

@HOOF KY, 2018

Page 24

Name: Modify Volunteer Application

● Brief Description: This allows a user to make changes to an existing volunteer application.

● Actors: Volunteer

● Basic Flow

○ User selects Volunteer application

○ User selects Edit Volunteer application

○ User modifies Volunteer’s first name

○ User modifies Volunteer’s last name

○ User modifies Volunteer’s Middle Initial

○ User modifies Gender

○ User modifies Volunteer’s Address

○ User modifies Volunteer’s City

○ User modifies Volunteer’s State

○ User modifies Volunteer’s Zip code

○ User modifies Volunteer’s Phone Number

○ User modifies Volunteer’s Availability days and hours


● Exception Flow

○ User cancels changes to application

● Preconditions

○ User has access to HOOF’s website

● Postcondition

○ Volunteer modifications are saved

Stable Geniuses

@HOOF KY, 2018

Page 25

Name: Delete Volunteer Application

● Brief Description: This allows a user to delete an existing volunteer application

● Actors: Volunteer or Administrative Staff

● Basic Flow

○ User selects Volunteer applications

○ User selects desired application to delete

○ User selects Delete Application


○ User deletes Volunteer’s first name

○ User deletes Volunteer’s last name

○ User deletes Volunteer’s Middle Initial

○ User deletes Gender

○ User deletes Volunteer’s Address

○ User deletes Volunteer’s City

○ User deletes Volunteer’s State

○ User deletes Volunteer’s Zip code

○ User deletes Volunteer’s Phone Number

○ User deletes Volunteer’s Availability days and hours

○ User selects save

● Exception Flow

○ User cancels deleting the application

● Preconditions

○ User has access to HOOF website

○ User is authorized to delete application

● Postcondition

○ Volunteer application is deleted

Stable Geniuses

@HOOF KY, 2018

Page 26

Name: Add Volunteer Hours

● Brief Description: This allows a user to add a volunteers work hours

● Actors: Volunteer or Administrative Staff

● Basic Flow

○ User Logs into HOOF website

○ User selects Volunteer profile

○ User selects Volunteer hours

○ User enters date of service

○ User selects total hours from drop down

○ User enters duties completed

○ User selects submit

● Exception Flow

○ User does not add volunteer hours

● Precondition

○ User has access to Volunteers’ profile

○ User is authorized to add hours

● Postcondition

○ Volunteer hours entry is added

Stable Geniuses

@HOOF KY, 2018

Page 27

Name: Edit Volunteer Hours

● Brief Description: This allows a user to update an already existing volunteer hour entered

● Actor: Volunteer or Administrative Staff

● Basic Flow

○ User Logs into HOOF website

○ User selects an existing hour entry

○ User updates date of service

○ User updates total hours from drop down

○ User updates duties completed


● Exception Flow

○ User does not update the volunteer hours

● Preconditions

○ User has a valid login to HOOF’s website

○ User is authorized to update hours

● Postcondition

○ Volunteer hours entry is updated

Stable Geniuses

@HOOF KY, 2018

Page 28

Name: Delete Volunteer hours

● Brief Description: This allows a user to delete an existing volunteer hour entry

● Actor: Volunteer or Administrative staff

● Basic Flow

○ User logs into HOOF website

○ User selects an existing hour entry

○ User selects Delete entry

○ User selects yes when prompted with a warning message

● Exception Flow

○ User does not delete the volunteer hours

● Preconditions

○ User has a valid login to HOOF’s website

○ User is authorized to delete hours

● Postcondition

○ Volunteer hours entry is deleted

Stable Geniuses

@HOOF KY, 2018

Page 29

Name: Add Donor

● Brief Description: The purpose is to have a record of these donors’ contact information for future

reference -to ask for future donations. The risk for entry is high because this is crucial information for the

organization.

● Actor: Administrative staff

● Basic Flow

○ User logs in

○ User enters Donor’s first name

○ User enters Donor’s last name

○ User enters Donor’s Middle Initial

○ User enters Donor’s Address

○ User enters Donor’s City

○ User enters Donor’s State

○ User enters Donor’s Zip code

○ User enters Donor’s Phone Number


● Exception Flow

○ User cancels addition of Donor information

● Precondition

○ Donor has made a payment to HOOF

○ Actor has access to website

● Postcondition

○ Donor is added to the system

Stable Geniuses

@HOOF KY, 2018

Page 30

Name: Modify Donor

● Brief Description: This allows a user to edit already existing donor information


● Basic Flow

○ User logs into Donor’s profile

○ User modifies fields that need updating


● Exception Flow


● Precondition

○ User has access to donor’s information

○ User is authorized to update information

○ Donor information has already been added to system

● Postcondition

○ Donor’s information is updated

Stable Geniuses

@HOOF KY, 2018

Page 31

Name: Delete Donor

● Brief Description: This allows a user to delete a donor’s information


● Basic Flow

○ User logs into volunteer’s profile

○ User deletes profile via a single Delete button



○ User deletes Donor’s first name

○ User deletes Donor’s last name

○ User deletes Donor’s Middle Initial

○ User deletes Donor’s Gender

○ User deletes Donor’s Address

○ User deletes Donor’s City

○ User deletes Donor’s State

○ User deletes Donor’s Zip code

○ User deletes Donor’s Phone Number


● Exception Flow


● Precondition

○ Donor information already exists

○ User has access to Donor’s information

○ User is authorized to delete information

● Postcondition

○ Volunteer’s information is deleted

Stable Geniuses

@HOOF KY, 2018

Page 32

Name: Collect Donation

● Brief Description: A primary source of income for the nonprofit. Methods of collection include: in-person,

mail-in, call-in, debiting a card on file if one exists, and PayPal which can also support recurring

payments/donations.

● Actors: HOOF employee/volunteer

● Basic Flow

○ User visits the HOOF KY website

○ Clicks on Donate button

○ Brings you to donation page, must click another donate button

○ Takes you to PayPal portal where user completes the donation process

● Alternative Flows

○ Donor calls HOOF and gives receptionist credit card information

○ OR

○ Donor visits HOOF and delivers cash or check

○ OR

○ Donor mails a check (not advisable)

○ OR

○ For fundraising events like auctions, donor will bring an item for auction as a donation

● Exception Flow

○ User no longer needs to update donor information

○ Donor reconsiders the donation

○ Volunteer refunds the donation

● Precondition

○ Donor information may already exist

○ User is authorized to add, update, delete information

● Postcondition

○ Donor’s information is deleted

○ User has access to Donor’s information to update/delete if necessary

Name: Add Sponsorship

Stable Geniuses

@HOOF KY, 2018

Page 33

● Brief Description: A secondary source of income for the nonprofit. Involves recruiting sponsors and

advertising the organization.

● Actors: HOOF volunteer

● Basic Flow

○ HOOF volunteer may compose RFI documents or elicit sponsors via other recruitment means

○ Sponsors get their business logo advertised on a prominent spot on the HOOF website - HOOF

volunteer places logo under Sponsor section on the home subpage or donation subpage

● Exception Flow

○ User has no need to enter Sponsor information (already recorded)

● Precondition

○ Sponsor information may already exist


● Postcondition

○ User has access/permission to Sponsor’s information to update/delete if necessary

Stable Geniuses

@HOOF KY, 2018

Page 34

Name: Edit Sponsorship

● Brief Description: Sponsor may adjust donation amount or their information may need to be updated


● Basic Flow

○ HOOF volunteer logs on to system

○ Access sponsor information and makes the necessary changes

● Exception Flow

○ User no longer needs to update Sponsor information

● Precondition

○ Sponsor information already exists


Stable Geniuses

@HOOF KY, 2018

Page 35

Name: Delete Sponsor

● Brief Description: A sponsor has ended their sponsorship, or the term of the sponsorship have concluded.


● Basic Flow

○ HOOF volunteer may compose RFI documents or elicit sponsors via other recruitment means

○ Sponsors get their business logo advertised on a prominent spot on the HOOF website - HOOF

volunteer places logo under Sponsor section on the home subpage or donation subpage

● Exception Flow

○ User no longer needs to update Sponsor information

● Precondition

○ Sponsor information may already exist


● Postcondition

User has access/permission to Sponsor’s information to update/delete if necessary

Stable Geniuses

@HOOF KY, 2018

Page 36

Name: Add Database

● Brief Description: ○ Allows for the addition of new databases, which store the information necessary to run HOOF.

When a database is added, information important to HOOF’s operations become easier to find with the right searches. When explaining this use case, the term “user” will be used frequently to denote the person attempting to add the database.

● Actors: Board of Directors ● Basic Flow:

○ User enters a database name. ○ User enters a starting database size if desired. A default size will be selected if no size is entered. ○ User hits submit. ○ System creates the database. ○ System loads form asking for data tables to add to database. ○ User cancels out of form. ○ System closes the tables form.

● Alternative Flows ○ Adding tables and fields during the database addition

After creating the database, the table can be filled in with tables and field information. These can be done separately using the edit function described in UC.38 (Modify Database), or at the same time.

■ User enters a database name. ■ User enters a starting database size if desired. A default size will be selected if no size is

entered. ■ User hits submit. ■ System creates the database. ■ System loads form asking for data tables to add to database. ■ User enter table name needed for new database. ■ User hits submit.

● User can repeat the previous two steps until the database is populated with tables.

■ System enters table into table list. ■ User selects table to add new field to. ■ User enters field name. ■ User enters field type (string, number, currency, etc.) ■ User hits enter

● User can repeat the previous two steps until the table is populated with fields. ■ System enters field into field list. ■ User submits form. ■ System loads new information into server memory.

○ Adding a database directly to SQL server/Azure SQL Server If the user wants to add a database to SQL Server or Azure’s SQL Server directly, this can also be done. The user must have login information for the database they want to access and must have enough knowledge of SQL to properly add the database. Tables and fields can also be added at this time.

■ User opens SQL Server/Azure SQL Server. ■ System loads SQL Server Program. ■ System asks for server name, username, and password. ■ User enters server name. ■ User enters username.

Stable Geniuses

@HOOF KY, 2018

Page 37

■ User enters password. ■ User hits enter. ■ System loads server databases. ■ User selects new query from SQL Server taskbar. ■ System opens a new page with a large text box where information can be typed. ■ User specifies parameters for the new database. ■ User selects run query. ■ System creates database. ■ User saves database information by clicking save.

○ If Using SQL Server ■ System saves information to application server.

○ If using Azure SQL Server ■ Azure saves the information to Azure’s read only SQL database. ■ Azure’s Data Sync sends the information to the application server. ■ System saves the information to the application server.

● Special Requirements ○ Application server must be able to use SQL Server

■ This use case requires that the application server have an operating system that can run SQL Server. As of SQL Server 2017 SQL Server can run on Windows, Linux natively, or can run Mac by using the application Docker, which requires a subscription fee.

○ Application server must be able to connect to the Internet for Azure method ■ In order for the user to add information to the main application server, the server must

have a connection to the Internet. If the server can’t then the information contained in Azure’s database will contain different information than the database on the application server. Running the system this way would defeat the purpose of using Azure, so an Internet connection is vital to updating the main server.

○ User systems must be able to run or connect to Azure’s SQL Server ■ In order to add a database properly, the user needs to have a device than can run or

connect to Azure’s SQL Server. If SQL Server can’t be connected to, then the user will not be able to add the database until they find a suitable device or enter the information to the application server directly.

● Pre-conditions ○ Application server must be on

■ When using the server on site, the system must be on. When using Azure it’s important for the application server to be on so that the system is updated properly, but it doesn’t need to be in this instance.

○ SQL Server must be installed on the application server ■ In order to use SQL Server, it has to be installed and set up so database features can be

used. ○ Azure must be connected to the application server

■ In order to add database information offsite properly, Azure’s database needs to be connected to the application server so that any database added will be accessible to other users that need the information.

○ System must be connected to application or Azure server ■ In order for the forms to properly do their job, they must be correctly connected to the

server that they are attempting to connect to. Failure to do so will result in no data transfer, incomplete data transfer, or incorrect data transfer.

● Post-conditions ○ Database is entered into the system

■ The command to add the database to the application server is successful, and system saves everything properly.

○ Database fails to be entered into the system

Stable Geniuses

@HOOF KY, 2018

Page 38

■ Either because of a misworded entry or a system error, the database fails to be saved to the server. This can be a failure on the application server itself, an error between the communication Azure’s database, or an error with the user’s device that causes an issue with the save.

○ Database is entered into the system improperly ■ If the wrong database information is added or there is an issue with the system that

allows a save, data can be entered incorrectly which then needs to be removed and updated. This can potentially stem from errors in the system design or viruses, so it is important to determine why the information was entered improperly.

○ System crash ■ If the system can’t handle the amount of information added or a system error occurs,

the system can crash. This can cause issues with any information being transferred, and unsaved data will be lost, so it’s important to check what needs to be done to restore the system to a working order.

Sequence Diagram

Stable Geniuses

@HOOF KY, 2018

Page 39

Name: Modify Database ● Brief Description

○ Allows for the modification of previously existing databases, which allows a user to add, change, or delete information to a database on HOOF’s application server. When a database is modified, information important to HOOF’s operations can be updated to reflect changes in the business. When explaining this use case, the term “user” will be used frequently to denote the person attempting to modify the database.

● Actors: Board of Directors, Volunteers ● Basic Flow

○ User selects a database to edit. ○ User hits submit. ○ System loads the current database information into a form that allows tables and fields to be

modified. ○ User enter table name needed for new database. ○ User hits enter button.

■ User can repeat the previous two steps until the database is populated with new tables needed.

○ System enters table into table list. ○ User selects tables to delete. ○ User hits the delete button next to the list. ○ System deletes the tables specified. ○ User selects table to add new field to or delete field from. ○ User enters field name. ○ User enters field type (string, number, currency, etc.) ○ User hits enter button.

■ User can repeat the previous two steps until the table is populated with fields. ○ System enters field into new field list. ○ User selects fields either from the current fields or the new fields. ○ User hits the delete key by their respective list. ○ System deletes the fields specified. ○ System enters field into field list. ○ User submits form. ○ System deletes old information from server memory. ○ System saves new information to server memory.

● Alternative Flows ○ Modifying a database directly on SQL server/Azure SQL Server

If the user wants to edit a database to SQL Server or Azure’s SQL Server directly, this can also be done. The user must have login information for the database they want to access and must have enough knowledge of SQL to properly add the database.

■ User opens SQL Server/Azure SQL Server. ■ System loads SQL Server Program. ■ System asks for server name, username, and password. ■ User enters server name. ■ User enters username. ■ User enters password. ■ User hits enter. ■ System loads server databases. ■ User selects new query from SQL Server taskbar. ■ System opens a new page with a large text box where information can be typed. ■ User updates the database’s tables and/or fields. ■ User selects run query. ■ System updates database with new information.

Stable Geniuses

@HOOF KY, 2018

Page 40

■ User saves database information by clicking save. If using SQL Server

■ System saves information to application server. If using Azure SQL Server

■ Azure saves the information to Azure’s read only SQL database. ■ Azure’s Data Sync sends the information to the application server. ■ System saves the information to the application server.





○ User systems must be able to run or connect to Azure’s SQL Server ■ In order to add a database properly, the user needs to have a device than can run or

connect to Azure’s SQL Server. If SQL Server can’t be connected to, then the user will not be able to add the database until they find a suitable device or enter the information to the application server directly.

● Pre-conditions ○ Application server must be on

■ When using the server on site, the system must be on. When using Azure it’s important for the application server to be on so that the system is updated properly, but it doesn’t need to be in this instance.



■ In order to modify database information offsite properly, Azure’s database needs to be connected to the application server so that any database modified will be accessible to other users that need the information.



● Post-conditions ○ Database is entered into the system

■ The command to modify the database to the application server is successful, and system saves everything properly.

○ Database fails to be entered into the system ■ Either because of a misworded entry or a system error, the database fails to be saved to

the server. This can be a failure on the application server itself, an error between the communication Azure’s database, or an error with the user’s device that causes an issue with the save.

○ Database is entered into the system improperly ■ If the wrong database information is added or there is an issue with the system that

allows a save, data can be entered incorrectly which then needs to be removed and

Stable Geniuses

@HOOF KY, 2018

Page 41

updated. This can potentially stem from errors in the system design or viruses, so it is important to determine why the information was entered improperly.

○ System crash ■ If the system can’t handle the amount of information changed or a system error occurs,


Sequence Diagram

Stable Geniuses

@HOOF KY, 2018

Page 42

Name: Delete Database ● Brief Description

○ Allows for the deletion of existing databases contained on the server, which store the information needed to run HOOF. If information related to HOOF’s operations is no longer necessary or updated databases are developed, then there needs to be a way of deleting the old information as to not have unnecessary clutter in the system’s memory.. When explaining this use case, the term “user” will be used frequently to denote the person attempting to add the database.

● Actors: Board of Directors ● Basic Flow

○ User selects the database to be deleted from the drop down menu. ○ User selects delete. ○ System erases the database. ○ System notifies the user that the database has been deleted.

● Alternative Flows ○ Deleting an item directly from SQL server/Azure SQL Server

If the user wants to delete an item from SQL Server or Azure’s SQL Server directly, this can also be done. The user must have login information for the database they want to access and must have enough knowledge of SQL to properly delete the information.

■ User opens SQL Server/Azure SQL Server. ■ System loads SQL Server Program. ■ System asks for server name, username, and password. ■ User enters server name. ■ User enters username. ■ User enters password. ■ User hits enter. ■ System loads server databases. ■ User selects new query from SQL Server taskbar. ■ System opens a new page with a large text box where information can be typed. ■ User specifies database to be deleted. ■ User selects run query. ■ System deletes database. ■ User saves database information by clicking save.

If using SQL Server


■ Azure saves the information to Azure’s read only SQL database. ■ System saves the information to the application server.





Stable Geniuses

@HOOF KY, 2018

Page 43

○ User systems must be able to run or connect to Azure’s SQL Server ■ In order to add a database properly, the user needs to have a device that can run or

connect to Azure’s SQL Server. If SQL can’t be connected to, then the user will not be able to access databases until they find a suitable device or access the information from the application server directly.

● Pre-conditions

○ Application server must be on ■ When using the server on site, the system must be on. When using Azure it’s important

for the application server to be on so that the system is updated properly, but it doesn’t need to be in this instance.



■ In order to add database information offsite properly, Azure’s database needs to be connected to the application server so that any database added will be accessible to other users that need the information.



● Post-conditions

○ Database is deleted from the system ■ The command to delete the database from the application server is successful, and

system saves everything properly. ○ Database fails to be deleted from the system

■ Either because of a misworded entry or a system error, the database fails to be deleted to the server. This can be a failure on the application server itself, an error between the communication Azure’s database, or an error with the user’s device that causes an issue with the save.

○ Database is deleted from the system improperly ■ If the wrong database information is deleted or there is an issue with the system that

allows a save, data can be deleted incorrectly which then needs to be adjusted so that the correct information is removed. This can potentially stem from errors in the system design or viruses, so it is important to determine why the information was deleted improperly.


the system can crash. This can cause issues with any information being transferred, and unsaved changes will be lost, so it’s important to check what needs to be done to restore the system to a working order.

Stable Geniuses

@HOOF KY, 2018

Page 44

Sequence Diagram

Stable Geniuses

@HOOF KY, 2018

Page 45

Name: Add Financial Data ● Brief Description

○ HOOF will need to be able to store any information regarding donations, item sales, payments, or other transaction information in order to stay up to date on business needs and to adhere to government regulations. In order for this to work, this information will need to be able to be added in to the system so that transactions are kept up with and totals including total assets and total liabilities can be viewed.


○ User enters amount added or taken out ○ User enters transaction type (entering asset or liability) ○ User enters date that the transaction occurred. ○ User enters who gave or received funds. ○ User enters reason for addition/decrease in funds. ○ User hits submit. ○ System locates space to save the new information. ○ System writes the new information to memory. ○ System lets the user know that information has been added.


○ Adding financial data directly to SQL server/Azure SQL Server If the user wants to add financial data to SQL Server or Azure’s SQL Server directly, this can also be done. The user must have login information for the database they want to access and must have enough knowledge of SQL to properly add the information.

■ User opens SQL Server/Azure SQL Server. ■ System loads SQL Server Program. ■ System asks for server name, username, and password. ■ User enters server name. ■ User enters username. ■ User enters password. ■ User hits enter. ■ System loads server databases. ■ User selects new query from SQL Server taskbar. ■ System opens a new page with a large text box where information can be typed. ■ User specifies data to be deleted from the database. ■ User selects run query. ■ System modifies database. ■ User saves database information by clicking save.

If using SQL Server

○ System saves information to application server. If using Azure SQL Server

○ Azure saves the information to Azure’s read only SQL database. ○ Azure’s Data Sync sends the information to the application server. ○ System saves the information to the application server.

● Special Requirements

○ Application server must be able to use SQL Server ■ This use case requires that the application server have an operating system that can run

SQL Server. As of SQL Server 2017 SQL Server can run on Windows, Linux natively, or can run Mac by using the application Docker, which requires a subscription fee.

○ Application server must be able to connect to the Internet for Azure method

Stable Geniuses

@HOOF KY, 2018

Page 46

■ In order for the user to add information to the main application server, the server must have a connection to the Internet. If the server can’t then the information contained in Azure’s database will contain different information than the database on the application server. Running the system this way would defeat the purpose of using Azure, so an Internet connection is vital to updating the main server.



○ Financial data must be held to government regulations ■ Any financial data must be readily accessible in case it is required by state or federal

inspection. Keeping data to government standards is necessary, and any data withheld or tampered with to hide transaction data may be punishable by law.

● Pre-conditions




used. ○ Database with correct tables and fields must be previously added to the system

■ In order for the information to be saved properly, the information has to have the proper place to go, otherwise information will be lost or the system won’t allow the form to function as it should. Having a financial database that accepts all of the fields that need to be sent to it is a necessary step in the process.

○ Azure must be connected to the application server ■ In order to add database information offsite properly, Azure’s database needs to be

connected to the application server so that any database added will be accessible to other users that need the information.

○ System must be connected to application or Azure Server ■ In order for the forms to properly do their job, they must be correctly connected to the


● Post-conditions

○ Financial data is entered into the system ■ The command to add the data to the application server is successful, and system saves

everything properly. ○ Financial data fails to be entered into the system

■ Either because of a misworded entry, an incorrectly formatted database without the proper tables and/or fields, or a system error, the data fails to be saved to the server. This can be a failure on the application server itself, an error between the communication Azure’s database, or an error with the user’s device that causes an issue with the save.

○ Financial data is entered into the system improperly ■ If incomplete or otherwise faulty information is accepted and system allows it to be

saved, data may need to be removed and updated. This can potentially stem from errors in the system design or viruses, so it is important to determine why the information was entered improperly.

Stable Geniuses

@HOOF KY, 2018

Page 47

○ System crash ■ If the system can’t handle the amount of information added or a system error occurs,


Sequence Diagram

Stable Geniuses

@HOOF KY, 2018

Page 48

Stable Geniuses

@HOOF KY, 2018

Page 49

Name: Modify Financial Data ● Brief Description

○ HOOF will need to be able to update any information regarding donations, item sales, payments, or other transaction information in their database in order to stay up to date on business needs and to adhere to government regulations. By making transaction information editable, incorrectly added data can be corrected and any updates to fields such as donor addresses can be updated as they need to be. Caution needs to be taken when editing transaction information, as changing transaction information can be misconstrued as attempts to hide evidence of wrongdoing, and as such must be handled with care.


○ User searches for financial data by entering parameters for amount, date, transaction amount, transaction type, transaction participant, or transaction description.

○ User selects the information that needs to be updated. ○ System loads current information. ○ User enters change in amount added or taken out. ○ User enters change in transaction type (entering asset or liability) ○ User enters change in date that the transaction occurred. ○ User enters change in who gave or received funds. ○ User enters change in reason for addition/decrease in funds. ○ User hits submit. ○ System locates the information that has been saved. ○ System deletes old information. ○ System writes the new information to memory. ○ System lets the user know that the information has been updated.


○ Modifying financial data directly on SQL server/Azure SQL Server If the user wants to edit financial data currently on SQL Server or Azure’s SQL Server directly, this can also be done. The user must have login information for the database they want to access and must have enough knowledge of SQL to properly add the information.

■ User opens SQL Server/Azure SQL Server. ■ System loads SQL Server Program. ■ System asks for server name, username, and password. ■ User enters server name. ■ User enters username. ■ User enters password. ■ User hits enter. ■ System loads server databases. ■ User selects new query from SQL Server taskbar. ■ System opens a new page with a large text box where information can be typed. ■ User specifies data to be updated in the database. ■ User selects run query. ■ System modifies database. ■ User saves database information by clicking save.

If using SQL Server



Stable Geniuses

@HOOF KY, 2018

Page 50

● Special Requirements

○ Application server must be able to use SQL Server ■ This use case requires that the application server have an operating system that can run

SQL Server. As of SQL Server 2017 SQL Server can run on Windows, Linux natively, or can run Mac by using the application Docker, which requires a subscription fee.







● Pre-conditions




used. ○ Database with correct tables and fields must be previously added to the system

■ In order for the information to be saved properly, the information has to have the proper place to go, otherwise information will be lost or the system won’t allow the form to function as it should. Having a financial database that accepts all of the fields that need to be sent to it is a necessary step in the process.





● Post-conditions

○ Financial data is entered into the system ■ The command to edit the data on the application server is successful, and system saves

everything properly. ○ Financial data fails to be entered into the system

■ Either because of a misworded entry, an incorrectly formatted database without the proper tables and/or fields, or a system error, the data fails to be saved to the server. This can be a failure on the application server itself, an error between the

Stable Geniuses

@HOOF KY, 2018

Page 51

communication Azure’s database, or an error with the user’s device that causes an issue with the save.





Sequence Diagram

Stable Geniuses

@HOOF KY, 2018

Page 52

Stable Geniuses

@HOOF KY, 2018

Page 53

Name: Delete Financial Data ● Brief Description

○ HOOF will need to be able to delete information regarding donations, item sales, payments, or other transaction information in the case that the data is incorrect, such as a case where a transaction never took place. Caution must be used when deleting financial data, as deleting transaction information can be misconstrued as attempts to hide evidence of wrongdoing, and as such must be handled with care.


○ User searches for financial data by entering parameters for amount, date, transaction amount, transaction type, transaction participant, or transaction description.

○ User selects information to be deleted. ○ User hits delete. ○ System locates information in the system’s memory. ○ System overwrites information. ○ System lets the user know that the information has been deleted.

● Alternative Flows ○ Deleting financial data directly from SQL server/Azure SQL Server

If the user wants to delete financial data currently on SQL Server or Azure’s SQL Server directly, this can also be done. The user must have login information for the database they want to access and must have enough knowledge of SQL to properly delete the information.

■ User opens SQL Server/Azure SQL Server. ■ System loads SQL Server Program. ■ System asks for server name, username, and password. ■ User enters server name. ■ User enters username. ■ User enters password. ■ User hits enter. ■ System loads server databases. ■ User selects new query from SQL Server taskbar. ■ System opens a new page with a large text box where information can be typed. ■ User specifies data to be deleted from the database. ■ User selects run query. ■ System modifies database. ■ User saves database information by clicking save.

If using SQL Server





○ Application server must be able to Connect to the Internet for Azure method

Stable Geniuses

@HOOF KY, 2018

Page 54

■ In order for the user to add information to the main application server, the server must have a connection to the Internet. If the server can’t then the information contained in Azure’s database will contain different information than the database on the application server. Running the system this way would defeat the purpose of using Azure, so an Internet connection is vital to updating the main server.





● Pre-conditions




used. ○ Financial data must be present so it can be deleted

■ When trying to delete data there must be data previously entered into the database. Failure to do so will end with a request to find data that isn’t there, meaning no data can be deleted.



○ System must be connected to application or Azure Server ■ In order for the forms to properly do their job, they must be correctly connected to the


● Post-conditions

○ Financial data is deleted from the system ■ The command to delete the data from the application server is successful, and system

saves everything properly. ○ Financial data fails to be entered into the system

■ Either because of a misworded entry, an incorrectly formatted database without the proper tables and/or fields, or a system error, the data fails to be saved to the server. This can be a failure on the application server itself, an error between the communication Azure’s database, or an error with the user’s device that causes an issue with the save.



○ System crash

Stable Geniuses

@HOOF KY, 2018

Page 55

■ If the system can’t handle the amount of information changed or a system error occurs, the system can crash. This can cause issues with any information being transferred, and unsaved data will be lost, so it’s important to check what needs to be done to restore the system to a working order.

Sequence Diagram

Stable Geniuses

@HOOF KY, 2018

Page 56

Name: Add Reports

● Brief Description: allows users to access the database system, through the website, and add any financial

reports to the database.

● Actors: HOOF Board Members

● Basic Flow:

○ The HOOF Board Member logs into the system through the HOOF website.

○ Select the file of the financial report to be uploaded.

○ Click submit to initiate file upload.

○ The system requires a confirmation from the user.

○ Confirm file upload.

○ The system stores the financial report file into the database.

● Alternative Flows: ·

○ Incorrect Username

○ Incorrect Password

○ While the user uploads the file, the system sends an error message due to a failure to upload the

file.

● Pre-Conditions:

○ The user must have a valid username and password

■ See the Add Log-In use case

● Post-Conditions:

○ System displays a message letting the user know the file has been uploaded to the database.

Stable Geniuses

@HOOF KY, 2018

Page 57

Name: Modify Reports

● Brief Description: Allows users to access the database and update/modify any of the data that is currently

on the financial reports.

● Actors: HOOF Board Members

● Basic Flow:


○ Select the file of the financial report to be updated.

○ The user downloads the file from the system to their computer.

○ Update the file as needed.

○ Initiate modified file upload.


○ Confirm financial report modification upload.

○ The system stores the updated financial report.

● Alternative Flows:

· User is unable to download the file containing the report from the system

· While the user uploads the file, the system sends an error message due to a failure to upload the file.

● Pre-conditions:

○ The user must have a valid username and password

■ See the Add Log-In use case


○ The financial report in the system is updated

Stable Geniuses

@HOOF KY, 2018

Page 58

Name: Delete Report

● Brief Description: Allows users to access the system and delete any financial report from the database.

● Actor: HOOF Board Members

● Basic Flow:


○ Select the file containing the financial report.

○ Initiate file deletion.


○ Confirm financial report deletion

○ The system deletes the file.


○ No File Selected

■ The user did not select a file from the system to delete.

■ The user hits the submit button to delete

■ Error message

○ Incorrect File Deleted

■ User deletes the wrong file from the system

■ Error Message

● Special Requirements:

○ File upload must be in the form of pdf, doc, or excel.

● Pre-conditions:

○ Access to the HOOF website

○ User has authorized Administrator Log-In

Stable Geniuses

@HOOF KY, 2018

Page 59


○ The file is deleted and is no longer stored in the system

Name: Add Social Media

● Brief Description: allows a user to add a social media profile/information, such as the HOOF Facebook

account, to the system.

● Actor: HOOF Board Members and Volunteers

● Basic Flow:

○ Enter Social Media Username

○ Enter Social Media Password

○ Submit


○ Confirm submission.

● Special Requirements:

○ User has access to the HOOF website

● Pre-conditions:

○ User has access to the HOOF website.

○ User has an authorized Log-In


○ Social Media Account information is added into the system

Stable Geniuses

@HOOF KY, 2018

Page 60

Name: Modify Social Media

● Brief Description: Allows HOOF users to access the system and modify the social media information that is

currently stored in the database


● Basic Flow:

○ Enter the new Social Media Username

○ Enter the new Social Media Password

○ Submit


○ Confirm updated social media log-in.

○ The system stores the modified information.


○ Lost Log-In

■ Lost Username

■ Lost Password

Stable Geniuses

@HOOF KY, 2018

Page 61

● Pre-conditions:


○ User has authorized Log-In

○ User has valid social media log-in


○ Social Media Information is added to the database.

Name: Delete Social Media

● Brief Description: Use Case allows the user to delete the social media information currently stored in the

system.


● Basic Flow:

○ Select social media account information.

○ Initiate account information deletion.


○ Confirm social media information deletion.

○ The system deletes the social media information.


Stable Geniuses

@HOOF KY, 2018

Page 62

○ User Cancel

■ Users cancels the delete action

● Pre-conditions:




○ Mission Statement is added into the system

Name: Add Mission Statement

● Brief Description: Allows users to add or upload a mission statement into the system.


● Basic Flow:

○ Enter Mission Statement.

Stable Geniuses

@HOOF KY, 2018

Page 63

○ Submit.


○ Confirm mission statement submission.

○ The system adds the mission statement to the database.


○ Invalid Input

■ User enters invalid input

■ User attempts to submit input

■ Error message

● Pre-conditions:




○ Social Media Information is added

Stable Geniuses

@HOOF KY, 2018

Page 64

Name: Modify Mission Statement

● Brief Description: Allows HOOF Board Members to update the current mission statement that is currently

stored in the system.


● Basic Flow:

○ Select the mission statement from the system.

○ Enter modified mission statement.


○ Confirm updated mission statement submission.

○ The system adds the modified mission statement to the database.


○ No Mission Statement Selected

■ User does not select currently stored mission statement

■ User initiates mission statement deletion

○ Error Message

● Pre-conditions:



○ Previous mission statement already stored in the system


○ Modified mission statement is entered into the system replacing the previous mission statement.

Stable Geniuses

@HOOF KY, 2018

Page 65

Name: Delete Mission Statement

● Brief Description: Allows users to delete the current mission statement from the system


● Basic Flow:

○ Select the mission statement from the system.

○ Initiate mission statement deletion.


○ Confirm mission statement deletion

○ The system deletes the file.


○ No Mission Statement Selected

■ User does not select currently stored mission statement

■ User initiates mission statement deletion

■ Error Message

● Pre-conditions:

○ Valid user Log-In


Stable Geniuses

@HOOF KY, 2018

Page 66


○ The current mission statement is deleted from the system completely

Name: Add Fundraiser Event

● Brief Description: Allows users to add fundraiser information into the database. Then they enter data

about the fundraiser such as the date, name, location, and any additional information.

● Actor: HOOF Board Members/Volunteers

● Basic Flow:

○ Enter Fundraiser Name

○ Enter date

○ Enter Location

○ Enter Additional Information

○ Submit


○ Confirm fundraiser.

○ The system adds the fundraiser to the system


○ User Input Error

Stable Geniuses

@HOOF KY, 2018

Page 67

■ Enter wrong name

■ Enter wrong date

■ Enter wrong location

■ Enter wrong additional information

■ User must enter the correct information

● Pre-conditions:




○ HOOF fundraiser event information is added into the system

Name: Modify Fundraiser Event

● Brief Description: allows users to modify any fundraiser information currently in the database such as the

date, location, time, name, and additional information of the fundraiser


● Basic Flow:

○ Enter modified Fundraiser Name

○ Enter modified date

○ Enter modified Location

○ Enter modified Additional Information

Stable Geniuses

@HOOF KY, 2018

Page 68

○ Submit


○ Confirm fundraiser.

○ The system adds the fundraiser to the system.


○ User Input Error

■ Enter wrong name

■ Enter wrong date

■ Enter wrong location

■ Enter wrong additional information

■ User must enter the correct information

○ Invalid User Input

■ User enters invalid input

■ Error message

● Pre-conditions:




○ Fundraiser Information on the system is updated accordingly.

Stable Geniuses

@HOOF KY, 2018

Page 69

Name: Delete Fundraiser Event

● Brief Description: Allows users to delete fundraiser information in the database.


● Basic Flow:

○ Select Fundraiser Name

○ Select date

○ Select location

○ Select additional information

○ Initiate Fundraiser Deletion


○ Confirm fundraiser deletion

○ The system deletes the fundraiser


○ User Deletion Error

■ User deletes the wrong fundraiser information

■ The system requires a confirmation from the user.

■ User select no

■ Deletion is canceled

● Pre-conditions:



○ Fundraiser information already in the system

Stable Geniuses

@HOOF KY, 2018

Page 70


○ Fundraiser info is deleted from the system.

Stable Geniuses

@HOOF KY, 2018

Page 71

Name: Add Auction Item

● Brief Description ○ Auctions of donated items help to provide HOOF with necessary funding to run their operation,

so having a way to add items to their database will help provide easy access and tracking of item information. It is important to track both the item itself as well as the donor who provided the item to make sure that the item is accounted for and so that the donor can be reached in case any questions arise about an item or the item needs to be returned for any reason. Donors can also be sent updates on HOOF affairs if they aren’t currently added to the system in the case that they decide to donate an item or funds again in the future.

● Actors: Board Members, Volunteers, Parents, Donors ● Basic Flow

○ User enters name of auction item. ○ User enters brief description of the item. ○ User enters donor’s name. ○ User enters donor’s phone number. ○ User enters donor’s email address. ○ User hits submit. ○ System locates space to save the information. ○ System writes new information to memory. ○ System lets the user know that information has been added.

● Alternative Flows ○ Adding auction item directly to SQL server/Azure SQL Server

If the user wants to add one or more auction items to SQL Server or Azure’s SQL Server directly, this can also be done. The user must have login information for the database they want to access and must have enough knowledge of SQL to properly add the item information.

■ User opens SQL Server/Azure SQL Server. ■ System loads SQL Server Program. ■ System asks for server name, username, and password. ■ User enters server name. ■ User enters username. ■ User enters password. ■ User hits enter. ■ System loads server databases. ■ User selects new query from S

Elaboration Spec · 2018. 11. 30. · Stable Geniuses @HOOF KY, 2018 Page 11 Trace Matrix Trace...

Documents

Transcript of Elaboration Spec · 2018. 11. 30. · Stable Geniuses @HOOF KY, 2018 Page 11 Trace Matrix Trace...