Software Requirements Specification s1

FRED Software Requirements Specification 0.1 April 28, 2016

FRED: Food, Resources, Expenses & Distribution MTM Program Product Software Requirements Specification

Version 0.1 April 28, 2016

Jordanelle Espinosa Jesse Lieberg Celia Schahczenski

Standard Version Number: 3.5 Standard Version Date: March 24, 2016

SRS Version History Version Date Authors Comment 0.1 March 28, Celia Schahczenski Contains information from the first three 2016 meetings.

Template Version History Version Date Authors Comment 3.0 120721 Frank Ackerman Initiating standards versions 3.1 120802 Frank Ackerman Added some non-functional requirements definitions: Adaptability, Enhanceability, and Portability 3.2 120825 Frank Ackerman Added usability comment 3.3 130117 Frank Ackerman Added general attributions 3.4 130306 Frank Ackerman Added a bit more explanatory text and final section 8.

036252c232095fc7e8a4e7651677c9a2.docx . page 1 of 33 This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA. FRED Software Requirements Specification 0.1 April 28, 2016

3.5 160215 Celia Schahczenski Rearranged, renamed items, removed Illustrative User Cases and increased some explanations.

Montana Tech Software Engineering Students: These Montana Tech Method software engineering standards encapsulate Dr. Ackerman’s decades of experience in the software industry, the IEEE software engineering standards, and many suggestions from various texts. They have gone through many revisions and additions over the last several years. They are part of your software engineering studies so that (1) you may have the experience of developing software to a standard (which you may find you need to do if you take a job that requires high reliability software), and so that (2) you will have the experience of developing high quality software. You are also invited to participate in the continuing evolution of these standards by studying them critically and making suggestions for their improvement and correction.

2 Version 1.0 FRED Software Requirements Specification 0.1 March 28, 2016

TABLE CONTENTS

036252c232095fc7e8a4e7651677c9a2.docx . page 3 of 33 This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA. 1 Introduction

This introduction consists of the purpose and scope for FRED: Food, Resources, Expenses, and Delivery. It also describes the purpose of contents of this document.

1.1Software Purpose and Scope The software system FRED, for Food, Resources, Expenses, and Delivery, is to facilitate and track non-financial operations of the Butte Emergency Food bank. Data includes client statistics on their start dates at the Food bank and demographics such as family size, veteran status, disabled veteran status, over the age of 55, children’s date of birth (DOB), income sources, rent cost disabilities, supplemental security income (SSI), and any food stamps the client receives.

The software should also allow historical data report generation, tracking of incoming food donations and outgoing food donations by donation source or receiving organization (such as Knights of Columbus community meals for outgoing donations), weight in pounds, and category of food if it is an incoming donation, tracking the food box size a client should be able to receive and at what date, and tracking how much food that went out to clients in various sizes of box. The FRED system will require login information in order to display anything inside of it.

The business objectives for this software are:  Increase recorded knowledge of food bank operations, food donations and food distribution  Increase historical data beyond the last box pickup and generate reports using this information  Provide increased security and comply with food bank business rules  Reduce duplicate data (multiple families at the same address, or one family with two addresses)  Reduce information sources (Excel spreadsheets, paper reports)

The Vision of the software is: For Butte Emergency Food Bank volunteers who process client in-take, receive food, and distribute food, FRED (Food, Resources, Expenses and Distribution) is a database application that provides information to better serve clients, report to donors and the advisory board. Unlike the current method with a database and multiple spreadsheets, FRED is a single point of access.

1.2Document Purpose and Contents This document is an attempt to document the characteristics of software to facilitate and track operations of the Butte Emergency Food Bank. It was developed by the students and instructor of the Montana Tech, spring 2016 class, Software Requirements and Specification (ESOF 328). It is meant to serve as an agreement between the Butte Emergency Food Bank and future software developers as to what FRED should do. This document should help the director and volunteers of the Butte Emergency Food Bank understand the proposed software, and help future developers of the software to know what to implement. Thanks goes to Kathy Griffith, Executive Director of the Butte Emergency Food Bank, Sharon Hanni and Darlene Smith, volunteers at the Food Bank, and Elissa Mitchell, member of the Butte Emergency Food Bank Board of Directors, for their help in developing this document.

The remainder of this document includes general factors of the software, use cases for it, functional and non-functional attributes and quality attributes, a sample user interface, future enhancement and references, definitions, acronyms and abbreviations and a data dictionary.

2 General Factors

The general factors for the software include how this system relates to other products or projects, the features which the system will perform, its planned environment, characteristics of users of the system, any dependencies it has, and any assumptions made of it.

2.1Product Perspective The FRED software will operate independently from any other software. While the Butte Emergency Food Bank tracks financial information in a Financial System (currently in QuickBooks) FRED will not communicate with that financial system in any way.

Three types of users will interact with FRED – the Executive Director of the Food bank, customer service and warehouse volunteers.

The FRED environment for the software is shown in the following figure: Figure 1: FRED Environment

2.2Product Features FRED has the major functions: Manage Donations, Handle Box Pickup, Manage Business Information and Manage Client Information.

Manage Donations:  “Record outgoing donations” when the Food bank gives out food to certain receiving organizations or people  “Record number of people served” when said receiving organizations report back to the Food bank administrator with numbers on how many people they served that month.  “Record incoming donations” when the Food bank receives food donations.

