Pre Planning - Tohar-Ts/mishalvim GitHub Wiki

Use case Diagram

Use Case Diagram

Use case Templates

Name: “Fill out form”.

Brief Description: The guide or volunteer will select and open a form and will be able to fill out the various questions presented in the form with answers.

Actors: Volunteer, Guide.

Preconditions: The form must be open to the volunteer, and the user must be logged in.

Basic flow:

  1. User Selects a form.
  2. The system directs to the form page.
  3. User Selects a question text box.
  4. User Answers the question.
  5. The system saves temporary changes.
  6. The user finished answering all questions and clicks "send to guide".
  7. The System saves answers and sends the finished form to the guide.
  8. The system will redirect the User back to the view forms page.

Alternate Flows: In stage 5, If there are additional questions to answer or if the User wants to edit an answer - he returns to stage 2.
In stage 5, the user can click "save" instead, and then in stage 7, the System saves answers but does not send the finished form to guide.

Exception Flows: User closed the app without saving - all temporary changes will be deleted. If a Guide and a volunteer try to fill out the same form, the system will block the guide and pop out a relevant message.

Post Conditions: The User and the guide will be able to see the saved answers.

Name: “Manage Forms”.

Brief Description: The admin has the ability to manage forms, add new forms, and edit existing forms on the database.

Actors: Admin.

Preconditions: Admin must be logged in and in the “view forms” tab.

Basic flow:

  1. Admin clicks on the “Manage forms” button.
  2. The system shows 2 buttons: "edit form" and "add a new form".
  3. The admin chooses to add a new form.
  4. The system asks for the form name.
  5. Admin enters the form name.
  6. System saves and directs to an empty edit form page.
  7. Admin clicks on “add a question” and edits the question text.
  8. System saves and asks for the answer type - checkbox or text box.
  9. Admin chooses answer type.
  10. Admin clicks “save question”.
  11. Admin clicks “save form”.
  12. System saves and adds the new form to the database.
  13. The system will redirect the Admin back to the view forms page.

Alternate Flows:

In stage 3, if the admin chooses to edit an existent form:
a) The system will show a list of the existing forms.
b) The admin chooses 1 form to edit.
c) The system will show the chooses form in edit mode, with a button to add a new question.
d) If the admin chooses to add a new question- return to stage 6-9.
e) User can choose to press the "save changes" button and end the edit mode.
f) The system update the form details on the database.
g) Go back to stage 12.

In stage 9, if the admin chooses a checkbox answer, he can edit the answer text.
In stage 10 - If the admin wants to add another question - he can go back to stage 7.

Exception Flows:
Admin closed the app without saving:
if admin already entered the form name, all temporary changes will be saved in the new form and admin can access and edit the form again.
if admin did not enter a form name, all temporary changes will be deleted.

Post conditions: the admin can see the new form in the “view all forms” page.

Name: ”Manage volunteers”.

Brief Description: The guide can either add a new volunteer or edit an existing volunteer's details or delete the volunteer from the system.
Actors: Guide.

Preconditions: User is a Guide, and must be logged in.

Basic flow:

  1. The system shows the volunteers list with an edit button next to every name, and an “add a new volunteer” button.
  2. The guide chooses the “edit volunteer” button on a specific volunteer.
  3. The system redirects the guide to that specific volunteer page that has 3 buttons: “add access to form” , “edit volunteer detail”, “delete volunteer”.
  4. The guide chooses ”editing volunteer details”.
  5. The system redirects to the edit page.
  6. The guide edits the relevant details.
  7. The guide clicks the “save changes” button.
  8. The system will save the changes and redirect the guide back to the volunteers list view page.

Alternate Flows:
In stage 2, if the guide chooses to add a new volunteer instead:
a) The system redirects to an empty “edit volunteer details” page.
b) The Guide continues from stage 4 until stage 6.
c) In stage 7, The user clicks instead the “save volunteer” button.
d) In stage 8, The system adds a new volunteer user to the database with all the updated details, and redirects the guide back to the volunteers list view page.

In stage 4, if the guide chooses to delete a volunteer user:
a) The system pops out “are you sure?” message and an “ok” button or a “dismiss” button.
b) The Guide clicks the “ok” button.
c) The system deletes the volunteer user from the database.
Otherwise, if the guide chooses to give access to a new form for the volunteer, the guide will choose a form from a list to give the access and then press a button to confirm the change.

Exception Flows:
Guide closed the app without saving - all temporary changes will be deleted.
If the guide tries to save a new user details without entering the email or password, the system will pop out the message “please enter username and password” and won’t continue to save until these fields are valid.
Post conditions: All changes will be saved in the database and both admin and volunteer will see the update.

Requirements

Non-Functional:

  1. The volunteers can only access forms that the guide assigned to him.
  2. The font in the application will be large and in contrast colors.
  3. The application will boot up in 5 seconds.
  4. Admin can add, edit and view forms.
  5. Volunteers can fill out forms and review their old answers.
  6. Guide can fill a volunteer form on his behalf.

Functional:

  1. The system will support 3 user types: volunteers, guides and admin.
  2. The system will only support android version 7.0 (nougat) and above.
  3. The default language is Hebrew. No other languages will be supported.
  4. The system will support user identification via email and password.
  5. Only a guide can add new volunteers users and assign them a username and password.
  6. Only admin can add new guides user and assign them a username and password.

Personas

Who are we designing for?

Olaf:

He is a volunteer in the Mishlavim program.

He has some kind of mental disability (like autism). Therefore, he might have trouble with reading / writing.

He knows how to use a smartphone, but he feels more comfortable with simple and very clear apps.

His pain points are:

  • small buttons and items.
  • too much text.
  • He cannot see his previous answers and review them.

His Goals:

To be able to answer an accessible form alone and review his previous answers.

Anna:

She is a guide in the Mishlavim program.

She is responsible for a group of approximately 15 volunteers.

She wants to help her volunteers be as independent as possible.

She meets the volunteers regularly and checks their progress.

Her pain points are:

  • Hard to review previous forms that were filled
  • Difficulty keeping track of her volunteers progress
  • Has difficulty with technology

Elsa:

She is the admin of the Mishlavim program.

She manages both the volunteers and the guides.

She needs to be able to edit the forms and the lists of the guides and volunteers

Her pain points are:

  • must deal with many forms, volunteers and guiders.
  • cannot track changes easily and have no effective way to do it right now.
⚠️ **GitHub.com Fallback** ⚠️