How to Gather Requirements and Write Use Cases for a Software?

Everyone loves a satisfied customer (especially our sales team, since that's how we get our salaries!). But how do we make customers happy? How do we capture requirements properly for developing good software? That is what we will learn today.

Let's start with a story!

Rajesh, the proud owner of a bustling sweet shop on 56 Dukan Street in Indore, is struggling to manage his inventory due to the recent increase in consumer demand and limited staff. Frustrated with the inability to handle numerous orders, Rajesh reaches out to GreatSoftwareSolutions.Inc in search of a solution.

"Every day we are losing customers since our staff is not able to handle so many orders. Can you help us in managing our orders and inventory?" Rajesh pleads with a heavy voice.

"Don't worry, Rajesh. You have come to the right place. In fact, we already have a solution ready for you. Have a look," Vikas from sales replies with a confident voice.

class MySweetShop {
  
    private OrderService orderService;
    private Map<String, Integer> inventory = new HashMap<>();
  
    public MySweetShop(OrderService orderService) {
        this.orderService = orderService;
    }
  
    public String placeOrder(String sweetName, int quantity) {
        if (inventory.containsKey(sweetName) && inventory.get(sweetName) >= quantity) {
            inventory.put(sweetName, inventory.get(sweetName) - quantity);
            int orderId = orderService.placeOrder(sweetName, quantity);
            return "Your order id is " + orderId + ". Please collect it from the counter.";
        } else {
            return "Sorry, we are out of stock. Please come tomorrow.";
        }
    }
  
    // other methods
}

Relieved to have found a solution, Rajesh thanks the team and begins using the inventory management app in his shop. Everything runs smoothly until Rajesh hurries back to GSS.Inc's office a few days later, with a sense of urgency.

"There's some problem with the system. Our customers are not able to order our best-selling Indori special chaat," Rajesh explains, frustrated with the setback.

Tip: Think about what could have gone wrong here before reading further!

• Kishore (new intern at GSS.Inc): "I figured out the problem. The inventory is empty, that's why customers can't find the item."
• Rajesh: "How is that possible? I just updated the inventory this morning!"
• Kishore: "Did you update the data in the app?"
• Rajesh: "Well, nobody told me I had to do it. I asked for an app that can handle everything for me.

This is what happens when you don't listen to your customers properly. Always remember, the first principle for building a great software product is that Great Software fulfils customer expectations, no matter how big or small. In the software development life cycle, this step of capturing the expectations and requirements of your customers is known as Requirement Gathering.

What is a requirement?

In software engineering, A requirement is a statement that describes what a software system must do or how it should behave in order to satisfy stakeholders’ needs and expectations.

Requirements can be divided into two categories:

1. Functional Requirements: These requirements describe the system’s behaviour and define what it must do to achieve its intended purpose. Functional requirements are typically derived from user stories or use cases that describe the steps a user would take to achieve a specific goal.
2. Non-Functional Requirements: These requirements describe the system’s qualities or characteristics, such as performance, reliability, security, usability, and maintainability. Non-functional requirements often specify constraints or conditions that the system must satisfy or provide guidance for design decisions.

One effective way to capture requirements is to use a structured approach such as the user story mapping technique. This involves identifying and organizing user stories based on the different user roles and goals and then prioritizing them based on their importance and feasibility.

User Stories for VSS:

1. As a customer, I want to browse the available sweets and savouries on the website, so that I can make an informed purchase decision.
2. As a customer, I want to place an order online and receive a confirmation email with an order ID, so that I can pick up my order at the shop later.
3. As a shop owner, I want to update the inventory of available items in real-time, so that I can keep track of stock levels and avoid overselling.
4. As a shop worker, I want to receive notifications of new orders and assign them to the appropriate worker based on availability and proximity, so that I can efficiently fulfil customer requests.
5. As a shop worker, I want to update the order status in real-time and communicate any delays or issues to the customer, so that they are informed and satisfied with the service.

Using these user stories as a basis, we can then identify the corresponding functional and non-functional requirements for the system, such as:

Functional Requirements

1. The system shall provide a searchable catalogue of available sweets and savouries, including descriptions and prices.
2. The system shall enable customers to place orders online, select pickup times, and receive confirmation emails with order IDs.
3. The system shall allow the shop owner to update the inventory of available items, including quantities and prices, and view sales reports.
4. The system shall notify shop workers of new orders and assign them to the appropriate worker based on availability and proximity.
5. The system shall allow shop workers to update the status of orders in real-time and communicate with customers via email or SMS.

Non-functional Requirements

1. The system shall be available 24/7 and have an uptime of at least 99%.
2. The system shall respond to customer requests within 5 seconds and complete transactions within 2 minutes.
3. The system shall be secure and protect customer data from unauthorized access or theft.
4. The system shall be scalable and able to handle increasing traffic and orders over time.
5. The system shall be easy to use and intuitive for both customers and shop workers, with clear instructions and error messages.

Notice how writing the user journey also helps us design the system. In this case, our application caters to two different sets of users. From a design perspective, it makes sense to build the product with clearly defined system borders between the two groups. These different sets of requirements delivered by your software system are also commonly known as use cases.

What is a use case?

In software development, A use case outlines how a system interacts with users or other systems to achieve a specific goal. It defines the steps involved and the expected inputs and outputs for that goal.

Why are use cases important?

Use cases are critical in the requirements-gathering process. They help ensure that the system meets the needs of end-users and stakeholders by providing a clear understanding of how the system will work in real-world scenarios.

How to write good use cases? 

1. Include multiple examples: Provide use cases that illustrate different types of systems or industries. This will help readers better understand how use cases can be applied in a variety of contexts.
2. Use diagrams: Consider including a use case diagram to visualize the different actors and their interactions with the system. This can help readers better understand the relationships between the system and its users.
3. Discuss alternative paths: In addition to the happy path, consider alternative scenarios where a use case may take a different path. For example, what happens if a customer’s payment fails? This can help ensure that the system is robust and can handle unexpected situations.
4. Define clear starting and stopping points: Each use case should have a clearly defined starting and stopping point. For example, in an e-commerce system, the starting point may be when a user adds items to their cart and the stopping point maybe when the user completes their purchase.
5. Define external initiators: Each use case should have a clearly defined external initiator, which can be a human or another subsystem. For example, in a food delivery system, the external initiator may be a customer placing an order through a mobile app.
6. Define clear inputs and outputs: Each use case should define the expected inputs and outputs in a clear and concise manner. This will help ensure that everyone involved in the project has a clear understanding of what the system needs to do.

Few examples:

Use case: Deliver an order to the customer

Input: Order Id, Item Quantity, Item Type
Output: Packaged items of given quantity

Happy Path:
1. Validate order id.
2. Fetch Items
3. Package Items
4. Deliver items to reception area.

 Use case: Assist Customer with Order Placement

Input: Customer Query
Output: Order Id

Happy Path : 
1. Prompt customer for a query
2. Search Inventory for availability of queried item.
3. Prompt user for payment
4. Provide user with an order Id.

Use case: Authenticate a user

Inputs: Username and password 
Outputs: Access to protected resources

Happy path:
1. User enters their username and password.
2. System verifies the credentials.
3. System grants the user access to protected resources.

Summary

In conclusion, gathering requirements is a critical step in building great software products. It involves capturing and organizing user stories and identifying corresponding functional and non-functional requirements for the system. By listening to customers and using a structured approach such as user story mapping can help ensure that all important requirements are identified and prioritized.

So always remember the first principle for building a great software product: Great Software fulfils customer expectations, no matter how big or small. Enjoy learning, enjoy software engineering!

If you have any queries/doubts/feedback, please write us at contact@enjoyalgorithms.com. Enjoy learning, Enjoy oops design, Enjoy algorithms!