Handle Box Pickup:  “Verify box request” when someone calls into the Food bank and asks for a food box. The callers must be a client of the Food bank and not have gotten a box in the last 30 days.  “Generate daily box summary” after the deadline to call in has passed and the food boxes need to be prepared by warehouse volunteers for all clients who were verified for receiving a box.  “Record no-shows” after the Food bank has closed up shop for the day and some people who called in to request a box did not actually pick up the box. Recording those people as no-shows resets their date of pickup to the one it was previously, before it was set to today because they were expected to pick up a box today.

Manage Business Information:  “Generate history report” for a report on the clients of the Food bank and how much food the Food bank gave out, etc.  “Generate monthly report” for a report on the average monthly intake/output of the food of the Food bank.  “Generate other reports” for other specific reports, such as outgoing donations given out during a certain time frame. (The exact reports desired are still unknown.)  “Login to view client database” when someone with administrator privileges wishes to see or change details of a client’s account. Regular volunteers should not be able to see or change more than a few specific client details.

Manage Client Information:  “Delete client info” when a client has been inactive at the Food bank for 2 years or more.  “Create new client info” when someone who is not a client wishes to receive a food box.  “Modify/validate client info” when client info needs to be modified because it is incorrect or validated because the Food bank needs to “re-certify” a client.

The following figure shows the features of FRED. Figure 2 FRED Features

2.3Environmental Conditions The environment in which the software must operate has not yet been defined. (Discuss at April 22nd meeting.)

2.4User Characteristic The end-product customers should not be required to be “tech-savvy”. Users are likely to appreciate a simple, user-friendly interface. Customer service volunteers work at the front desk talking with clients and on the phone. The administrator (the Butte Emergency Food Bank Director, Kathy Griffith) can perform all activities of a customer service volunteer or warehouse volunteer as well as the financial functions outlined in the feature tree (Figure 2) under Manage Business Information and Manage Client Info. Warehouse volunteers accept donations, stock food and place items into boxes.

2.5Dependencies No external system dependencies are known.

2.6Business Rules Following is a list of Butte Emergency Food Bank policy information which will be needed when implementing developing this software.  Food bank clients are supposed to wait at least 30 days in between box pickups. Some exceptions may be made.  The Food bank deletes clients who haven’t picked up a box in two years or more.  When a person first registers with the Food bank, the person must come in to the Food bank in person with certain documents, such as proof of address and social security card.  When a person first registers with the Food bank, the person must give the Food bank this information: first and last name, phone number, social security number, address, SSN of everyone in the household, DOB of everyone in the household, the size of the household, total income of the household (calculated by summing each family member’s Supplementary Security Income (SSI), disability, temporary aid, Temporary Assistance for Needy Families (TANF), and any other additional income).  Once a year, the clients must re-certify with the Food bank, but this does not change their original registration date. (The re-certification date should be noted in the comments of a client’s profile.)  For families receiving size 1 box, all of this is done in the lobby. For families getting boxes of size 2 or 3, they first pick up what they want in the lobby, and then they drive around to pick up their box.  No two clients of the food bank should have the same SSN. Also, no SSN can appear within two families.  Also, no two clients should have the exact same address.  To pick up a box, clients bring in their client card (furnished by the food bank) along with a recent piece of mail, showing that they are still at the address which the Food bank has for them.  When the clients register with the Food bank, they complete a registration sheet.  Categories of incoming donations are: Dairy, Meat, Produce, Grocery, Bakery and Misc (diapers, shampoo, etc.).  Normal donations sources of incoming donations are: Safeway, Stokes, Town Talk Bakery, Walmart Thriftway, Mission Foods, Orowheat, Wheat Montana, Churches, CVS, Mission Foods, and then Misc.  Outgoing donations are recorded in pounds (no categories) and by who they go to.  Normal receiving organizations of outgoing donations include: Knights of Columbus, Anaconda Food Bank, Silver Bow Homes, Legion Oasis, After School, Volunteers, and Misc.  There are currently four paper forms used to record incoming and outgoing donations. Three of these forms have the same format. These forms are for a designated month. Each line contains a date, source and weight. 1. Garbage (outgoing) – broken eggs, etc. are weighed and recorded. 2. Outgoing – all outgoing items (as had been noted before, there is no category recorded). 3. Wheat Montana (incoming) – Wheat Montana wants a recording of what they have donated each month. In the future, other donors may want the same. Therefore, FRED should be able to create one of these reports for every donor. (For Wheat Montana the category is always “bakery” so, even though incoming donations are recorded, a category isn’t currently needed.) 4. The 4th form is for all other incoming donations. This form is for a month. Each line contains a date, donor/sources and a weight for each category. As reported earlier, the categories are dairy, meat, produce, grocery, bakery and misc.

2.7Assumptions No assumptions have been identified for this system.

3 Use Cases

The section describes actors and use cases of the system. An actor is a person or other entity external to the software system being specified who interacts with the system and performs use cases to accomplish tasks.

3.1Actors and Use Cases Overview The following specifies the actors in the system and the names of the use cases performed by those actors.

