brookblackburn.files.wordpress.com€¦ · web viewin this use case, the actions will start with...

CIS320 Spring 2016 Hoosier Analysts P a g e | 0

2016

Hoosier AnalystsBrook Blackburn, Sarah muss, candace kelley, ben langston, and zack ohlendorf

cis320-01 | Spring 2016

Table of ContentsSystem Requirements...............................................................................................................4

Use Case Diagrams...................................................................................................................7

Trace Matrix............................................................................................................................13

Use Cases................................................................................................................................24

Create Student – 1...............................................................................................................25

Modify Student – 2...............................................................................................................27

Archive Student – 3..............................................................................................................29

Create Grant – 4...................................................................................................................30

Modify Grant – 5...................................................................................................................32

Archive Grant – 6.................................................................................................................34

Create Donor – 7..................................................................................................................35

Modify Donor – 8..................................................................................................................38

Archive Donor – 9.................................................................................................................40

Create Event – 10.................................................................................................................42

Modify Event – 11.................................................................................................................44

Cancel Event – 12................................................................................................................46

Create Class – 13.................................................................................................................48

Modify Class – 14.................................................................................................................49

Delete Class – 15.................................................................................................................50

Add Volunteer – 16...............................................................................................................51

Modify Volunteer – 17..........................................................................................................52

Archive Volunteer – 18.........................................................................................................53CIS320 Spring 2016 Hoosier Analysts P a g e | 1

Add Parent – 19....................................................................................................................54

Modify Parent – 20...............................................................................................................57

Archive Parent – 21..............................................................................................................58

Add Staff Member – 22.........................................................................................................60

Modify Staff Member – 23....................................................................................................62

Archive Staff Member – 24...................................................................................................64

Add Media – 25....................................................................................................................66

Modify Media – 26................................................................................................................68

Delete Media – 27................................................................................................................70

Add Form – 28......................................................................................................................72

Modify form – 29..................................................................................................................73

Delete Form – 30..................................................................................................................74

Print Form – 31.....................................................................................................................75

Create Board Member Account – 32.....................................................................................77

Modify Board Member Account – 33.....................................................................................79

Archive Board Member Account – 34...................................................................................81

Create Book an Appointment - 35........................................................................................83

Modify Appointment – 36.....................................................................................................84

Delete Appointment – 37.....................................................................................................85

Login – 38............................................................................................................................86

Backup – 39.........................................................................................................................87

Recovery System – 40..........................................................................................................89

User Rights Administration – 41...........................................................................................90


Sequence Diagram..................................................................................................................92

Class Diagram.......................................................................................................................110

Database Designs and Data Definitions................................................................................112

Database Designs and Data Definitions................................................................................113

User Interface and Navigation Diagram & Screen Layout.....................................................120

Physical Architectural Design Specifications.........................................................................122

Design Procedures for Security Concerns & Non-Functional Requirements..........................125

Gantt Chart...........................................................................................................................127

Elaboration Phase Prototypes................................................................................................129


System Requirements


System requirements are features that should

be part of the new system that will be

constructed. Each requirement that is stated

is in a numbered list. Each item represents

features that will be included in the system.

System Requirements

1. The system shall have a student database.

2. The system shall allow staff members to edit student information.

3. The system shall allow inactive students to be archived in the system.

4. The system shall have a grant database.

5. The system shall allow staff members to edit grant information.

6. The system shall allow grants to be archived in the system.

7. The system shall have a donor database.

8. The system shall allow staff members to edit donor information.

9. The system shall allow donors to be archived in the system.

10. The system shall allow staff members to create events.

11. The system shall allow staff members to edit events.

12. The system shall allow staff members to delete events.

13. The system shall allow staff members to create classes.

14. The system shall allow staff members to edit classes.

15. The system shall allow staff members to delete classes.

16. The system shall have a volunteer database.

17. The system shall allow staff members to edit volunteer information.

18. The system shall allow staff members to archive inactive volunteers.

19. The system shall have a parent database.

20. The system shall allow staff members to edit parent information.

21. The system shall allow staff members to archive parents of inactive students.

22. The system shall have a staff database.

23. The system shall allow staff members to modify staff information.

24. The system shall allow staff members to archive staff who no longer work there.

25. The system shall have a media database.

26. This system shall allow users to edit media content.

27. This system shall allow users to delete media.

28. This system shall have a form database.

29. This system shall allow staff members to edit forms.

30. This system shall allow staff members to delete forms.


31. This system shall allow users to print forms.

32. This system shall have a board of directors’ database.

33. This system shall allow staff members to edit board of director’s information.

34. This system shall allow inactive board of director’s to be archived.

35. This system shall have a “Book an Appointment” feature for booking an appointment with staff.

36. This system shall allow users to edit appointment information until the day of the appointment.

37. This system shall allow users to cancel appointments with staff.

38. This system shall have a login for staff, students, and parents.

39. This system shall allow staff to backup the system.

40. This system shall be able to recover from a previous backup.

41. This system shall allow staff to administer user rights as needed.

42. This system shall have an application for student recruitment.

43. This system shall have an application for volunteer recruitment.

44. This system shall track student attendance.

45. This system shall allow the staff to track performance statistics and reporting.

46. This system shall allow staff to push event notifications to appropriate users.

47. This system shall allow staff to enroll students in program(s).


Use Case Diagrams


Use case diagrams are graphic depictions of

the interactions among the elements of a use

case. More specifically, it is a visual aid to

show what users interact with the specific

area of the system. This is a way to double

check the system design.

Use Case Diagram


Trace Matrix


Trace Matrix is a document that maps and traces user

requirement with test case. The main purpose is to see that

all test cases are covered by at least one user requirement.

UC - 1 UC - 2 UC - 3 UC - 4 UC - 5 UC - 6 UC - 7 UC - 8Create Student Modify Student Archive Student Create Grant Modify Grant Archive Grant Create Donor Modify Donor

R1 XR2 XR3 XR4 XR5 XR6 XR7 XR8 XR9

R10R11R12R13R14R15R16R17R18R19R20R21R22R23R24R25R26R27R28R29R30R31R32R33

Trace Matrix


UC - 1 UC - 2 UC - 3 UC - 4 UC - 5 UC - 6 UC - 7 UC - 8Create Student Modify Student Archive Student Create Grant Modify Grant Archive Grant Create Donor Modify Donor

R34R35R36R37R38R39R40R41R42R43R44 XR45R46R47 X X



UC - 9 UC - 10 UC - 11 UC - 12 UC - 13 UC - 14 UC - 15 UC - 16 UC - 17Archive Donor Create Event Modify Event Cancel Event Create Class Modify Class Delete Class Add Volunteer Modify Volunteer

R1R2R3R4R5R6R7R8R9 X

R10 XR11 XR12 XR13 XR14 XR15 XR16 XR17 XR18R19R20R21R22R23R24R25R26R27R28R29R30R31R32R33

UC - 18 UC - 19 UC - 20 UC - 21 UC - 22 UC - 23 UC - 24 UC - 25 UC - 26Archive Volunteer Add Parent Modify Parent Archive Parent Add Staff Modify Staff Archive Staff Add Media Modify Media

R34R35R36R37R38R39R40R41R42R43R44R45R46R47

UC - 27 UC - 28 UC - 29 UC - 30 UC - 32 UC - 32 UC - 33Delete Media Add Forms Modify Forms Delete Forms Print Forms Add Board of Director Modify Board of Director

R1R2R3R4R5R6R7R8R9

R10R11R12R13R14R15R16R17R18R19R20R21R22R23R24R25R26R27 XR28 XR29 XR30 XR31 XR32 XR33 X



R1R2R3R4R5R6R7R8R9

R10R11R12R13R14R15R16R17R18R19R20R21R22R23R24R25R26R27 XR28 XR29 XR30 XR31 XR32 XR33 X


R34R35R36R37R38R39R40R41R42 X X XR43 X X XR44R45R46R47



R34R35R36R37R38R39R40R41R42 X X XR43 X X XR44R45R46R47


UC - 34 UC - 35 UC - 36 UC - 37 UC - 38 UC - 39 UC - 40 UC - 41

Archive Board of DirectorBook an

Appointment Modify AppointmentDelete

Appointment Login Backup RecoveryAdministratve

Use RightsR1 XR2 XR3 XR4 XR5 XR6 XR7 XR8 XR9 X

R10 XR11 XR12 XR13 XR14 XR15 XR16 XR17 XR18 XR19 XR20 XR21 XR22 XR23 XR24 XR25 XR26 XR27 XR28 XR29 XR30 XR31 XR32 X


UC - 34 UC - 35 UC - 36 UC - 37 UC - 38 UC - 39 UC - 40 UC - 41R33 X

Archive Board of DirectorBook an

Appointment Modify AppointmentDelete

Appointment Login Backup RecoveryAdministratve

Use RightsR34 X XR35 X XR36 X XR37 X XR38 XR39 X X XR40 X X XR41 X XR42R43R44R45R46R47


