Animal Adoption Compatibility System: A Solution to Reduce Animal Abandonment at NAU, Exams of Software Development

Download Animal Adoption Compatibility System: A Solution to Reduce Animal Abandonment at NAU and more Exams Software Development in PDF only on Docsity! Requirements Document Team Anubis December 6, 2016 Sponsor: Cindy Brown, Assistant Director of Development at NAU on behalf of the NAZ Animal Welfare Task Force Faculty Mentor: Steven Jacobs, Lecturer SICCS Frankie Berry Steven Gruenewald Marjorie Hahn Riley Shelton Matthew Siewierski Accepted as baseline requirements for the project: Sponsor:____________________________________________________ Date:_______________ Team: ____________________________________________________ Date:_______________ Table of Contents Introduction 2 Problem Statement 2 Solution Overview 4 Overall Solution 4 Data Processes 5 Software Usage 6 Project Requirements 7 Functional Requirements 7 Non-Functional Requirements 9 Environmental Requirements 10 Potential Risks 10 Project Plan 12 Conclusion 13 Definitions, Acronyms, and Abbreviations 14 References 16 1 ○ These concerns are evident: ■ Unwanted pets are abandoned or returned to the shelter ■ Animals are traumatized, making it difficult to readopt them ● Current System Issues [Figure 1]: ○ Only provides web links to other pet adoption organizations. ○ Selection is based on looks and breed of the animal. ○ No education system for the adopter. ○ No screening of pet adoption readiness. ● Obstacles for New System: ○ Maintainability for the task force. ○ Integration with current pet databases. 3. Solution Overview 3.1. Overall Solution The solution that we have proposed to fit the sponsor’s needs is a website application that will match people to shelter animals based on compatibility traits regarding lifestyle and personality. This will help ensure that people do not return pets to the shelter as often since they will be more likely to keep an animal with which they are matched. The system will match people to animals using a questionnaire that a person would fill out upon creating an account in the system. Furthermore, this website will also serve as an educational tool by informing the user about the responsibilities and costs of becoming a pet owner. This will help dissuade people who should not adopt an animal from becoming pet owners, and thus decrease the number of pets returned or abandoned. The following bullet points reveal specific features that the website will have so as to fulfill the requirements, separated by default, shelter and admin users: ● Administrators will be able to: ○ Add, remove, and edit pet information on the website. 4 ○ Modify the questionnaire that students will fill out to allow for future maintainability of the website. ○ Add new administrators to the system. ○ Generate reports on the system. ● Default users will be able to: ○ Create an account so that they can refer back to their pet matches. ○ Fill out a questionnaire so as to be matched to compatible animals. ○ View educational advice on adopting an animal. ○ Get redirected to rent-a-puppy or fostering events if adoption is not a suitable option. ● Shelters will be able to: ○ Add and modify one animal at a time into the system. ○ Import an excel sheet or CSV file into the system containing the information of the animals. ○ Connect with an existing database. ○ Get notifications when a default user has expressed interest with an animal, and will receive their corresponding report concerning if they have been deemed fit for adoption by the system. 3.2. Data Processes The system will utilize existing databases of animal information from sources such as PetPoint. PetPoint is a database management system that many shelters in northern Arizona use to store information that they have on animal rescues. [1] We are expecting to have a few, large imports of this data in the beginning so all the current shelter data does not have to be entered in manually. Once these larger imports are finished, administrators on our website will be able to maintain it on their own by modifying, removing, and adding animals to the system through the website itself. We will also be storing data including login information and animal match results. These will be generated by the system as users create their accounts and fill out 5 questionnaires. This way, users will be able to log back in and still see all of their animal matches. The main data transformations are illustrated in Figure 2. Default users and administrators creating new accounts will have their information saved in our database. Administrators adding, modifying, or removing animal data will alter the database accordingly. Administrators modifying the questionnaire that users fill out will alter what questions the student sees. Default users filling out this questionnaire will have their results stored in the database so that they can view their matches at any time. Figure 2: Data Flow 3.3. Software Usage This website will not necessarily change the way that the current adoption process works. Users will be matched to animals, and then it will be their responsibility to go to the shelter and complete the adoption themselves. Adoptions will not be handled through this website. Instead, what this system will change is the number of pets that end up getting returned to the shelter or abandoned because a student was not yet ready to adopt a pet, or adopted a pet that did not suit their lifestyle or personality. Originally, our sponsor wanted a mobile application that could help to match pets to users. However, we decided that this would not be the best option since, unless the user is fostering quite a few animals, adopting a pet is not something that the user will do very often. It seemed odd to us to develop this tool as a 6 4.1.4.4. The system will allow admin users to “delete” shelter users from the system. 4.1.4.5. The system will allow admin users to create admin users. 4.1.4.6. The system will allow admin users to “delete” admin users from the system. 4.1.4.7. The system will allow admin users to add additional fields to the profiles of the user when they first create the profile e.g. birth year, expected graduation date, etc. 4.1.4.8. The system will allow admin users to add additional fields to the profile for the animal. 4.1.4.9. The system will allow admin users to export reports generated by the system. 4.1.5. Regarding reports 4.1.5.1. The system will generate a report on the number of users that have created and completed a questionnaire within the system. 4.1.5.2. The system will generate a report on the student user once the questionnaire has been completed, regarding their potential as an adopter. It will send this report to the shelter if the user has expressed interest in an animal. 4.2. Non-Functional Requirements 4.2.1. The system will have a responsive interface that will size to the respective screen of the user. 4.2.2. The system will have a same or similar experience across all platforms. 4.2.3. The system will have an intuitive interface for creation of a profile and the completion of the different questionnaire. 4.2.4. The system will clearly show the user the potential matches. 4.2.5. The system will use a content management system. 4.2.6. The system will will be hosted by the content management system. 4.2.7. The system will be easily maintainable for a sponsor representative. 9 4.2.8. The system will have documentation regarding the maintenance of the system. 4.2.9. The system will be heavily commented by the development team. 4.3. Environmental Requirements 4.3.1. The system shall be capable of being viewed on the following web browsers: 4.3.1.1. Chrome 4.3.1.2. Safari 4.3.1.3. Mozilla Firefox 4.3.1.4. Microsoft Edge 4.3.1.5. Opera 4.3.2. The system shall connect to the [system name] servers to achieve functionality. 4.3.3. The system shall connect to the PetPoint servers to pull data about animals at the shelters. 4.3.4. The system shall require an internet connection to send and receive data. 4.3.5. The system shall require all users to login into their account in order to use the system. 4.3.6. The system shall be developed as a responsive web application. 5. Potential Risks The potential risks for this system are limited, though they still exist. Due to the nature of the sponsors, the key directive of the system is to educate students about the needs of adoption and the resulting responsibilities. Therefore, the utilization of the system is important as well as the stability of the system. Each of the risks are outlined in more detail below. 5.1. Not utilized 5.1.1. The primary risk for the system is that it is not utilized by the target market. This would impact the project goal significantly by leading to a 10 lack of education about the adoption process as well as the needs of the animal. Another potential risk surrounding the utilization of the system is that educational opportunities which are a main focus of the system are ignored by the user, similarly affecting the system. 5.1.2. A secondary risk concerning the utilization of the system is that the shelters may not update the information concerning their animals. This could lead to problems with the matching system. For example, a student could be matched to an animal has was already adopted but not removed from the system. This could both lead to a disappointment for the user, but makes the system seem ineffective. 5.2. Sponsor changes to system 5.2.1. During the maintainability period of the system after its deployment, the sponsor modifying the system in response to user dissatisfaction with the screening or matching questions could result in changes that have the potential to break the system. For example, the removal of a section of the questionnaire that is pivotal to the matching system may result in inaccurate results given to the student user, which may adversely affect the adoption of an animal. 5.3. Frameworks Failing 5.3.1. The risk of the frameworks failing could result in the entire site becoming inaccessible; additional development time would be necessary in this case. 5.4. Server Changes 5.4.1. The possibility of a server change is highly probable due to the system being developed in a non-permanent development environment. This could result in complications with the system as a whole, as there may be compatibility issues with the final server hosting option. 5.5. Security Breach 5.5.1. Like any system, although it is unlikely, the potential for a security break is there. Due to this unlikelihood, the impact of this risk is fairly low. In any case, the information we are gathering is still sensitive in nature, so there is a need for security. 5.6. Legal 5.6.1. Due to the nature of the system and the collection of personal information, there is the risk of legal action from the user. Another legal concern would 11 students to shelter animals based on compatibility traits so there is less of a chance the animal will be returned. This document defines the problem we are trying to solve, and provides an overview of our solution. It also details the requirements that must be met to complete this project. It also provides a schedule to follow to complete the milestones given in the project plan. 8. Definitions, Acronyms, and Abbreviations 8.1. System 8.1.1. The Northern Arizona Animal Welfare Taskforce pet adoption tool will be referred to as the system. 8.2. [System name] 8.2.1. This is a placeholder for the name of the system. This information has not been provided at the creation of this document. Once this information has been received from the sponsor(s) it will be updated accordingly. 8.3. Responsive Web Application 8.3.1. A web application that has an interface that changes according to the screen of the user. e.g. runs on a desktop, laptop, tablet, or smartphone. 8.4. Student User 8.4.1. A normal user that interacts with the system 8.4.2. Creates a profile 8.4.3. Views potential matches within the system 8.5. Admin User 8.5.1. A user that oversees the system, including updates and maintenance 8.5.2. They are able to add/remove student users 8.5.3. They are able to add/remove admin users 8.5.4. Generates reports 8.6. Digital Content 14 8.6.1. Digital content refers to the website and backend database for the system. 8.7. Content Management System 8.7.1. A Content Management System (CMS) is a computer application or program that supports the creation and modification of digital content using a simple interface to abstract away low level details unless required, usually supporting multiple users working in a collaborative environment. 8.8. Lifestyle questionnaire 8.8.1. A questionnaire given to the student user (pet adoptor) to assess their lifestyle, including but not limited to the following: 8.8.1.1. Housing type 8.8.1.2. Activity level 8.8.1.3. Family status 8.8.1.4. 5-year plan 8.8.1.5. Amount of free time 8.9. Personality questionnaire 8.9.1. A questionnaire given to the user to assess their personality, including but not limited to the following: 8.9.1.1. Introvert / extrovert 8.9.1.2. Responsible, mature adult 8.10. Shelter 8.10.1. An animal shelter or shelter is a place consisting of stray, lost, abandoned, or surrendered animals which are mostly dogs and cats. The shelter is the organization that puts animals up for matching in the system. 8.11. PetPoint 8.11.1. A shelter management service used by the larger shelters in northern Arizona. E.g. Coconino Humane Society, Second Chance Animal Shelter. 8.12. Framework 15 8.12.1. The underlying structure of the system. More specifically, the framework is the software that the system is designed in and around. 9. References 1. PetPoint. (n.d.). Retrieved November 20, 2016, from PetPoint website: https://www.petpoint.com/. 16