Actor Description of Actor Use Cases Customer Volunteer working at the Create new client information Service front desk talking with Delete client information Volunteer clients and on the phone. Find client information Generate daily box summary Modify, validate client information Record no-shows Verify box request Administrator Food bank director, Kathy Add, remove, edit donors Griffith. The administrator Add, remove, edit receiving organization can perform all activities of Change default box type a customer service Generate history report volunteer. Generate monthly report Generate other reports (community meals, donations in and out, etc.) Login to view client database Record number of people served

Warehouse Volunteers who accepts Record, remove, edit incoming donation Volunteer donations, stocks food and Record, remove, edit outgoing donation places items into boxes.

3.2Specific Use Cases The following provides details of each use case.

3.2.1 Add, remove, edit donors Created By: ESOF 328 Class Last Updated By: ESOF 328 Class Date Created: 04/23/2016 Date Last Updated: 04/23/2016

Actors: Administrator Trigger: A new donor is to be added to the system, a donor name is to be edited, or a donor is to be removed from the system. Preconditions: None Postconditions: The donor has been added, edited or deleted. Story The user sees a list of all donors and has the option to add a new donor, edit an existing donor, or remove a donor.

If user adds a donor, the name of the donor is entered into the system.

If the user edits a donor, the name is changed.

If the user attempts to delete a donor for which donations have been recorded, the system shall warn the user that information will be lost, and give the user a chance to not delete the donor. Business Rules: Special Requirements: Assumptions: Notes and Issues:

3.2.2 Add, remove, edit receiving organization Created By: ESOF 328 Class Last Updated By: ESOF 328 Class Date Created: 04/23/2016 Date Last Updated: 04/23/2016

Actors: Administrator Trigger: A new receiving organization is to be added to the system, a receiving organization name is to be edited, or an organization is to be removed from the system. Preconditions: None Postconditions: The receiving organization has been added, edited or deleted. Story The user sees a list of all receiving organizations and has the option to add a new organization, edit an existing organization, or remove an organization.

If user adds an organization, the name of the organization is entered into the system.

If the user edits an organization, the name is changed.

If the user attempts to delete an organization which has received items from the food bank, the system shall warn the user that information will be lost, and allow the user to not delete the organization.

Business Rules: Special Requirements: Assumptions: Notes and Issues:

3.2.3 Change default box type Created By: ESOF 328 Class Last Updated By: ESOF 328 Class Date Created: 04/23/2016 Date Last Updated: 04/23/2016

Actors: Administrator Trigger: The default box type is to be changed Preconditions: None Postconditions: The default box type is changed. Story The Thanksgiving season is starting (around October) or ending (sometime in November), or the Christmas season is starting (sometime in November) or ending (sometime in December), and the default box type is to be changed. Business Rules: Default box types are: regular, Thanksgiving (when the boxes are considerably heavier than regular) or Christmas (when the boxes are heavier than regular) Special Requirements: Assumptions: With the new box types will come new weights for #1, #2 and #3 boxes. These weights will be needed for the reports. Notes and Issues:

3.2.4 Create new client information Created By: Jordanelle (Nikki) Last Updated By: ESOF 328 Class Espinosa Date Created: 2/10/2016 Date Last Updated: 04/23/2016

Actors: Customer Service Volunteer Description: User enters into the system the information of a new client who will be receiving food bank boxes. Trigger: A client comes in with the proper documents and asks to be registered with the food bank. Preconditions: None Postconditions: System contains the client’s information Normal Flow: 1.0 Client comes in to request being registered 1. User enters SSN of client and SSN is not already in the system 2. User enters address of client and address is not already in the system 3. User enters: name (first and last), phone number, date of birth, and sources of income (salary, food stamps, ssi, tanfa and other). 4. For each person who lives at the address: user enters the name (first and last), SSN, date or year of birth. 5. System displays the total income for the family. 6. User saves info Alternative Flows: 1.1 The client SSN is already in system (branch at step 1) 1. Client SSN is already in system. 2. System informs user SSN is already used 3. Go to “Modify/validate client info” use case

1.2 The client address is already in system (branch at step 2) 1. Client address is already in system. 2. System informs user address is already used 3. Go to “Modify/validate client info” use case 1.3 The client is homeless (branch at step 2) 1. The user enters an address of “homeless” in the system. 2. Continue with Step 3

1.4 The potential client’s income is too high (branch at step 5) 1. The family’s income is too high for them to be a client of the food bank. (This must be determined by the user who is at the time entering in the client’s info. The user must compare the client’s total income to the sheet that states the income limit for receiving food boxes, which is a federally imposed limit that changes every year and would be difficult to have the FRED system track.) 2. User exits or an administrator makes an exception and overrides the system to allow the user to save the client info into the system. Exceptions: 1.0.E.1 A necessary field is left blank when the user enters the client information into the system. (Branch at step 5.) 1. System informs user what necessary fields are missing. 2. Return to step 4. Includes: “Find client info” Priority: High Frequency of Use: 5 times a month Business Rules: Necessary information: name, address, SSN, phone number, and number of people in the family. For each person in the family, the SSN and date of birth are needed. Also, income information for the family is needed. This includes Supplementary Security Income (SSI), disability, temporary aid, tanf and any other additional income.

There is a maximum allowable income defined by the government. If the family has an income that exceeds the given amount for their family size, they ordinarily aren't allowed to use the services of the food bank. Sometimes Kathy overrides this if there are extenuating circumstances.

