20.2.4. BA Activities

• Gather user stories (e.g., “As a shopper, I want to remove an item from my cart”)

Gathering user stories means collecting and understanding the requirements from the end-users’ perspective. This involves speaking directly to users to learn about their needs and desires regarding a system. In the context of e-commerce, a user story example, 'As a shopper, I want to remove an item from my cart,' shows a specific action a user would want to perform. User stories help the business analyst to frame the project requirements clearly.

Think of it like a restaurant where you are the customer. If you want to make a specific change to your meal order (like removing onions from your burger), you express that desire to the waiter. In similar fashion, users express their needs through user stories which help the business analysts understand what changes or features must be included in the final product.

• Create wireframes for cart UI

Wireframes are visual blueprints for a system's interface that illustrate the layout and functionality, especially the user interface (UI). The business analyst works on designing these wireframes to show what the shopping cart feature will look like and how users will interact with it. Wireframes help to visualize the final product and reduce misunderstandings among stakeholders.

Consider wireframing like drafting plans for a new house. Before construction begins, architects create detailed blueprints to illustrate where different rooms will be placed and how they will work together. Similarly, wireframes provide a 'map' of how users will navigate through a digital product.

• Define business rules (e.g., max quantity per product, cart expiration)

Business rules are the specific guidelines that govern how various features of a product function. In the context of an e-commerce shopping cart, this might include limitations like the maximum quantity of a product a customer can buy or how long items can remain in the cart before they expire (or are removed). Establishing these rules is crucial since they help ensure the system behaves as expected.

Think of business rules like the regulations in a sport. For instance, in basketball, there are rules such as how far players can travel with the ball (traveling rule). Similarly, business rules dictate what customers can and cannot do within the shopping cart.

• Document functional & non-functional requirements

Requirements documentation involves detailing what the system should do (functional requirements) and how well it should perform (non-functional requirements). Functional requirements may include the ability to add items to the cart or apply discounts, while non-functional requirements could cover aspects like performance speed or usability. It's important the team understands both types to build a successful product.

Consider building a car. Functional requirements would include getting the car to start, stopping, and accelerating. Non-functional requirements might describe the desired fuel efficiency, safety features, or comfort. Both sets of requirements are vital for creating a successful vehicle.

• Conduct UAT for checkout and promo logic

User Acceptance Testing (UAT) is a critical phase in the development process where the system is tested in real-world scenarios by actual users. The goal is to ensure that all functionalities—such as the checkout process and applying promotional codes—work as intended. Feedback during UAT can reveal issues or areas for improvement before the product is fully launched.

Imagine you’re a chef who has created a new dish. Before you serve it to customers, you invite some friends to taste it and give feedback. This trial run allows you to make adjustments based on their reactions. Likewise, UAT helps to refine the product based on real user experiences.

--