Use Cases


Use Cases are a complete breakdown of

the description of a feature of the system.

This allows the feature to be broken down

into descriptive steps to make sure that it

functions exactly how it is expected to.

Use Cases have an identifying number on

it, and identifying name, who will be using

the feature, the main flow of the feature,

how important the feature is to

organization, and the frequency of the

feature.

Use Cases – 1

Brief Description

The purpose of this use case is to create a student account. The role of this use case is to be able to add a student into the database that will be created. With this use case, the staff will be able to enroll students into their program.

Flow of Events

Basic Flow

In this use case, the actions will start with the staff members of Adelante Hispanic Achievers as actors. The staff will start with entering all basic information that is related to the student. This information will include the student’s first name, middle initial, last name, address (street address, city, state, zip code), home phone number, cell phone number, active/inactive status, ambassador status, and date of birth. The system will store all of this information so that it can be recalled, if needed, at a later date. The staff will then calculate a field that will be named student ID. This will be a block style number. It will consist of the first initial of the student’s first name, the first initial of the student’s middle name, the first four letters of the last name, and the last four numbers of the associated phone number. The system will store this information so that it can be recalled, if needed, at a later date. The staff will also input the expected graduation date of the student. The system will store this information so that it can be recalled, if needed, at a later date. The staff will also input the schedule of the student. This will include all programs hosted by Adelante that the student will attend. The system will store this information so that it can be recalled, if needed, at a later date. After inputting all of this information, the staff will be able to retrieve any needed data to fulfill any future needs of the organization.

Alternative Flows

Data Entered Incorrectly

The alternative flow for this use case would include when the staff inputted in an incorrect character. For example, when the staff inputted a date of birth for a student they should not enter any alphabetical characters. Each attribute will have a certain input specification so that errors can be limited.

Missing Data


This alternative flow refers to when data is entered but is missing key parts to the record of the student. When this occurs the system will show an error message that tells the user that one of the fields in incomplete.

Duplicate Data

The alternative flow for this use case would include when the staff of Adelante input data that is an exact match to another student that has already been inputted into the system.

Pre-conditions

Enrollment

The Pre-condition for this use case would be that the student would be enrolled into the program of Adelante Hispanic Achievers.

Post-conditions

Inputted Student

The Post-condition for this use case would be that the student would be inputted into the system of the program.


Modify Student – 2

Brief Description

The purpose of this use case is to modify a student account. The role of this use case is to be able to modify information about a student into the database that will be created. With this use case, the staff will be able to edit information about students that are/were participating in their program.

Flow of Events

Basic Flow

In this use case, the actions will start with the staff members of Adelante Hispanic Achievers as actors. The staff will start with entering all basic information that is related to the student. The staff of Adelante may use this feature to update information such as: the student’s first name, middle initial, last name, address (street address, city, state, zip code), home phone number, cell phone number, active/inactive status, ambassador status, and date of birth. This feature can also be used to update the status of the student (active or inactive). The system will store all of this information so that it can be recalled, if needed, at a later date. This will include all programs hosted by Adelante that the student will attend. After inputting all of this information, the staff will be able to retrieve any needed data to fulfill any future needs of the organization.

Alternative Flows


The alternative flow for this use case would include when the staff inputted in an incorrect character. For example, when the staff inputted a date of birth for a student they should not enter any alphabetical characters. Each attribute will have a certain input specification so that errors can be limited.

Missing Data


Duplicate Data

The alternative flow for this use case would include when the staff of Adelante input data that is an exact match to another student that has already been inputted into the system.

Pre-conditions

Enrollment

The Pre-condition for this use case would be that the student would be enrolled into the program of Adelante Hispanic Achievers.


Post-conditions

Inputted Student

The Post-condition for this use case would be that the student would be updated in the system of the program.


Archive Student – 3

Brief Description

The purpose of this use case is to archive a student account. The role of this use case is to be able to save a student’s information into the database that will be created. With this use case, the staff will be able to keep all prior (inactive/active) student’s information.

Flow of Events

Basic Flow

In this use case, the actions will start with the staff members of Adelante Hispanic Achievers as actors. The staff will have already entered all basic information that is related to the student. This information will have included the student’s first name, middle initial, last name, address (street address, city, state, zip code), home phone number, cell phone number, active/inactive status, ambassador status, and date of birth. The system will store all of this information so that it can be recalled, if needed, at a later date. The staff will have already calculated the field student ID. The staff will have already inputted the expected graduation date of the student. The staff will have already inputted the schedule of the student. This will include all programs hosted by Adelante that the student will/has attended. This use case focuses on the storage of all this information, even when the student has become inactive. This use case will help the staff of Adelante retrieve any kind of information that they may need at a later date.

Pre-conditions

Enrollment

The Pre-condition for this use case would be that the student information would be inputted into the system that exists.

Post-conditions

Inputted Student

The Post-condition for this use case would be that the student’s information would be inputted into the system so that no data is ever lost.


Create Grant – 4

Brief Description

The purpose of this use case is to create a grant account. The role of this use case is to be able to add a grant into the database that will be created. With this use case, the staff will be able to access information about grants, such as when they have applied last, deadlines for applying currently, and the status of any grant that has/will be applied for.

Flow of Events

Basic Flow

In this use case, the actions will start with the staff members of Adelante Hispanic Achievers as actors. The staff will start with entering all basic information that is related to grants. This information will include the grant’s company name, amounts that is being applied for, deadlines of the grant, and the relationship status that Adelante has with the company. The system will store all of this information so that it can be recalled, if needed, at a later date. This can be useful when Adelante is trying to apply for more grants or trying to reapply for a grant that they have applied for in the past. After inputting all of this information, the staff will be able to retrieve any needed data to fulfill any future needs of the organization.

Alternative Flows


The alternative flow for this use case would include when the staff inputted in an incorrect character. For example, when the staff inputted a deadline for a grant they should not enter any alphabetical characters. Each attribute will have a certain input specification so that errors can be limited.

Missing Data


Duplicate Data

The alternative flow for this use case would include when the staff of Adelante input data that is an exact match to another grant that has already been inputted into the system.

Pre-conditions

Apply for Grant

A Pre-condition of this use case is that Adelante Hispanic Achiever’s has to apply for a grant that is offered.


Post-conditions

Inputted Grant Data

The Post-condition for this use case would be that the grant would be inputted into the system of the program.


Modify Grant – 5 Brief Description

The purpose of this use case is to modify a grant account. The role of this use case is to be able to modify a grant into the database that will be created. With this use case, the staff will be able to access information about grants, such as when they have applied last, deadlines for applying currently, and the status of any grant that has/will be applied for. With this feature, the staff will be able to update any information about the grants.

Flow of Events

Basic Flow

In this use case, the actions will start with the staff members of Adelante Hispanic Achievers as actors. The staff will update a grant that is already located in the system. They will be able to update information such as: the grant’s company name, amounts that is being applied for, deadlines of the grant, and the relationship status that Adelante has with the company. The system will store all of this information so that it can be recalled, if needed, at a later date. This can be useful when Adelante is trying to apply for more grants or trying to reapply for a grant that they have applied for in the past. This system will be especially useful when the staff of Adelante is trying to keep up with whom they need to contact. After inputting all of this information, the staff will be able to retrieve any needed data to fulfill any future needs of the organization.

Alternative Flows


The alternative flow for this use case would include when the staff inputted in an incorrect character. For example, when the staff inputted a deadline for a grant they should not enter any alphabetical characters. Each attribute will have a certain input specification so that errors can be limited.

Missing Data


Duplicate Data

The alternative flow for this use case would include when the staff of Adelante input data that is an exact match to another grant that has already been inputted into the system.

Pre-conditions

Apply for Grant

A Pre-condition of this use case is that Adelante Hispanic Achiever’s has to apply for a grant that is offered.


Post-conditions

Inputted Grant Data

The Post-condition for this use case would be that the grant would be updated in the system of the program.


Archive Grant – 6

Brief Description

The purpose of this use case is to archive a grant account. The role of this use case is to be able to save information about grants into the database that will be created. With this use case, the staff will be able to access information about grants, such as when they have applied last, deadlines for applying currently, and the status of any grant that has/will be applied for.

Flow of Events

Basic Flow

In this use case, the actions will start with the staff members of Adelante Hispanic Achievers as actors. The staff will have already entered all basic information that is related to grants. This information will include the grant’s company name, amounts that is being applied for, deadlines of the grant, and the relationship status that Adelante has with the company. The system will store all of this information so that it can be recalled, if needed, at a later date. This can be useful when Adelante is trying to apply for more grants or trying to reapply for a grant that they have applied for in the past. After inputting all of this information, the staff will be able to retrieve any needed data to fulfill any future needs of the organization.

Pre-conditions

Apply for Grant

A Pre-condition of this use case is that Adelante Hispanic Achiever’s has to input the data about the grant into the system.

Post-conditions

Inputted Grant Data

The Post-condition for this use case would be that the information about the grants would be saved into the system of the program.