The date that the new client information was put into the system is called the registration date. This date must not be allowed to change. Re-certification should occur every year but that doesn’t affect the registration date. Re-certification will be handled in the “Modify client information info” use case. The re-certification date is noted in the comments.

Special Requirements: When a new client is entered into the system, the system should generate a unique client number. New client numbers must be different than the client number for all clients which are already in the system. Client numbers of existing clients should not need to change.

Homeless addresses must be handled by the system. In general, addresses should be unique, using homeless 1, homeless 2, homeless 3, etc. was suggested. Along the same line, sometimes two different clients are living at the same address. The second may be living in a camper behind the other’s house. In this case a 2 can be appended to the address of the second family living at the address.

In some cases a date of birth will not be known. The system must be able to function correctly when only knowing the year of birth.

Assumptions: Notes and Issues:

3.2.5 Delete client information Created By: Celia Schahczenski Last Updated By: ESOF 328 Class Nikki Espinosa Date Created: 3/26/2016 Date Last Updated: 04/12/2016 4/6/2016

Actors: Customer Service Volunteer Trigger: A client has not picked up a box for two years or more, a client moves out of Butte, or a client is to be deleted from the system for some other reason. Preconditions: Client information must have been located in the system Postconditions: All of that client’s profile information is gone from the system, but not the information that added to the total amount of food given out during the time the client was actively receiving boxes. Story User receives a notification from the system saying that a certain client has been inactive for two years or more. The user informs the administrator so that the administrator can look at the notifications and delete the clients that need to be deleted. The administrator first logs into the client database and then searches for the client, and finding the client, deletes the client from the database. Business Rules: BR-2 – The Food Bank deletes clients who haven’t picked up a box in two years or more. Special Requirements: Assumptions: Can we assume that old reports will not be regenerated? Notes and Issues: Do they really want to remove all information about the client? This could change the reports on who was served.

3.2.6 Find client information Created By: Celia Schahczenski Last Updated By: ESOF 328 Class Date Created: 3/4/2016 Date Last Updated: 04/23/2016

Actors: Customer Service Volunteer / Administrator Description: User finds a client who is registered in the system Trigger: User wants to view the information about a client, or wants to see if a SSN or address is already used. Preconditions: None Postconditions: None Normal Flow: 1.0 User searches for information about a client 1. User enters a search criteria a. For Customer Service Volunteer searches can be by ClientID, last name or SSN. b. For Administrator, in addition to the above, searchers can be by address or phone number. 2. System either displays information about a single registered client, or, if multiple clients matched the search criteria, displays a list of those clients. In the second case, the client ID, name, address and phone number of all clients who match the criteria are displayed. 3. If multiple clients met the search criteria, the user selects the clients whose information is to be displayed. 4. System displays information about that single registered client. Alternative Flows: 1.1 Client not found in the system (branch after step 1) 1. No client is found whose information matches the search criteria. 2. System displays a message telling that there is no client that matches the search criteria. 3. User is given a chance to search another way Exceptions: None

Includes: None Priority: High Frequency of Use: 40 times daily, M-F Business Rules: SSNs should not be repeated within the system. If a client is registered with a SSN, and that SSN was already in the system as a family member, that family member must be removed.

Address shall not be repeated in the system (addresses are repeated for old information, but should not be for new information) Special Requirements: Addresses are not currently standardized. The system needs to allow non-standardized addresses to be in the old data, but new data should only have standardized addresses Assumptions: None Notes and Issues: None 3.2.7 Generate daily box summary Created By: Celia Schahczenski Last Updated By: ESOF 328 Class Date Created: 3/26/2016 Date Last Updated: 04/12/2016

Actors: Customer Service Volunteer Trigger: No more food requests will be taken for the day and a daily box summary is needed Preconditions: None Postconditions: None Story User requests to generate the daily box summary. The system generates a list of all clients who are expected to pick up boxes on this day. Information includes: box size, client id, counts of the number of adults, children and people, the name, phone number and last 4 digits of the SSN. The information is displayed onscreen and an option is available to print the list. Business Rules: Families receiving size 1 box pick the box up in the lobby. Families drive around to the warehouse for sizes 2 and 3. Special Requirements: Daily box summary should include recipient’s phone number. Assumptions: Notes and Issues: Clients sign a page when picking up a box. The page singed is the back of their original registration form.

3.2.8 Generate history report Created By: Celia Schahczenski Last Updated By: ESOF 328 Class Date Created: 3/26/2016 Date Last Updated: 04/12/2016

Actors: Administrator Trigger: The administrator desires to see a report of the historical goings-on of the Food Bank, usually in order to report to the Board. Preconditions: None Postconditions: None Story User requests to generate a history report. The system request a start and finish date. For each month within the start and finish dates, inclusive, the system generates: the month and year, number of adults, community means, and children served, the total, how many #1, 32 and #3 orders (boxes) went out, the total number of orders, the total weight and the total value. Business Rules: Currently 1 pound of food corresponds to $1.75 of value. Special Requirements: The format of the report will be similar to that of the example form given by Kathy Griffith.

