Requirements
Project Background
The International Federation of Red Cross (IFRC) helps National Soceities apply for funding to deal with disaster events by filling out the Disaster Relief Emergency Fund (DREF) Form. The existing features on the IFRC's GO platform helps with automating data entry and collection for country specific information from the DREF forms filled out by Host Societies. However, there is no existing mechanism to extract relevant information from DREF Appeals already made in the past, specifically for Admin 1 and Admin 2 related information [Admin 0, 1 and 2 represent geogrpahical administrative units. For e.g.: In the case of the USA, USA would be Admin 0, California would be an exmaple of Admin 1 and Butte County would be an example of Admin 2]. It would take a significant amount of time and manual labour to extract and tabulate relevant information from sucha a large collection of documents. As such, it is diffcult to form meaningful historic trends about disaster events that would help paint a better picture for the IFRC and allow them to allocate funding in a faster and more efficient manner.
Project Goals
Our project goal is to develop a easy-to-learn, efficient and user-friendly tool that allows the IFRC to extract required information from documents to help form meaningful historic trends and make funding decisions.
It must be a stand-alone tool that is simple to navigate with minimal effort and must provide usable results.
The tool allows users to upload a file and extract certain details from it and stores the extracted information in a PostgreSQL database that the IFRC can view and manage.
The extracted information can be visualized at various stages of use, the first instance being a page that displays extracted information after the necessary data enrichments are done and the second instance being the database itself, which is updated after every use of the tool.
Gathering of Requirements
Gathering requirements was part of the Human Computer Interaction (HCI) component of this module and formed the first phase of our project.
The 6 usability goals as deined by HCI are effectiveness, efficiency, safety, utility, learnability and memorability. Centering the development of our project around these 6 goals has helped us develop a tool that is focused on the end-user's experience.
In order to gather the requirements of this project, we needed to interview different categories of end-users. Due to the fact that our clients are centered in Geneva, we decided to conduct interviews on Microsoft Teams that followed a semi-structured approach as well as collect responses from questionnaires using Microsoft Forms.
Due to the fact that some categories of end-users had busy schedules and the fact that we were time-bound, we decided to develop quick, easy-to-answer questionnaires in addition to the semi-structured interviews in order to paint a more accurate picture.
Interviews and Questionnaires
In order to collect authentic, unbiased information from the users, we concluded that it would be vital to ask open-ended, general questions that would encourage them to give us honest answers about what their needs and expectations of the tool were. As we wanted to maximize the chances of users submitting the questionnaire, we made sure to include clear instructions on how to fill out the questionnaire and asked simple-to-answer questions while respecting their anonymity.
We chose to ask questions about what they thought the current problem was, what they liked and disliked about the current GO platform and what they believe the final product must contain. Extracts from the transcripts of the interviews as well as visualizations of the questionnaire results are as follows:
Analysis of Data Collected
Upon analysing the data collected through surverys, we arrived at the following conclusions:
- Users were concerned about the time taken to train non-organization staff (eg: volunteers) and thus wanted an easy-to-use system that was self-explanatory.
- Users wanted to be able to upload multiple files at once as uploading each document individually would be cumbersome.
- Users wanted to be able to see extracted data and be given the ability to edit results in case of errors.
Personas
After getting a clearer understanding of our end-users and their needs and expectations, we created personas of our main user groups: .
We decided to center our personas around details and personality traits that would have the most impact on our final product. The personas created are as follows:
MoSCoW Requirements
After analysing inetrview and questionnaire results as well as conducting adequate user research and communicating with our client, we finalized a list of functional and non-functional MoSCoW requirements:
Functional Requirements
Must Have
- The tool must be usable without the need for any login system. This is because the tool may be used by non-IFRC emplyees (for e.g.: National Society employees) or external volunteers, who may not possess the same kind of/any kind of standard IFRC employee details.
- Users must be able to see visible output of extracted information in a tabular form.
- Users must be given the option to upload either single files or a folder of files.
- The tool must extract the following details from documents:
- Operation Number.
- Glide Number.
- Admin 0, Admin 1 and Admin 2 location names.
- The respective International Organization for Standardization (ISO) code of Admin 0, Admin 1 and Admin 2 locations.
- Operation start date.
- Operation end date.
- Number of people affected.
- Number of people assisted.
- Name of the Host National Society.
- Operation Budget.
- Extracted information must be present in a database so that the required analyses can be performed to establish historic trends.
- When matching extracted locations with their corresponsing codes, the tool must take into account typos as well as different variations of city names (for e.g.: Bangalore vs Bengaluru, Sanaa vs Sana'a, Al-Khisa vs Al-Kheesa).
Should Have
- The tool should check if the document uploaded is in PDF format.
- Users should have the freedom of editing results of the data extraction in case of errors, before pushing extracted data into the database.
- The database should be structured in a sensible manner so that the required queries can be performed.
Could Have
- A preview page showing the contents of the PDF uploaded so that users can ensure the right PDF was uploaded.
- A progress bar that shows the prgress of the data enrichments so the users have a visual aid to help them gauge how long the process will take.
Won't Have
- Mechanism to work with non-PDF documents.
- The tool will not be able to handle documents that are not in English.
Non-functional Requirements
Must Have
- The tool must be easy to maintain and update for future use.
- The user interface must be intuitive and easy-to-follow.
- The tool must be portable and supported by all Operating Systems.
- Users must be able to easily comprehend what a feature is and what it can do. (for e.g.: button descriptions must be concise and accurate, a button with an 'i' on it will provide additional information etc).