Create Donor – 7

Brief Description

This use case details the function of creating donor accounts. Staff will be able to create website accounts for new donors in order to help track and maintain relationships with them. Donor accounts will contain identifying and contact information for donors and will help Adelante keep track of how much and how often a person donates.

Flow of Events

Basic Flow

The actor in this use case is an Adelante staff member. Adelante staff can enter donor information easily into the following forms:

First Name [Textbox]

Last name [Textbox]

Initial [Textbox]

Company [Textbox]

Date of Birth [Three dropdown selections for day, month, and year]

Phone Number [Textbox]

Email [Textbox]

Address [Textbox]

Zip [Textbox]

City [Textbox]

State [Dropdown]

Country [Dropdown]

Previous student of Adelante? [Yes/No]

Once the information is entered, the website will check for errors, missing entries, duplicate entries, inconsistencies, and other anomalies. If everything is correctly filled out, then the webpage will send a confirmation message and create a donor account.

Alternative Flows

Data entered incorrectly

If data is entered incorrectly, for instance, numbers in a name box, the website will display an error message informing the user that an error has been made, and an account could not be created.

Missing Data

If data is missing from certain fields, the website will prompt the user to fill out any remaining forms and will not have created a donor account. Some fields will be optional and will accept null values. Optional forms include:


Email

Phone Number

Initial

Additionally, the website will remind the user that there is information missing from optional forms, but present them with an option to fill those out before creating the account.

Duplicate Account

If a donor account has already been created with the same information, the webpage will display a message informing the user that “This account already exists”. It will provide the option to “Go To Donor Account” or “Cancel”.

Company Account

Since not every donation will be from an individual, company accounts are also available. A company account form is completely separate from an individual’s account and an option is available on the initial screen to change account type to company. Company accounts only require:

Organization Name

Phone Number

Email

Address

Zip

City

State

Country

Pre-conditions

Pre-condition One

A donor account is only necessary for people who have donated to Adelante and should only be created when the first donation is made. In addition to this, the system must be online in order for this use case to be performed since it is entire based around a web application.

Post-conditions

Post-condition One

The account information will be saved and backed up in the event of data loss. The account can be modified and archived at any point in the future.

Extension Points

Modify Donor Account

UC-8: Allows staff to update or alter any information as it is needed.


Archive Donor Account

UC-9: Allows staff to archive donor accounts and mark them as inactive and puts them on the “do not disturb list”. These users will no longer receive updates from Adelante.


Modify Donor – 8 Brief Description

This use case enables staff to go into existing accounts and make changes as necessary. If an error has been made or an account needs information to be updates, staff will have the ability to do so.

Flow of Events

Basic Flow

The actors in this use case are Adelante staff members. A staff member can edit a donor account page at any time. Clicking edit will give staff access to the following forms:


Last name [Textbox]

Initial [Textbox]

Company [Textbox]



Email [Textbox]

Address [Textbox]

Zip [Textbox]

City [Textbox]

