Onward and upward with my demonstration of how business analysts can leverage the power of evolving AI technology in the form of chatGPT to work faster, create superior results, and hopefully lower stress levels. In this lecture, I’d like to demonstrate chatGPT’s ability to draft the standard path or the get dietary and budget suggestions use case that we identified in an earlier lecture.
A standard path in a use case represents the interaction between actors and the application. Unfortunately, for me, there wasn’t a lot of interaction in chatGPT’s earlier interpretation of the scope of this use case. So, I decided expanding the use case would make the demonstration a lot more useful. My expanded scope includes things like location service, searching for vendors within a specified range, filtering and sorting suitable menu items, selecting the item, ordering, and paying for the order.
In the first try, I’m asking chatGPT to create a use case specification document for this use case using the dialog convention. I’m specifically asking only for preconditions and post conditions and the standard path to keep it lean. I identify the primary actor as the consumer, secondary actor as the vendor, and the system with which they are interacting as the feed me app.
To make my expansion clear, I expanded the name of the use case to get dietary and budget suggestions with nearby vendors. Although I like that name, it’s way too long for me. I would have shortened it to something like order food, but that’s a personal choice.
Let’s look at the preconditions first. The consumer is legit and logged in, they have established a profile that has both dietary preferences and budget constraints, and the app has permission to use the consumer’s GPS. Vendors have loaded their ingredient list and prices for menu items. Sounds to me like we’re ready to rumble.
Now let’s dive into the standard path:
- The consumer triggers the use case.
- The app grabs the GPS location.
- It finds the vendors within the defined range.
- The app picks menu items from each selected vendor.
- The app filters out menu items that don’t match the consumer’s profile.
- Source the recommended menu items by how far away and how much to pay.
- Shows the list of suggested menu items to the consumer.
- The consumer selects a menu item.
- The app facilitates the order and prepayment.
- The app sends the order details to the corresponding vendor and the consumer.
That looks like a pretty reasonable main path. Remember, we aren’t dealing with errors or exceptions in this path.
Onward and downward to the post conditions. The consumer has a list of menu items that match their dietary preferences and budgets. They can order and prepay for their chosen menu item, and the vendor has received the order and begins preparing the food.
This use case is a good solid happy path. It starts with the consumer triggering the app and ends with a food order ready for pickup, delivery, or dining.
In conclusion, we have seen one way to create a use case specification document using the dialog format. We have also presented the same information in table form and as a function list. Different formats can cater to different learning styles and organizational norms. The key is to focus on what the system is supposed to achieve rather than the how. The how comes later during the design phase.
Remember, this is just a trigger to get you started. As the business analyst, you still need to collaborate with your AI assistant to deliver the goods. I hope this lecture was revealing, and I look forward to seeing you in the next one.
