Personal COVID-19 Challenges Provide Data Requirements Analysis Example

At the start of the COVID-19 pandemic in the United States--amid stay-at-home directives and health concerns especially for vulnerable populations--many people were challenged to acquire food, medications and other critical goods. A potential solution to this problem serves as an example of how data-oriented applications can be conceived and developed, starting with a data requirements analysis example.

In our neighborhood, an organic solution evolved that leverages a combination of technologies and collaboration to help support the needs of the people on the street while reducing the collective amount of time that people are out of their homes and minimizing potential exposure to the virus.

The basic idea is that whenever someone goes to a store, that person--whom we will call the “shopper”--alerts others in the cohort and asks if anyone needs anything from that store. Anyone else (we’ll call those people “recipients”) can post what is needed. The shopper can then purchase all, some or none of those items (based on availability, usually). Once items have been purchased, the shopper works with each recipient to arrange for delivery and reimbursement.  

This approach combines a handful of technologies that are available on any smartphone. We used WhatsApp to create the group and share both shopper information (where the shopper is going), status (what is and is not available) and recipient requests. Payment options include traditional exchange of cash or money exchange apps such as Zelle or Venmo.

In general, this has worked generally well, although are a few issues. For example, a shopper alerts the list about the store that he/she is going to, but other people are not monitoring their phones and miss the notification. In this case, recipients miss the opportunity to acquire something they need, delaying the time to acquisition until the next shopper decides to go to that particular store. Another example is the need for the shopper to tally up all the amounts owed, communicate that to the recipients and request the reimbursements. And, not surprisingly, there are times when the cash paid by Person A to reimburse Person B on one day is returned by Person B to Person A on another day when the roles are reversed.

It occurred to me that this scenario was a good example of how a dedicated data-oriented application could reduce the complexity of interactions, speed the accessibility to needed items and manage back-end remuneration. This gives us an opportunity to “roll back the covers” and provide a case study of two key aspects of data-oriented application design: user requirements analysis and data design and implementation. The remainder of this article looks at the user requirements, and a follow-up article will map out the data design.

By reviewing data from a collection of our interactions, we can derive (at the very least) these key requirements:

Requirement 1 provides the context for the scope of sources from which an item can be requested.

Requirement 2 addresses the “synchronization” issue that happens when someone misses the message that a shopper is at a particular location. It allows you to add your request to a list that any shopper will be able to see whenever that shopper goes to a particular location (Requirement 3).

Once the item has been acquired, that item should be removed from the request list so that no one else tries to purchase it (Requirement 4), and the shopper should be able to log the prices of all purchased items (Requirement 5) and the amounts purchased for each recipient so that the reimbursements can be automatically calculated (requirement 6).

Finally, the shopper must be provided with the instructions of how to deliver the purchase items (Requirement 7).

This addresses most of the requirements except for simplifying the reimbursement process, and this introduces an additional requirement (Requirement 8) that “the payment process should be automated when possible.”

Given this basic set of requirements, our next steps, which I will discuss in an upcoming article, would be to describe the process flows, analyze the data management requirements and describe the transactions associated with each step of the process flows.

The result should be a blueprint for implementing a “neighborhood collaborative shopping” application that can be architected, designed and implemented.