Currently changes to family composition are not always recorded when they occur, so that reports are generated accurately. For example, a family may have been receiving #3 boxes all the way until November, when their composition changes and they begin receiving #2 boxes. The statistics reports should show what was actually given. Assumptions: Notes and Issues: Is this the statistics report? Should the start and finish simply be years?

3.2.9 Generate monthly report Created By: Celia Schahczenski Last Updated By: ESOF 328 Class Date Created: 3/26/2016 Date Last Updated: 04/12/2016

Actors: Administrator Trigger: User wants to see the amount of assistance provided in a month Preconditions: None Postconditions: None Story User requests to generate a monthly report telling the number of each type of box distributed in that month, along with characteristics of the families served. Report includes: number of adults, children, community meals, orders (divided between #1, #2 and #3, weight and value), along with other miscellaneous statistics. Business Rules: 1 pound corresponds to $1.75 of value. Special Requirements: Assumptions: Notes and Issues: The purchases on this report comes from Quickbooks which will not be part of this system. There is also a contribution fields.

Reports are needed for the board and for Montana Food Bank

3.2.10 Generate other reports Created By: Celia Schahczenski Last Updated By: ESOF 328 Class Date Created: 3/26/2016 Date Last Updated: 04/12/2016

Actors: Administrator Trigger: User wants to see other reports Preconditions: None Postconditions: None Story User requests to generate other reports. Business Rules: Special Requirements: Assumptions: Notes and Issues: We need to find out what other reports are needed.

Reports are needed for the board and for Montana Food Bank 3.2.11 Login to view client database Created By: Celia Schahczenski Last Updated By: ESOF 328 Class Date Created: 3/26/2016 Date Last Updated: 04/12/2016

Actors: Administrator Trigger: User wants access to the entire database Preconditions: None Postconditions: User has access to entire database Story Only by logging into the system can a user see and edit records in the database. Business Rules: Special Requirements: After 3 minutes of inactivity, the system will automatically exit the login state. Assumptions: Password will be hard coded, unencrypted, into the software.

This would be used when: 1. The administrator wants to modify part of the client’s information (removing a member, changing address, etc.) 2. The administrator wants to delete a client 3. The administrator wants to look at details of a client that do not show up to a regular front desk volunteer. Notes and Issues: This special login is to allow the administrator, Kathy, to change any client information, but not allow any front desk person to make changes. Instead, regular volunteers can only change a few things from the page of the system they see.

3.2.12 Modify, validate client info Created By: Jesse Lieberg Last Updated By: ESOF 328 Class Date Created: 2/9/2016 Date Last Updated: 04/12/2016

Actors: Customer Service Volunteer Description: User modifies existing client information Trigger: Realization that client information isn’t current in the database Preconditions: 1. None Postconditions: 1. Client’s information has been updated Normal Flow: 1.0 Client’s information is updated in the system 1. User searches to find current client 2. Information is updated concerning that client 3. A message is displayed confirming the update Alternative Flows: 1.1 Client not found in the system (branch at step 1) 1. Person is informed that they are not in the system. (Possibly use “Create new client info” use case to be added to the system. Exceptions: None Includes: “Find client info” Priority: High Frequency of Use: 1 time M-F Business Rules: The date that a client is registered in the system is fixed. It is not allowed to change. Clients re-certify in the system, but that is recorded elsewhere (currently, in the comments of that client) Special Requirements: Client id and registration date may not be changed. Assumptions: Notes and Issues:

3.2.13 Record, remove, edit incoming donation Created By: Jesse Lieberg Last Updated By: ESOF 328 Class Date Created: 3/8/2016 Date Last Updated: 04/23/2016

Actors: Warehouse Volunteer Trigger: An incoming donation is to be added /edited or deleted from the system for the current day Preconditions: For adding donations, the incoming donation must be weighed. The donation source and type must be known. For edits or deletions, the donation must already be in the system. Postconditions: Incoming donation is recorded, edited or deleted in the system Story Warehouse volunteer sees all the incoming donations which have been entered for the day.

For an addition the user selects donor, selects the type of donation and enters the weight in pounds. Each of these fields are editable. Also any donation from the day can be deleted. Donations from previous days can be seen, but not changed.

Note that the donor, type and weight will not necessarily be unique for the day. Business Rules: Normal Donors are: Safeway, Stokes, Town Talk Bakery, Walmart Thriftway, Mission Foods, Orowheat, Wheat Montana, Churches, CVS, Mission Foods, and then Misc. (It was later decided that it must be possible to add new donors.)

The type, weight and source will be recorded. Types are: Dairy, Meat, Produce, Grocery, Bakery and Misc (diapers, shampoo, etc.) No interface is needed for changing these types.

Special Requirements: Assumptions: Notes and Issues:

3.2.14 Record, remove, edit outgoing donation Created By: Jesse Lieberg Last Updated By: ESOF 328 Class Date Created: 3/8/2016 Date Last Updated: 04/23/2016

Actors: Warehouse Volunteer Trigger: An outgoing donation is to be recorded /edited or deleted from the system for the current day because a receiving organization is to be given some food. Preconditions: For adding donations, the outgoing donation must be weighed. The receiving organization must be known. For edits or deletions, the outgoing donation must already be in the system Postconditions: Outgoing donation is recorded, edited or deleted in the system Story Warehouse volunteer sees all the outgoing donations which have been entered for the day (which will often be none).

For an addition the user selects receiving organization and enters the weight in pounds. Both of these fields are editable. Also any outgoing donation from the day can be deleted. Donations from previous days can be seen, but not changed.

Business Rules: Receiving organizations include: Knights of Columbus, Anaconda Food Bank, Silver Bow Homes, Legion Oasis After School, Volunteers, Garbage and Misc.

Sometimes volunteers take items home. These count as outgoing donations and the receiving organization is “Volunteers”

Special Requirements: Assumptions: These items are always perishables and their type isn’t kept. Notes and Issues:

3.2.15 Record no-shows Created By: Celia Schahczenski Last Updated By: ESOF 328 Class Date Created: 3/26/2016 Date Last Updated: 04/12/2016

Actors: Customer Service Volunteer Trigger: User doesn’t expect any more box pick-ups and wants to record any families which did did not pick-up their box Preconditions: Client requested to pick-up a box on the current day Postconditions: Every no-show’s “Last box pickup date” is reset from the current date to value it had before the volunteer put that client down for a box pickup on the current date. Story The user tells the system which clients, out of all the clients that were verified for a box pickup on the current date, did not pick up their boxes. The system resets the “Last box pickup date” for those no-show clients from the current date to value it had before the volunteer put that client down for a pickup on the current date. Business Rules: Special Requirements: Assumptions: The person is free to request another box for this month at a later date. Notes and Issues:

3.2.16 Record number of people served Created By: Celia Schahczenski Last Updated By: ESOF 328 Class Date Created: 3/26/2016 Date Last Updated: 04/12/2016

Actors: Administrator Trigger: One of the “receiving organizations” for the Food Bank’s outgoing donations reports back to the Director of the Food Bank with info on how many people they served. Preconditions: FRED has a record of an outgoing donation going this specific receiving organization that is reporting back. Postconditions: The system has a value for the number of people served this month, but the value has now been incremented by the amount reported back by the receiving organization. Story The user received a number for the number of people served by a certain receiving organization. The user checks to make sure that an outgoing donation was made to this receiving organization, and then for that organization for this month, the user enters in the amount of people served. The system keeps a running log of organization/amount of people served and a total amount of people served for that month. Business Rules: The number of meals served is considered equal to the number of people served. Special Requirements: Assumptions: Notes and Issues: Currently recording the number of people served is only for the community meals and not for the backpack program. However in the future maybe recording people served with the backpack program should be included.

3.2.17 Verify box request Created By: Jesse Lieberg Last Updated By: ESOF 328 Class Date Created: 2/25/2016 Date Last Updated: 04/12/2016

Actors: Customer Service Volunteer Description: User handles a request for a box of food Trigger: Person calls to request a box pickup Preconditions: None Postconditions: If box pickup is allowed, pickup is recorded in the system Normal Flow: 1.0 Box pickup is requested, verified and recorded 1. User answers call and uses system to see if caller is a client of the food bank. 2. Caller is a client and has not receive a box in the last 30 days 3. Box pickup of the default type for this client is recorded in the system

Alternative Flows: 1.1 Caller is not a client of the food bank (branch after step 1) 1. Caller is informed that they must register as a client of the food bank. 2. Go to “Create new client info” use case

1.2 Caller is not a client of the food bank, but may receive an emergency box (branch after step 1) 1. User determines that caller warrants an emergency box 2. User determines the size of box to be received 3. User records that size of box, of the appropriate type, as given to a special “dummy” client which is in the system for this purpose

1.3 Information is outdated (branch after step 1) 1. Caller provides information that must be updated in the system 2. Go to “Modify/validate client info” use case before continuing with Step 2.

1.4 Insufficient time has passed for a client to get another box (branches after step 2) 1. System displays date of last box pickup. 2. Either caller is told to call back when a box may be picked up, or the system is overridden, so that the caller can receive a box

1.5 User changes the type of box from the default type (branches after step 3) 1. User changes the default type of box 2. Return to step 3.

Exceptions: Includes: “Find client info” Priority: High Frequency of Use: 30 times daily, M-F Business Rules: Client can pick up a box each 30 days. To pick up a box, they bring in their client card (furnished by the food bank) along with a recent piece of mail, showing that they are still at the address which the food bank has for them. In addition to boxes being of size #1, #2 or #3, as determined by the system, boxes can be regular, Thanksgiving or Christmas.

Special Requirements: Dummy clients need to be created in the system Assumptions: Notes and Issues:

4 Requirements Models

No requirements models were developed for this system.

5 Specific Requirements

This sections details all requirements for the software. The subsection “Functional Requirements” gives behavioral requirements for the system. Subsection “Non- Functional Requirements” gives system constraints and external interface requirements. The final subsection “Quality Attributes” gives system characteristics such usability, performance and security.

5.1Functional Requirements The following details the requirements for the behavior of the software.

5.1.1 Change default box type The Administrator shall be able to change the current default type of box for box requests. The optional box types are: regular, Thanksgiving, and Christmas. Rationale: The system’s generated reports include weight of boxes. The boxes during these special periods are larger than regularly, and to keep accurate information this information must be recorded. Priority: TBD

5.1.2 Delete incoming donation A warehouse volunteer shall be able to delete an incoming donation which was recorded on the current day. The system shall ask for confirmation from the user before permanently deleting the data. Rationale: A donation consisting of several categories of items may come in at the same time. Each of these must be weighed separately. It is possible to accidentally record an item twice, necessitating the need to remove a recently recorded item. Priority: TBD

5.1.3 Delete outgoing donation A warehouse volunteer shall be able to delete an outgoing donation which was recorded on the current day. The system shall ask for confirmation from the user before permanently deleting the data. Rationale: It is possible to accidentally record a donation twice, necessitating the need to remove a recently recorded item. Priority: TBD

5.1.4 Find client info after logging in as an administrator When a user has logged in as an administrator, the system shall allow a user to search the client database on any category of client information (including address and phone number). Rationale: It is acceptable and preferable for the administrator to have special privileges when it comes to searching the client database because the administrator is the most trusted category of user and should not be restricted from seeing all client info and searching on any category of search term. Priority: TBD

5.1.5 Find client info without logging in When a Customer Service Volunteer indicates that he/she wants to search for a client, the system shall allow the user to enter a search term in the category of last name, SSN, or client ID and return a list of results to be displayed onscreen. Rationale: The Customer Service Volunteers, who do not have login credentials, should be able to find a client based on just these few categories of search terms so that they cannot search the system invasively for neighbors or friends. Priority: TBD

5.1.6 Generate daily box report The Customer Service Volunteer shall be able to print a report of the daily box requests. Rationale: The Warehouse and other volunteers need a way to verify who is to be receiving a box for the day. Priority: Imperative

5.1.7 Generate Monthly Donor Report The system shall enable an Administrator to generate a monthly donor report. The system shall facilitate the user selecting a donor from the system, along with a month and year. The report header shall include the name of the food bank, the name of the donor and the month and year of the report. The system shall list, in chronological order, the date, type and weight of all donations from that donor received by the food bank during the given month and year. Rationale: Currently Wheat Montana asks for this report but no other donors. In the future it is likely that other donors will want this. (If it is decided that this is gold plating, the current method of keeping information for Wheat Montana shall be continued.) Priority: Low

5.1.8 Generate reports When logged in, the Administrator shall be able to generate reports. Rationale: In general Customer Service Volunteers should not be able to generate reports. However, the Administrator will want to be able to generate reports. Priority: TBD 5.1.9 Log inactive clients The system shall keep information on clients that have been deleted from the system. Rationale: The food bank wants to keep historical information. It is undecided exactly what that information should be. Priority: TBD

5.1.10 Login A single login shall be available for the Administrator. The username and password for this login can be hard coded into the system. Rationale: The Administrator needs to be able to perform functions which no one else is able to. A login will enable this. Priority: TBD

5.1.11 Manage client information When logged in, the Administrator shall be able to remove clients from the database or to change any client information within the database. Rationale: In general, Customer Service Volunteers should not be able to remove clients from the database or edit certain client fields. However, the Administrator should be able to remove a client from the database if the client has not received a box for two or more years. Also, information may have been entered incorrectly, and an Administrator should be able to correct information. Priority: TBD

5.1.12 Notify user of expired clients The Administrator shall be able to generate a list of clients who are active in the system but having picked up a box for two or more years. Rationale: It would time consuming to search through the entire client database looking for any clients whose last pickup date was two or more years ago. The system should make it easier for the Administrator to find these clients. Priority: TBD

5.1.13 No duplicated SSN Social security numbers shall not be duplicated in the system, either as primary clients or as family members of a primary client. Rationale: Some clients may want to abuse the Food Bank by receiving more boxes of food that is allowed. This rule makes it easier for Customer Service Volunteers to avoid such fraud. Priority: TBD

5.1.14 Record incoming donation A warehouse volunteers shall be able to record incoming donations, consisting of the date, donor, category and weight in pounds of the donation. Categories will be: Dairy, Meat, Produce, Grocery, Bakery and Misc (diapers, shampoo, etc.). Donors will be: Safeway, Stokes, Town Talk Bakery, Walmart Thriftway, Mission Foods, Orowheat, Wheat Montana, Churches, CVS, Mission Foods, and then Misc. Rationale: An important operation of the food bank is to receive and distribute food donations from donor organizations. Priority: TBD

5.1.15 Record no-shows A Customer Service Volunteer shall be able to record when a box request was not fulfilled. In this case, the system shall roll back the client’s date of last box received to the last reception of the client. Rationale: The system tracks how long it has been since the last verified pickup, if this information is incorrect it cannot detect when the correct amount of time has passed since the last pickup. Priority: TBD

5.1.16 Record outgoing donation Warehouse volunteers shall be able to record outgoing donations, consisting of the date, receiving organization and weight in pounds of the donation. Category does not need to be recorded for an outgoing donation. Receiving organizations will be: Knights of Columbus, Anaconda Food Bank, Silver Bow Homes, Legion Oasis After School, Volunteers, Misc. Rationale: An important operation of the food bank is to distribute perishable food to community organizations.

5.1.17 Standardized addresses Client addresses shall be standardized within the system so that duplication will be eliminated. The only address that is allowed to be duplicated is the special case for homeless clients, in which case the address shall be recorded as “homeless.” When multiple clients are homeless, a number shall be appended “homeless 2”. Rationale: Currently, more than one customer may be at the same address and this makes fraud more likely. For example, apartment numbers weren’t always recorded in the system so it appears that many clients are living at the same address. Priority: TBD

5.2Non-Functional Requirements This section gives system constraints and external interface requirements of the system.

5.2.1 Cost (CT)

5.2.2 Deliverable Items, Dates and Conditions (DD) 5.2.3 Delivery Operations (OP)

5.2.4 Delivery Site Environment (DSE)

5.2.5 Design Constraints (DC)

5.2.6 Development Environment (DE)

5.2.7 External Interface Hardware (EHW)

5.2.8 External Interface Software (ESW)

5.2.9 External Communications (ECM)

5.2.10 Standards (ST)

5.2.11 V&V Activities (VV)

5.3Quality Attributes This sections describes characteristics which need to permeate the software.

5.3.1 Adaptability (AD)

5.3.2 Availability (AL)

5.3.3 Enhanceability/Extendibility (EN)

5.3.4 Human Factors (HF)

5.3.5 Integrity (IN)

IN01: Reports generated by the system shall accurately reflect family composition (number of members, number of members six and younger, number of members who are children, number of members who are 55 and older, whether or not a member of the household is employed, whether or not the client is new and family AFDC, Social Security, Food stamp and other income) at the time the box was distributed, regardless of later changes to client family composition. Note: It appears that this only applies to the Monthly Expenditure and Statistics report.

5.3.6 Maintainability (ML)

5.3.7 Performance (PR)

5.3.8 Portability (PT)

5.3.9 Reliability (RL)

5.3.10 Usability (UB)

UB01: Anyone aged 18 to 75 must be able to enter in 5 incoming donations and 5 outgoing donations within 20 minutes with no prior instruction and no more than 1 mistake entered into the system’s state and no mistakes entered into the system’s state that the user could not fix without help.

5.3.11 Security (SC)

SC01: The user interface shall not show the contents of the database to volunteers. Instead, volunteers shall see and operate from one page.

SC01: No users of the system, aside from a user logged in as an Administrator, shall be allowed to freely peruse client information. For users not logged in as an Administrator, the system shall only show search results based on the following search criteria: client ID, last name or SSN. Auto-completion on such searches may be allowed. Wild-card characters shall not be allowed.

6 Sample User Interface

Ideas for the user interface include having different colored background for the page for recording incoming donations and the page for recording outgoing donations.

Administrative functions such as “Record number of people served” should be kept separate from other types of functions, such as those performed by warehouse volunteers. There could be three tabs, for instance: Administrator, Front Desk, and Warehouse.

The following shows portions of a possible user interface for the system.

Screens for Warehouse Volunteers - Record/edit/delete incoming and outgoing donations.

Screen for Administrator - Record number of people served. (Suggestion: use the same format as above, so that what was already recorded is viewable too, although in reverse chronological order.)

7 Future Enhancements

Tracking inventory could be useful. Originally the following “wish list” was developed:  How many boxes are left of cheese, toilet paper, etc.  What needs to be ordered next month even if no “bargain” (when a bargain occurs items are often purchased anticipating future need)  How much is going in and out on average each month

It was realized that this would require entering purchases, along with what is contained in the outgoing boxes. This was seen to be too burdensome currently, but may be reconsidered in the future.

Also, there was another feature the clients brought up but decided against putting the software because it would be too complicated. At some point, it might be nice to have the system restrict the days or weeks of the month (say, the date the client registered on, or the first week of the month, for example) that a client is allowed to call in for a box. This restriction might help to even the flow of business, so that things never get too busy.

8 References, Definitions, Acronyms, and Abbreviations

This section contains references to information which may be useful in understanding this SRS. In addition, definitions, acronyms and abbreviation used in the SRS are included. The final subsection defines known data elements which are likely to be part of the final system. 8.1References No references particular to this system have been identified.

8.2Definitions No definitions particular to this system have been defined.

8.3Acronyms and Abbreviations DB Database FRED Food Resources, Expenses, & Delivery DOB Date of Birth SSI Supplemental Security Income TANF Temporary Assistance for Needy Families

8.4Data Dictionary When known, data elements in the system are defined below. It is expected that the design and implementation of the system will use these names.

Data Description Composition or Length Values Element Data Type Client Info Information kept Identifier, first and about a client last name, address, phone, FSIncome, SSIncome, AFDCIncome, TANFIncome, otherIncome, information on other members of the family

Client id Unique identifier TBD System must of a client generate Client name Name of the First and last name Length primary person of client TBD registering at the food bank Address Address of the Length These should be primary person TBD unique in the registering at the software food bank Rent cost Mentioned on Feb. 19th as information that is wanted, but is not always gotten Type Type of incoming Enumeration type: TBD TBD donation Dairy, Meat, Produce, Grocery, Bakery and Misc (diapers, shampoo, etc.)

Organization Characters TBD Safeway, Donor which donates to Stokes, Town the food bank Talk Bakery, Walmart Thriftway, Mission Foods, Orowheat, Wheat Montana, Churches, CVS, Mission Foods, and then Misc Receiving Organization Characters TBD Knights of organiza- which receives Columbus, tion donations to the Anaconda Food food bank Bank, Silver Bow Homes, Legion Oasis After School, Volunteers, Misc.