State [Dropdown

Country [Dropdown]


The user can add or update information in order to most accurately represent the donor.

Alternative Flows

Error While Updating

If a user makes a mistake and leaves a non-optional form blank or incorrectly enters information, such as letters in a numbers only textbox, the website will prompt the user to go back and fix any problems, and will not update the account until all information is correctly entered.

Rolling Back

If a user makes a mistake editing an account and doesn’t find out about it until later, the user will have the option to roll back to a previous version of the account.


Deleting an Account

An account should only be deleted if it should have never been created in the first place, but the option is there should the need arise. Accounts should be kept indefinitely for record keeping.

Pre-conditions

Pre-condition One

In order to edit a user account, the account must have already been created at a previous time. A user account should only be edited in order to correct misinformation or add additional information that was previously left blank.

Post-conditions

Post-condition One

After completing this process, a user account will now best reflect donors with the most up to date information.

Extension Points

Archive Donor Account

UC-9: A donor account can be archived when they no longer want to receive updates about Adelante or if they have been inactive for an extended period of time.

Create Donor Account

UC-7: A donor account must be created before it can be modified..


Archive Donor – 9

Brief Description

A user account needs to be archived to mark it as inactive. It should be archived when the donor should no longer be contacted.

Flow of Events

Basic Flow

The actors in this use case are Adelante staff members. Staff can go in and mark an account as “Archived” which will stop all attempts at communication with a donor. A donor account should be consider for archiving after an extended period of inactivity or if the donor requests to stop receiving updates from Adelante. This use case is as simple as the user navigating to the donor account page and pressing the archive button. The website will prompt the user with a confirmation request, and after pressing “Confirm”, the account will be archived. If the user presses “Cancel”, the account will not be archived. An archived account cannot be edited.

Alternative Flows

Restoring an Account from Archive

If for any reason a Donor decides they want to receive information again or if they become active with Adelante again, the donor account can be taken out of the archive and restored as a regular account.

Trying to Create an Existing, Archived, Account

If a staff member attempts to create an account for a person or organization that has been archived, the website will throw an error message informing the user that the account already exists and has been archived. It will prompt the user to restore the account from the archive.

Special Requirements

First Special Requirement

In order to be archived, the donor account must either have been inactive for an extended period of time or have been requested from the donor.

Pre-conditions

Pre-condition One

In order to be archived, an account must exist; therefore, the completion of UC-7 is required.


Post-conditions

Post-condition One

After completion of this use case, the donor account will be marked as “Archived”, and will no longer be available to edit and will place the account on the “Do not disturb” list. The person or company associated with the account will stop receiving updates from Adelante.

Extension Points

UC-7

In order for this use case to be applied, UC-7, create a donor account, must have been completed at a previous point in time.


Create Event – 10

Brief Description

This use case represents the process of creating a new event. Staff will be able to create “event” entries to signify a date when Adelante plans to host an event for promotional, donor, etc. purposes. Event entries will have the date of the event and information describing the event.

Flow of Events

Basic Flow

The actor(s) in this use case are Adelante Staff members. When creating an event, the actor will enter information into forms on a webpage. The possible forms are as follows:

Date [Calendar form]

Start Time [Time form]

End Time [Time form]

Location [Textbox]

Link to GPS link [Textbox -- optional]

Purpose of Event [Textbox, ONLY viewable by staff -- optional]

Goal of Event [Textbox, ONLY viewable by staff -- optional]

Description of Event [Textbox]

Staff attending event [Textbox]

Volunteers attending event [Textbox, ONLY viewable by staff -- optional]

Once the information is entered, the website will check for errors, missing entries, duplicate entries, inconsistencies, and other anomalies. If everything is correctly filled out, then the webpage will send a confirmation message and create the event.

Alternative Flows


If data is entered incorrectly, for instance, if the account number or name for the “staff attending” textbox doesn’t match an existing account, the webpage will display an error message informing the user that the user does not exist and the event will not have been created.

Missing Data

If data is missing from required fields, the website will prompt the user to fill out any remaining forms and will not have created an event. Additionally, the website will remind the user that there is information missing from optional forms, but present them with an option to fill those out before creating the event.

Conflicting EventCIS320 Spring 2016 Hoosier Analysts P a g e | 43

If an event is already taking place on the same day at the same time as the event that is being created, then the system will inform the user that there is already an event taking place at this time and that this may create a conflict. It will then give the user an option to either “Create Event Anyway”, “Edit Event”, or to “Cancel Event Creation”.

Duplicate Event

If an event is already taking place on the same day at the same time AND the same location as the event that is being created, then the system will inform the user that there is already an event taking place at this time and location and that “It is likely that this event has already been created because there is already an event taking place at the same time at the same location.” It will then give the user an option to either “Create Event Anyway”, to “Edit Event Information”, or to “Cancel Event Creation”.

Special Requirements

In order for an even to be considered for creation, Adelante must have permission from the host location of the event.

Pre-conditions

Pre-condition One

In order to create an event, Adelante must be online and have access to the internet. Only Staff have access to the event creation forms.

Post-conditions

Post-condition One

After this use case is successfully performed, a new event will be listed on the calendar and a notification will have been sent out to the appropriate recipients.

Extension Points

Modify Event

UC-11: Allows staff to update or alter any information for the event as is necessary.

Delete/Cancel Event

UC-12: Allows staff to cancel an event. This will notify all appropriate users.

Modify Event – 11


Brief Description

This use case represents the process of modifying an existing event. Staff will be able to modify an event in order reflect the most accurate, up-to-date information.

Flow of Events

Basic Flow

The actor(s) in this use case are Adelante Staff members. When modifying an event, the actor will have access to the following forms:

Date [Calendar form]

Start Time [Time form]

End Time [Time form]

Location [Textbox]

Link to GPS link [Textbox -- optional]

Purpose of Event [Textbox, ONLY viewable by staff -- optional]

Goal of Event [Textbox, ONLY viewable by staff -- optional]

Description of Event [Textbox]

Staff attending event [Textbox]

Volunteers attending event [Textbox, ONLY viewable by staff -- optional]

Once the information has been rectified, the website will check for errors, missing entries, duplicate entries, inconsistencies, and other anomalies. If everything is correctly filled out, then the webpage will send a confirmation message and create the event.

Alternative Flows

Date Entered Incorrectly

If data is entered incorrectly, for instance, if the account number or name for the “staff attending” textbox doesn’t match an existing account, the webpage will display an error message informing the user that the user does not exist and the event will not be updated.

Missing Data

If data is missing from required fields, the website will prompt the user to fill out any remaining forms and will not have modified the event. Additionally, the website will remind the user that there is information missing from optional forms, and offer them the option to fill those out before modifying the event.

Conflicting Event

If an event is already taking place on the same day at the same time as the event that is being modified, then the system will inform the user that there is already an event taking place at this time and that this may create a conflict. It will then give the user an option to either “Modify Event Anyway”, “Edit Event”, or to “Cancel Event Modification”.

Duplicate Event


If an event is already taking place on the same day at the same time AND the same location as the event that is being modified, then the system will inform the user that there is already an event taking place at this time and location and that “It is likely that this event already exists because there is already an event taking place at the same time at the same location.” It will then give the user an option to either “Modify Event Anyway”, to “Edit Event Information”, or to “Cancel Event Modification”.

Pre-conditions

Pre-condition One

In order to modify an event, an entry for the event has to have been created in at an earlier time. It is impossible to modify an event that does not yet exist.

Post-conditions

Post-condition One

After this use case is successfully performed, the event entry will now reflect the most accurate, up-to-date information.

Extension Points

Create Event

UC-10: Allows staff to create an event.

Delete/Cancel Event

UC-12: Allows staff to cancel an event. This will notify all appropriate users.

Cancel Event – 12


Brief Description

This use case represents the process of cancelling an event. Staff will be able to cancel an event as necessary, for any reason.

Flow of Events

Basic Flow

This actor(s) in this use case are Adelante staff members. When cancelling an event, the actor will simply navigate to the event entry and use the “cancel event” option. When the cancel even option is pressed, the web page will display a message warning that “Once this event is canceled, a notification will be sent out to all appropriate users informing them of the cancelation. This event will be archived for future reference” The website will then mark the event as cancelled and archived.

Alternative Flows

Delete Archived Event

If an event was created by mistake, then it is possible to delete an archived event. Staff only needs to navigate to the event entry of an archived event and press delete event permanently. The website will display a message that “It is only advisable to delete an event if it is absolutely necessary, for instance, if the event was created by mistake.” Once the user confirms this, the website will inform the user that this action is permanent and cannot be undone. After the user confirms this second message, then the event will be gone forever. The actor will land on the events homepage.

Pre-conditions

Pre-condition One

In order to cancel an event, an event has to exist to begin with. It is impossible to delete an event that has not yet been created.

Post-conditions

Post-condition One

After this use case is performed, the event will now be cancelled and archived. A notification will be sent out informing the appropriate users that the event has been cancelled.

Post-condition Two

If the “Delete Archived Event” alternate flow is performed, then the event will be completely gone.

Extension Points

Create Event

UC-10: Allows staff to create an event.CIS320 Spring 2016 Hoosier Analysts P a g e | 47

Modify Event

UC-11: Allows staff to update or alter any information for the event as is necessary.

Create Class – 13

Brief Description


This use case describes how a new class will be inputted into the system by a staff member. The staff member will have to know certain information (listed below) in order to perform this use case. Once they click “add class” the staff member will enter the information and selects submit to enter the class into the system.

Flow of Events

Basic Flow

Staff member clicks “add class” button.

Staff member then fills out the class information: Class ID, Class Name, Class Start Date, Class End Date, Class Location, Class Enrollment Size (max), Class Enrollment Size (min), Class Enrollment Size (actual).

Staff member clicks submit.

Alternative Flows

Missing Data

Not all information needed has been entered causing an error message.

Incorrect Data

Staff member inputted an incorrect character, when this happens the system will show an error message.

Duplicate Data

Staff member enters information that matches another class exactly. This will produce an error message.

Pre-conditions

Staff Member Login

Staff member must login to the system.

Post-conditions

New Class

A new class is saved into the system.

Modify Class – 14

Brief Description


This use case describes how to change the contents of a class that is already in the system. Staff member will select desired class and choose the “edit” button. From there the staff member may change the desired information. Then the staff member selects “submit” and the information is updated in the system.

Flow of Events

Basic Flow

Staff member selects desired class.

Staff member modifies class information: ID, Name, Location, Start Date, End Date, Size (max), Size (min), Size (actual).


Alternative Flows

Missing Data


Incorrect Data

Staff member inputted an incorrect character causing an error message.

Duplicate Data

Staff member enters information that matches another class exactly causing an error message.

Pre-conditions


Post-conditions

A class’ information is changed.

Extension Points

Add Class

A class must be created before it can be modified.

Delete Class – 15

Brief Description


This use case describes how a staff member will remove a class from the system completely. Staff member will select “delete class”. The list off classes will then appear on the screen. The staff member will select the desired class and click “delete”. A confirmation message will ask if they are sure. Staff member must select “confirm” and then the class is removed from the system.

Flow of Events

Basic Flow

Staff member selects desired class.

Staff member clicks delete.

Staff member clicks confirm.

Pre-conditions


Post-conditions

Class Deleted

A class is deleted from the system

Not Offered

A class should be deleted when that class is no longer offered by Adalante Hispanic Achievers.

Extension Points

Add Class

A class must be created before it can be deleted.

Add Volunteer – 16

Brief Description


This use case describes how a Staff Member inputs a new volunteer into the system. The staff member must know certain information (listed below) in order to perform this use case. Once the staff member clicks “add volunteer” they then are able to enter the volunteers’ information and clicks “submit” and it enters the volunteer into the system.

Flow of Events

Basic Flow

Staff member clicks “New Volunteer”.

Staff member enters volunteer information: First Name, Last Name, DOB, Address (Street Number and Name, City, State, Zip Code), Phone Number, and Available Dates.

Staff member submits information.

Alternative Flows

Missing Data


Incorrect Data

Staff member inputted an incorrect character causing an error message.

Duplicate Data

Staff member enters information that matches another Volunteer which produces an error message.

Pre-conditions

Staff Member Login


Post-conditions

New Volunteer

A new volunteer’s information is saved in the system.

Modify Volunteer – 17

Brief Description


This use case describes how to change the contents of a volunteer that is already in the system. The staff member will select the desired volunteer and choose the “edit” button. From there, the staff member may change the desired information. Then click “submit” and the information is updated in the system.

Flow of Events

Basic Flow

Staff member selects desired volunteer.

Staff member modifies volunteer information: Name, Address, City, State, Zip Code, or Phone Number


Alternative Flows

Missing Data


Incorrect Data

Staff member inputs the incorrect character causing an error message.

Duplicate Data

Staff member enters information that matches another Volunteer causing an error message.

Pre-conditions

Staff Member Login


Post-conditions

A volunteer’s information is changed in the system.

Extension Points

Add Volunteer

A volunteer must be created before it can be modified.

Archive Volunteer – 18

Brief Description


This use case describes how to save an inactive volunteer into the system for possible later use. The staff member will select “archive volunteer”. From the drop-down list they will choose the volunteers name. Then the staff member selects “archive”. A confirmation message asking if they are sure will pop up. The staff member selects “submit” and the volunteer us archived into the system.

Flow of Events

Basic Flow

Staff member selects desired volunteer.

Staff member clicks “Archive”.

Staff member clicks “Confirm”.

A volunteers Name, Address, City, State, Zip Code and Phone Number is archived into the system.

Pre-conditions

Staff Member Login


Post-conditions

Save Volunteer

A volunteer is archived in the system.

No Contact

A volunteer should be archived when they should no longer be contacted.

Extension Points

Add Volunteer

Add Parent – 19

Brief Description


The staff members of Adelante Hispanic Achievers, upon logging into the system, will have the option to add parent information for the students who are attending Adelante programs, enhancing ease of communication and analytical capability.

Flow of Events

Basic Flow

Within the student summary page, the staff member clicks the “Manage parent information” button, which displays all existing parent information for this student. The “Add parent” button is also present on this page; this button initiates the primary workflow for adding a parent.

The Adelante staff member clicks “Add Parent”.

The Adelante staff member enters the parent first name, parent last name, and parent-date-of-birth in the provided fields, leaving the optional “Create parent login?” checkbox unchecked. The Adelante staff member may also enter information into other optional fields – parent phone number, parent e-mail, and notes.

The Adelante staff member clicks “Submit”.

The form information is manipulated and validated by the system.

If there are errors in the form submission as determined by validation, the system presents the user with an error message and prompts them to correct.

If there are no errors in the form submission as determined by validation, the system creates a parent entry in the database and relates that entry to the associated student via database keys.

Alternative Flows

First Alternative Flow

Within the student summary page, the staff member clicks the “Manage parent information” button, which displays all existing parent information for this student. The “Add parent” button is also present on this page; this button initiates the primary workflow for adding a parent.

The Adelante staff member clicks “Add Parent”.

The Adelante staff member enters the parent first name, parent last name, and parent-date-of-birth in the provided fields, and checks the optional “Create parent login?” checkbox. The Adelante staff member may also enter information into other optional fields – parent phone number, parent e-mail, and notes.

The Adelante staff member then enters the parent username, parent password, parent password confirmation, and parent e-mail information into the provided fields. These fields are unavailable until “Create parent login?” is checked.






The system sends a confirmation e-mail to the provided parent e-mail address notifying the user an account has been created, and providing them with login instructions.

Second Alternative Flow

Within the staff portal homepage, the Adelante staff user clicks “Add new parent” button.

The Adelante staff member enters the student first name, student last name, student ID, student date-of-birth, parent first name, parent last name, and parent-date-of-birth in the provided fields, leaving the optional “Create parent login?” checkbox unchecked. The Adelante staff member may also enter information into other optional fields – parent phone number, parent e-mail, and notes.





Third alternative flow

Within the staff portal homepage, the Adelante staff user clicks “Add new parent” button.

The Adelante staff member enters the parent first name, parent last name, and parent-date-of-birth in the provided fields, and checks the optional “Create parent login?” checkbox. The Adelante staff member may also enter information into other optional fields – parent phone number, parent e-mail, and notes.

The Adelante staff member then enters the parent username, parent password, parent password confirmation, and parent e-mail information into the provided fields. These fields are unavailable until “Create parent login?” is checked.





The system sends a confirmation e-mail to the provided parent e-mail address notifying the user an account has been created, and providing them with login instructions.

Pre-conditions

Student entry must exist within the database.

Adelante staff member must have a staff login.


Post-conditions

A parent entry is created and associated with a student entry, OR

A parent entry is created and associated with a student entry, and a parent login entry is also created, OR

Parent entry fails due to incorrect or incomplete information – the system returns to its pre-use case state.

Modify Parent – 20


Brief Description

Staff members at Adelante log in and make updates to parent information. The database is updated with the new information, and with a timestamp reflecting when the changes took place. Flow of Events

Basic Flow

Within the student summary page, the staff member clicks the “Manage parent information” button, which displays all existing parent information for this student.

The staff member clicks the “Edit” button in the parent information entry which they would like to modify.

The staff member changes the information in the parent first name, parent last name, parent-date-of-birth, parent e-mail, parent phone, notes, parent password, or parent username as desired.

The staff member clicks the “Submit” button on the modify parent input screen.

The form submits all fields to the system for validation.

If field validation fails, the user is presented with an error message for each field with an invalid entry.

If field validation is successful, the entry is updated in the database. A timestamp is created which reflects the time the changes took place.

Pre-conditions

Parent entry must exist within the database.

Adelante staff member must have valid staff login.

Post-conditions

Parent entry is updated with new information. Last Change timestamp updated, OR

Parent update validation fails – system is returned to previous state.

Extension Points

This use case occurs after the staff member login has already occurred.

This use case is dependent on at least one corresponding instance of the Add Parent use case having occurred.

Archive Parent – 21


Brief Description

Parent information is marked as “Archived” and saved to a backup server.

Flow of Events

Basic Flow

Within the student summary page, the staff member clicks the “Manage parent information” button, which displays all existing parent information for this student.

The staff member clicks the “Edit” button in the parent information entry which they would like to modify.

The staff member clicks the “Archive” button.

User is presented with a message box – “Are you sure you want to archive this parent’s information and mark as inactive?”

User selects “Yes” – parent information is moved to historical table and marked as “Inactive.” Changes can no longer be made to parent record.

User selects “No” – user is returned to the student summary page.

Database log entry is created to reflect transfer to historical table.

Alternative Flows


Student entry is archived (see “Archive Student Information” use case).

Upon archival of student information, message box asks user if they would also like to archive parent’s information.

User selects “Yes” – parent information is moved to historical table and marked as “Inactive.” Changes can no longer be made to parent record.

User selects “No” – student information is archived, but parent information remains active.

Database log entry is created to reflect transfer to historical table.

Pre-conditions

Student entry exists

Parent entry is associated with a student entry

Valid Adelante staff login exists.

Post-conditions

Parent entry is moved to historical table, OR


User decides not to archive parent entry - the system returns to its pre-use case state.

Extension Points

This use case is dependent on one or more instances of the Add Student use case having been completed.

This use case is dependent on one or more instances of the Add Parent use case having been completed.

This use case may be initiated as part of the Archive Student use case flow.

Add Staff Member – 22


Brief Description

This use-case is where the administration for the organization can access an area to be able to add a staff member into the database. This will be where all the personal information for the new staff member will be inputted such as address, phone number, date of birth, and etc. This will also have the date of hire and benefits eligibility of the staff member. This will also have a section where the administrative person can add what properties this particular staff member has access to.

Flow of Events

Basic Flow

The administrator opens up an internet browser and goes to the Adelante Hispanic Achievers website.

The administrator logs in to the system website.

The system opens the AHA website.

The administrator clicks on the staff tab.

The system opens up a screen that has tabs to access current staff members, previous staff members, and a tab to add a new staff member.

The administrator clicks on Add New Staff Member tab.

The system opens up the form to add the staff members’ information.

The administrator inputs all information into the Personal Information Tab. This would include name, address, phone number, date of birth, email address, a unique identification number that is assigned by the administrator, availability schedule, tax identification information, and current filing status.

The administrator clicks Save information

The system checks the information to make sure there is no missing data.

If everything correct, the system saves the New Staff Member.

Alternative Flows

There is an error with the login. Administrator checks username and password to make sure it was entered correctly. Administrator tries logging in again and successfully accesses website.

If there is missing data, the system addresses the missing data to the administrator for correction. The system will not save the New Staff Member when there are errors in the information. Once all errors have been corrected then the system saves the New Staff Member and goes back to the main screen.

Pre-conditions

The user has internet connection


The person logging in has a login name and password

The person logging in to the system has administrative rights in order to be able to add a staff member.

The administrator has all the new staff members’ information to input into the system.

Post-conditions

The post-condition for this use-case is that after the system saves the New Staff Member then it returns to the main page awaiting the next instructions from the user.

Modify Staff Member – 23


Brief Description

This use-case is where the administration for the organization can access an area to be able to modify a staff member in the database. This will be where all the personal information for the staff member can be edited such as address, phone number, date of birth, and etc. This will also have the date of hire and benefits eligibility of the staff member so if new benefits need to be added. This will also have a section where the administrative person can modify what properties this particular staff member has access to.

Flow of Events

Basic Flow






The administrator clicks on the Current Staff Member tab.

The system opens up the form that contains the current staff members’ information.

The administrator updates any information into the Personal Information Tab. This could involve updating name, address, phone number, email address, a unique identification number that is assigned by the administrator, availability schedule, tax identification information, and current filing status.



If everything correct, the system saves the updates for the Staff Member.

Alternative Flows


If there is missing data, the system addresses the missing data to the administrator for correction. The system will not save the changes made to the Staff Member when there are errors in the information. Once all errors have been corrected then the system saves the Staff Member and goes back to the main screen.

Pre-conditions

The user has internet connectionCIS320 Spring 2016 Hoosier Analysts P a g e | 63



The administrator has all the new staff members’ information to input into the system.

Post-conditions

The post-condition for this use-case is that after the system saves the Staff Member then it returns to the main page awaiting the next instructions from the user.

Extension Points

Security

Archive Staff Member – 24


Brief Description

This use-case is where the administration for the organization can access an area to be able to archive a staff member in the database that has become inactive within the organization. This will be where all the personal information for the staff member will be saved such as address, phone number, date of birth, and etc. if they were to return to the organization. This will also have the date of hire and the date that the employee left the organization. This will also have a section where the administrative person can modify what properties this particular staff member no longer access to.

Flow of Events

Basic Flow






The administrator clicks on the Current Staff Member tab.

The system opens up the form that contains the current staff members’ information.

The administrator updates any information into the Personal Information Tab. This could involve updating name, address, phone number, email address, a unique identification number that is assigned by the administrator, availability schedule, tax identification information, and current filing status. This is also where the administrator can mark the employee as inactive.



If everything correct, the system saves the updates for the Staff Member.

Alternative Flows


If there is missing data, the system addresses the missing data to the administrator for correction. The system will not save the changes made to the Staff Member when there are errors in the information. Once all errors have been corrected then the system saves the Staff Member and goes back to the main screen.

Pre-conditions





The administrator has the date that the staff member is no longer of active status.

Post-conditions

The post-condition for this use-case is that after the system saves the Staff Member then it returns to the main page awaiting the next instructions from the user.

The Staff Member could come back after leaving for a short period of time and they could be made active again.

Extension Points

Security

Add Media – 25

Brief Description


This use-case is a section of the database where staff of AHA can place new photos that have been taken of the organization, students, staff, volunteers, or community events. These can be placed in the photo gallery so that staff, volunteers, current students, possible future students, or their parents can see photos from events at AHA.

Flow of Events

Basic Flow




The administrator clicks on the Photo Gallery Tab.

The system opens up a screen that has tabs to access different folders containing photos from events involving AHA.

The administrator clicks on the folder or the create new folder where they want to place the new photo.

The system opens up the folder where the photos are to be added.

The administrator uploads the photo or photos they want to add.


The system checks the photos to make sure it is in the correct format for photos.

If everything correct, the system saves the photo or photos that have been uploaded.

Alternative Flows


If the format of the photo is not correct then the system returns an error message stating to correct the format of the photo.

Pre-conditions



The person logging in to the system has administrative rights in order to be able to add photos.

The administrator has the photos in the correct format to upload.

Post-conditions


The post-condition for this use-case is that after the system saves the Photos then it returns to the main page awaiting the next instructions from the user.

Extension Points

Security


Modify Media – 26

Brief Description

This use-case is a section of the database where staff of AHA can update photos that have been taken of the organization, students, staff, volunteers, or community events. These can be placed in the photo gallery so that staff, volunteers, current students, possible future students, or their parents can see photos from events at AHA.

Flow of Events

Basic Flow






The administrator clicks on the album that they want to update.

The system opens up the folder that the photos are stored in.

The administrator can remove or add photos to the folder.


The system checks the format of the photo to make sure it is the correct type.

If everything correct, the system saves the modified photos.

Alternative Flows


If the photo is not the correct format then the system returns an error message stating to correct format of the photo.

Pre-conditions



The person logging in to the system has administrative rights in order to be able to modify photos.CIS320 Spring 2016 Hoosier Analysts P a g e | 69

The administrator has the correct format on the photos to be updated.

Post-conditions

The post-condition for this use-case is that after the system saves the photos then it returns to the main page awaiting the next instructions from the user.

Extension Points

Security


Delete Media – 27

Brief Description

This use-case is a section of the database where staff of AHA can delete photos that have been taken of the organization, students, staff, volunteers, or community events. These can be removed from the photo gallery so that staff can keep current photos as the main focus for the organization. This also frees up space in the storage.

Flow of Events

Basic Flow






The administrator clicks on the album that they need to delete a photo or photos from.

The system opens up the folder that the photos are stored in.

The administrator clicks on the photo/photos that they want to remove.

The administrator clicks Remove Photo/s

The system asks to make sure that the administrator wants to remove the photo.

The administrator clicks yes or no to remove the photo/s.

Alternative Flows


The administrator clicks no when prompted to remove the photo and the system returns to the album that photo is currently stored in.

Pre-conditions




The person logging in to the system has administrative rights in order to be able to delete photos.

Post-conditions

The post-condition for this use-case is that after the system saves the changes to the album then it returns to the Photo Gallery awaiting the next instructions from the user.

Extension Points

Security


Add Form – 28

Brief Description

Adelante staff members enter the Forms portal and upload new forms. They are also able to configure the access level for those forms.

Flow of Events

Basic Flow

Staff member clicks “Forms” link.

Staff member clicks the “Upload Forms” button within the Forms main page.

Staff member uses “Browse” field to navigate to location of form on hard drive and selects the form.

Staff member selects checkboxes next to “Student” and “Parent” if they wish for those users to have access to the form as well.

Staff member clicks “Submit” button.

Form object is saved to database for retrieval.

Pre-conditions

Adelante staff member must have a valid staff login.

Post-conditions

Form is uploaded and saved to database for use and retrieval, OR

Form submission fails or is cancelled by the user – the system reverts to pre-upload state.


Modify form – 29

Brief Description

Adelante staff members enter the Forms portal and edit existing forms entries by uploading new versions.

Flow of Events

Basic Flow


Staff member clicks the “Change Forms” button within the Forms main page.

If the form requires changes, staff member uses “Browse” field to navigate to location of form on hard drive and selects the new form to upload and overwrite existing form.

Staff member selects “Parent” and/or “Student” checkboxes depending on the desired level of access.

Staff member clicks “Submit” button

Form object is saved to database for retrieval.

Pre-conditions


Valid form must exist within the system.

Post-conditions

Form is uploaded and saved to database for use and retrieval, OR

Form submission fails or is cancelled by the user – the system reverts to pre-upload state.


Delete Form – 30

Brief Description

Adelante staff members enter the Forms portal and remove existing forms which are deprecated or no longer needed.

Flow of Events

Basic Flow


Staff member clicks the “Change Forms” button within the Forms main page.

In the “edit forms” page, the staff member clicks “Remove form”

Staff member clicks “Submit” button.

Form object is removed from database and a log entry is created.

Pre-conditions


Valid form must exist within the system.

Post-conditions

Form is deleted from the database and a log entry is created, OR

Form deletion fails or is cancelled by the user – the system reverts to pre-upload state.


Print Form – 31

Brief Description

Various Adelante users print paper copies of forms for completion.

Flow of Events

Basic Flow

Adelante staff member logs into system


Staff member clicks the “Print” button corresponding with the form they would like to print.

The form is printed; a number which keeps a running count for each time that form is printed is incremented.

Alternative Flows


Adelante student logs into system

Student clicks “Forms” link and is presented with all forms which have “Student” access level selected.

Student clicks the “Print” button corresponding with the form they would like to print.

The form is printed; a number which keeps a running count for each time that form is printed is incremented.


1. Parent logs into system

2. Parent clicks “Forms” link and is presented with all forms which have “Parent” access level selected.

3. Parent clicks the “Print” button corresponding with the form they would like to print.

4. The form is printed; a number which keeps a running count for each time that form is printed is incremented.

Pre-conditions

Form has been uploaded into the system

Appropriate level of access for current user has been granted to that form

User’s browser is capable of printing documents from web pages.


Post-conditions

The form is printed out, OR

Printing fails. The system is unaffected.

Extension Points

This use case is dependent on at least one instance of the Add Forms use case having been completed; this use case would occur after that instance had completed.

This use case is dependent on at least on existence of a relevant Add User use case having been completed (add parent, add student, or add staff member).


Create Board Member Account – 32

Brief Description

This use case details the function of creating a Board of Director account. Staff will be able to create website accounts for new Board of Directors in order to help track and maintain relationships with them. Board member accounts will contain identifying and contact information for members.

Flow of Events

Basic Flow

The actor in this use case is an Adelante staff member. Adelante staff can enter Board member information easily into the following forms:


Last name [Textbox]

Initial [Textbox]

Company [Textbox]



Email [Textbox]

Address [Textbox]

Zip [Textbox]

City [Textbox]

State [Dropdown]

Country [Dropdown]


Once the information is entered, the website will check for errors, missing entries, duplicate entries, inconsistencies, and other anomalies. If everything is correctly filled out, then the webpage will send a confirmation message and create a board member account.

Alternative Flows


If data is entered incorrectly, for instance, numbers in a name box, the website will display an error message informing the user that an error has been made, and an account could not be created.


Missing Data

If data is missing from certain fields, the website will prompt the user to fill out any remaining forms and will not have created a donor account. Some fields will be optional and will accept null values. Optional forms include:

Email

Phone Number

Initial


Duplicate Account

If a board member account has already been created with the same information, the webpage will display a message informing the user that “This account already exists”. It will provide the option to “Go to Board member Account” or “Cancel”.

Pre-conditions

Pre-condition One

A board member account is only necessary for people who are on the board of directors for Adelante. In order for an account to be created, the individual must already be on the board of directors.

Post-conditions

Post-condition One

The account information will be saved and backed up in the event of data loss. The account can be modified and archived at any point in the future.

Extension Points

Modify Board Member Account

UC-37: Allows staff to update or alter any information as it is needed.

Archive Board Member Account

UC-38: Allows staff to archive board member accounts and mark them as inactive and puts them on the “do not disturb list”. These users will no longer receive updates from Adelante.


Modify Board Member Account – 33

Brief Description

This use case details the function of modifying a Board of Director account. Staff will be able to modify website accounts for board of directors in order for the accounts to reflect the most accurate information. Board member accounts will contain identifying and contact information for members.

Flow of Events

Basic Flow

The actor in this use case is an Adelante staff member. Adelante staff can modify Board member information easily into the following forms:


Last name [Textbox]

Initial [Textbox]

Company [Textbox]



Email [Textbox]

Address [Textbox]

Zip [Textbox]

City [Textbox]

State [Dropdown]

Country [Dropdown]


Once the information is changed, the website will check for errors, missing entries, duplicate entries, inconsistencies, and other anomalies. If everything is correctly filled out, then the webpage will send a confirmation message and update a board member account.

Alternative Flows


If data is entered incorrectly, for instance, numbers in a name box, the website will display an error message informing the user that an error has been made, and an account could not be modified.


Missing Data

If data is missing from certain fields, the website will prompt the user to fill out any remaining forms and will not have modified a donor account. Some fields will be optional and will accept null values. Optional forms include:

Email

Phone Number

Initial


Duplicate Account

If a board member account already exists with the same information, the webpage will display a message informing the user that “This account already exists”. It will provide the option to “Go to Board member Account” or “Cancel”.

Pre-conditions

Pre-condition One

In order to be modified a board member account must already exist.

Post-conditions

Post-condition One

The account information will be saved and backed up in the event of data loss. The account will now reflect the most accurate information available.

Extension Points

Create Board Member Account

UC-36: Allows staff to Create any information as it is needed.

Archive Board Member Account

UC-38: Allows staff to archive board member accounts and mark them as inactive and puts them on the “do not disturb list”. These users will no longer receive updates from Adelante.


Archive Board Member Account – 34

Brief Description

This use case details the function of archiving a Board of Director account. Staff will be able to archive website accounts for board of directors in order to reflect that they no longer have a seat on the board of directors. They will no longer receive updates from Adelante.

Flow of Events

Basic Flow

The actor in this use case is an Adelante staff member. Adelante staff can mark board member accounts as archived. Archived accounts are kept for record keeping. Adelante retains information on the board member but the board member will no longer receive updates from Adelante.

Alternative Flows

Restoring an Account from Archive

If for any reason a board member should resume their seat on the board of directors, the board member account can be taken out of the archive and restored as a regular account.

Trying to Create an Existing, Archived, Account

If a staff member attempts to create an account for a person or organization that has been archived, the website will throw an error message informing the user that the account already exists and has been archived. It will prompt the user to restore the account from the archive.

Pre-conditions

Pre-condition One

In order to be archived a board member account must already exist and the board member must either want off the board of directors or be voted off by staff and other board members.

Post-conditions

Post-condition One

The accounts will be set as archived. The board member will no longer receive updates and no longer has a seat on the board of directors.

Extension Points

Create Board Member Account

UC-36: Allows staff to create any information as it is needed.


Modify Board Member Account

UC-37: Allows staff to modify board member accounts to reflect the most accurate information.


Create Book an Appointment - 35

Brief Description

Site users and visitors click the “Book Appointment” button to schedule a Appointment with Adelante staff.

Flow of Events

Basic Flow

Site user clicks “Click here to book an Appointment with Adelante” hyperlink on home page.

Site user selects open calendar time from calendar object.

Site user selects a start and end time for the Appointment with Adelante staff.

Optionally, a site user may enter notes about the purpose or content of the Appointment in the “Notes” field.

Site user enters contact e-mail address.

When finished, site user clicks “Submit” button

Alternate Flow

After clicking the “Click here to book a Appointment with Adelante” hyperlink, users who are currently logged in will have additional functionality to modify or delete existing Appointments.

Pre-conditions

None.

Post-conditions

Appointment is created and added to Adelante staff calendar.

Adelante staff and Appointment creator are sent a notification of the appointment being scheduled via e-mail.


Modify Appointment – 36

Brief Description

Site users with active logins who have created Appointments previously use the site to update Appointment times, dates, contact information, and notes.

Flow of Events

Basic Flow

A logged-in site user clicks “Click here to book a Appointment with Adelante” hyperlink on home page.

Site user selects calendar time for existing Appointment from calendar object.

Site user clicks “Modify Appointment”

Site user selects a start and end time for the Appointment with Adelante staff.

Optionally, a site user may update notes about the purpose or content of the Appointment in the “Notes” field.

Site user enters contact e-mail address.

When finished, site user clicks “Submit” button

Pre-conditions

A user with a site login has logged in

That user has created an Appointment with Adelante previously.

Post-conditions

Appointment is updated in Adelante staff calendar.

Adelante staff and Appointment creator are sent a notification of the appointment being updated via e-mail.


Delete Appointment – 37

Brief Description

Site users with active logins who have created Appointments previously use the site to delete their Appointment requests.

Flow of Events

Basic Flow

A logged-in site user clicks “Click here to book a Appointment with Adelante” hyperlink on home page.

Site user selects calendar time for existing Appointment from calendar object.

Site user clicks “Delete Appointment”

Site user is presented with a confirmation pop-up window “Are you sure you want to delete your Appointment on <date>?”

Site user clicks “Yes” to cancel the Appointment.

Appointment updates are submitted to the database

Adelante staff and the user are sent automated e-mails notifying them of deletion.

Alternative Flow

Site user is presented with a confirmation pop-up window “Are you sure you want to delete your Appointment on <date>?”

Site user clicks “No” to abandon the deletion process Site user is returned to user home page – no changes are made to the Appointments

database.

Pre-conditions

A user with a site login has logged in

That user has created a Appointment with Adelante previously.

Post-conditions

Appointment is deleted from Adelante staff calendar.

Adelante staff and Appointment creator are sent a notification of the appointment being deleted via e-mail.


Login – 38

Brief Description

This use-case is the main screen where users are able to sign in so that they can access all the different areas that are available to them. These areas that they may access are different for students, volunteers, donors, and administrative personnel. Each user will be assigned a unique user name and password for access.

Flow of Events

Basic Flow

The user opens up an internet browser and goes to the Adelante Hispanic Achievers website.

The user is directed to enter their unique username and password.

The user enters their information and clicks enter.

The system verifies the login information.

If login correct, the system opens the AHA website.

The user can see the different areas that he/she is able to access.

Alternative Flows

There is an error with the login. User checks username and password to make sure it was entered correctly. User tries logging in again and successfully accesses website.

If user has forgotten their username or password they can click the link for the username/password reset.

Pre-conditions


The person logging in has been entered into the AHA system

The person logging in has been assigned a login name and password

Post-conditions

Evaluate the permissions for the user logging in.

System directs user to the correct screen

Extension Points

Security


Backup – 39

Brief Description

In order to keep the entire system secure, the system administrator can set rules in order to enhance security for Adelante’s information system.

Flow of Events

Basic Flow

The actor in this use case is the administrator for Adelante’s system. It is likely that the head administrator will be either Mara or Dustin. The administrator sets the rules and permissions for the following activities:

Logins

Passwords

Account permissions

Backups/recovery

System usage

Delete Accounts

The actor can reset logins and set password constraints in order to increase security. The actor can also set rules requiring passwords to be changed every 6 months. The actor can also set who has access to what parts of the website. They control what users have access to the database, to student information, to volunteer information, and to events. Backups are also scheduled by this actor; in addition recovery is also carried out by the administrator. The administrator has full access to all of the website’s tools and permissions.

Alternative Flows

Admin Dashboard

The dashboard gives the administrator quick glance diagnostics and statistics for the website and users. The dashboard also provides links to many pages where the administrator can set permissions.

Pre-conditions

Backups - If a backup is not scheduled, the administrator can schedule periodic backups. The admin can also perform backups whenever they feel it necessary.

Post-conditions

Backups - Important files are saved and secured, ready to be restore if something happens.


Extension Points

UC-34 Recovery

Security performs recovery operations.


Recovery System – 40

Brief Description

Allows staff members to recover the database from a hardware, software, network, or system failure and return to normal operations as quickly as possible. Recovery should protect the database and associated users from unnecessary problems and avoid or reduce the possibility of having to duplicate work manually.

Flow of Events

Basic Flow

Staff member clicks “Recovery”.

Staff member selects back up they wish to use to restore the system back to its state.

Staff member clicks “Run”.

Staff member clicks “Confirm”.

Alternative Flows

Corrupted Backup

The chosen back up is corrupted. Staff member must choose a different back up version.

Pre-conditions

Staff Member Login


Post-conditions

System Restored

System is restored to the chosen back up’s state.

Extension Points

Back Ups

Back Ups have to be created before the system can be recovered from a back up.


User Rights Administration – 41

Brief Description

Adelante staff users modify the level of access users have to different kinds of system resources via an all-inclusive online portal.

Flow of Events

Basic Flow

Within the Adelante Staff page, the Adelante staff member clicks “Update User Permissions” button, which opens a user selection screen.

The Adelante staff member chooses the user type “Parent”, which causes the next drop down box to populate with all active Parent names.

The Adelante staff member selects the parent’s name and clicks the “Next” button.

The Adelante staff member is presented with a screen containing all objects for which a parent may have rights to access. This includes student information, student course information, student attendance information, student uploads, and all forms and media. The Adelante staff member may select “Read”, “Edit”, or “None” for the permission levels.

When the appropriate permission levels are selected, the Adelante staff member clicks the “Submit” button.

The form is submitted and user rights are updated in the database.

Alternative Flows



The Adelante staff member chooses the user type “Student”, which causes the next drop down box to populate with all active Student names.

The Adelante staff member selects the Student’s name and clicks the “Next” button.

The Adelante staff member is presented with a screen containing all objects for which a student may have rights to access. This includes that student’s personal information, course information, attendance information, uploads, and all forms and media. The Adelante staff member may select “Read”, “Edit”, or “None” for the permission levels.


The form is submitted and user rights are updated in the database




The Adelante staff member chooses the user type “Staff”, which causes the next drop down box to populate with all active Staff names.

The Adelante staff member selects the staff member’s name and clicks the “Next” button.

The Adelante staff member is presented with a screen containing all objects for which a staff member may have rights to access. This includes student information, student course information, student attendance information, student uploads, and all forms and media, parent information, parent uploads, staff rights (if that staff member has rights to edit staff rights), database access, and user login information. The Adelante staff member may select “Read”, “Edit”, or “None” for the permission levels.


The form is submitted and user rights are updated in the database

Pre-conditions

At least one account of type student, staff, or parent exists.

The current user has been granted access to modify user permissions.

Post-conditions

User rights are updated in the database.


Sequence Diagram


Sequence Diagrams are models that are

the collaboration of objects based on a

time sequence. It shows how the objects

interact with others in a particular scenario

of a use case.

Sequence Diagrams


Class Diagram


Class diagrams provide an overview of the

target system by describing the objects and

classes inside the system and the relationships

between them. It provides a wide variety of

usages from modeling the domain-specific data

structure to detailed design of the target

system.

Class Diagram


Database Designs and Data Definitions


A data dictionary is a collection of descriptions of the data objects

or items in a data model for the benefit of programmers and

others who need to refer to them. A first step in analyzing a

system of objects with which users interact is to identify each

object and its relationship to other objects. This process is called

data modeling and results in a picture of object relationships. After

each data object or item is given a descriptive name, its

relationship is described (or it becomes part of some structure

that implicitly describes relationship), the type of data (such as

text or image or binary value) is described, possible predefined

values are listed, and a brief textual description is provided. This

collection can be organized for reference into a book called a data

Entity Relationship Diagram


Database Designs and Data DefinitionsStudent


PK FK Attribute Name Attribute Definition Type SizeStudent_Cellphone Cellphone Number for the Student Alphanumeric 11Student_Fname Student's First Name Text 15Student_Lname Student's Last Name Text 25Stuent_Suffix Student's Suffix ie. Jr. Text 2Student_Address Student's Home Address Alphanumeric 40Student_City City where Student lives Text 25Student_State State where student lives Text 20Student_Zip student's zip code Alphanumeric 5Student_Phone Alternate or home phone number Alphanumeric 11Student_Email Student's Email address Alphanumeric 30Student_DateOfBirth Date of student's birth Numeric 8Attendance_Status Displays whether student is active or not Binary 1Ambassador_Status Is the student an ambassador to Adelante Binary 1

Grant Awards


Family


Grants


Grant Proposal


Parent


Staff


Grant Agency


Administration


Enrollment


Login


PK FK Attribute Name Attribute Definition Type SizeStudent_Cellphone Student's Cellphone Number Alphanumeric 11Staff_Cellphone Staff Cellphone Number Alphanumeric 11Parent_Cellphone Parent Cellphone Number Alphanumeric 11Vol_Cellphone Volunteer Cellphone Number Alphanumeric 11User_Rights User Authorization Access 1-5 Alphanumeric 1Security User Password. Minimum 8 characters, include a Capital, lowercase, number, and symbol Alphanumeric 50

Volunteer


Volunteer Course Assignment


Volunteer Availability


Course


Calendar


Events


Event Attendance


MediaCourse_Access


Media


MediaEvent_Access


Donor


Donor_LogBook


Donations

PK FK Attribute Name Attribute Definition Type SizeDonor_Cellphone Donor Phone Number Alphanumeric 11Donation_Instance Number of times donor as donated Alphanumeric 4Donation_Date Date of donation Numeric 8Donation_Amount Amount Donated Numeric 7Donation_Single_Time Yes/No Binary 1Donation_Recurrence Yearly/Monthly/Weekly Alphanumeric 1Donation_Level Bronze/Silver/Gold/Platinum Donor Alphanumeric 1


Book Appointment

PK FK Attribute Name Attribute Definition Type SizeAppointment_Id Blockcode: (2)day(2)month()4year Numeric 8Calendar_ID Calendar ID Alphanumeric 7Appintment_Lname Last name of appointment attendee Text 25Appointment_Fname First name of appointment attendee Text 20


Board Member

PK FK Attribute Name Attribute Definition Type SizeBoard_cellphone Board member cellphone Alphanumeric 11Board_Lname Board member Last Name Text 25Board_Fname Board member first name Text 20Board_Address Board member address Alphanumeric 35Board_City Board member city Text 25Board_State Board member state Text 20Board_Zip Board member Zip Alphanumeric 5Board_Phone Board member Alt Phone number Alphanumeric 11Board_Email Board member Email Alphanumeric 45Board_Status Active/Inactive Binary 1


User Interface and Navigation Diagram & Screen Layout


The User Interface Navigation Diagram is the layout

that the system operates. This shows the developer and

user what happens when each link is selected so that

the flow of the system is clear to all involved.

User Interface Navigation Diagram & Screen Layout


Physical Architectural Design Specifications


These are the specifications of how the

system is going to operate in combination

with a third party web host. This also

describes how the system with work with

the support of a third party. This also

describes the architectural decisions that

have been made for the system.

Physical Architectural Design SpecificationsAdelante local network physical specifications

Adelante network PCs: Adelante’s local network is estimated to be a small network, with fewer than ten client computers connected at a time. Most consumer routing hardware will support up to 255 devices.

Adelante network-attached storage: Adelante will possess an on-premises data server which will contain backups of the Adelante website files, system files, and operations databases. This server will include a Microsoft Windows Server 2012 installation, a MySQL DBMS installation which contains identical data and configuration to the virtual environment, and all other core operating systems and networking software required for the server to back up and restore live environments.

Adelante network router: Adelante currently has a functional routing device on-site which should be sufficient for small-network routing.

Wide-area network physical specifications

Web- hosted virtual machine: A Microsoft Windows Server 2012 virtual machine will be created via cloud storage space. This virtual machine will have an installation of MySQL DBMS which will contain the operational copies of Adelante’s data. This virtual machine will also contain all necessary WordPress application files necessary to operate the site and application tasks for the system.

WordPress server: A WordPress server which houses the website code, application files, and configuration manager. The configuration manager will be accessible to Adelante staff members with the appropriate user login and/or permissions.

Site visitor physical specifications

User PC: The physical computer with which the user accesses the Adelante web solution. The solution will be compatible with a variety of operating system and web browser configurations.

User web-enabled mobile device: Some users may access the site via a mobile device. Mobile devices with browsers which are compatible with standard web applications will be able to view the site.


Physical Architectural Design


Design Procedures for Security Concerns & Non-Functional Requirements


Design Procedures for Security Concerns and Non-

Functional Requirements is the part of the system that

describes the areas that are non-action related. These

are what set the standards for the overall system. They

include standards such as password requirements for

users. The Security Concern section is what describes

the detective, corrective, and preventative controls. The

detective control finds any breach into the system. The

corrective control is how the system will fix the breach.

And the preventative control is what eliminates

possible breach/issues with the system.

Design Procedures for Security Concerns & Non-Functional Requirements

Password Requirements:

Password must contain at least 1 special character and must not contain a space or any of the following characters: >, <, &, ; or “

Password must contain at least 1 numeric character Password must contain at least 1 lower case alphabetic character Password must contain at least 1 upper case alphabetic character Password must not match or contain your user ID Password must not contain your first name or last name Password must be between 8 and 16 characters long Password must not be one of 24 previous passwords Password must not contain more than 4 identical characters

Security Requirements:

Detective (Being able to gain awareness of any issues)o User Authentication (login) – This is what will test to make sure the person signing in

is accessing the correct user file.o Antivirus Software – This is the software that will help to prevent cyber viruses and

worms from effecting the system. o Firewalls – This is the barriers that help to prevent “hackers” from accessing any

personal information that is saved in the system.o Hire outside source to test system – This is an option if funding is available to get

someone to try to access the system who is not authorized. Corrective (Fixing any situation that is not correct)

o Advance Security – Add in additional softwareo Add Firewall – Add additional barriers if neededo Hire outside source – Then they are responsible for any breach in the system

Preventative (Making sure that problems are corrected before they happen)o Proper Training o Updating Antivirus Software – This would include timely maintenance required from

the softwareo Updating Firewalls – This would include timely maintenance on the barrierso User Password change every 6 monthso Risk Assessments done periodically


Gantt Chart


A preliminary planning schedule for the sequencing of events displayed

against time. On the left of the chart is a list of the activities and along the

top is a suitable time scale. A bar represents each activity; the position and

length of the bar reflects the start date, duration, and end date of each

activity.

Gantt Chart


Elaboration Phase Prototypes


These represent the basic skeleton models of what each page

of the system will function as. These are strictly a skeleton

and will have graphics and pictures added during the

development stage of the process. Again, these only show the

basic functionality of the pages and will be much more

desirable to the eyes during the next phase of the process.

Elaboration Phase Prototypes


brookblackburn.files.wordpress.com€¦ · web viewin this use case, the actions will start with...

Documents