Agile Requirements Modeling Example 1. Initial Envisionment

Agile Requirements Modeling Examplehttp://www.agilemodeling.com/essays/agileRequirementsExample.htmPage 10 of 133/1/2011So how would I approach detailed requirements modeling for SWA Online? First, let’s assume that the two ofus are working together as a pair and that our team will be implementing the order definition and placementportions of the basic course of action for the “Place Order” use case in this iteration. We won’t be implementingsearch functionality, any sort of error or exception handling, tax calculations, or discount calculations right now.This example reveals a common problem with use cases – they are often too coarse-grained to schedule into asingle iteration. You are often motivated to either schedule a single use case across multiple iterations,something that is uncomfortable from a project management point of view, or refactor your use case into acollection of smaller ones which is often uncomfortable from a modeling point of view.The basic course of action is often called the “happy path” because everything works in the basic course ofaction – the alternate courses of action describe when things don’t work well, in the case of placing an order thiswould include being out of stock of an item that the customer has requested. However, our goal this iteration isto focus simply on a portion of the happy path for now, the other requirements will be worked on either by othersubteams or perhaps by us at a later date.The first thing that we do is flesh out the logic for the basic course of action, which is presented in Figure 6, andin parallel work on essential (abstract) UI prototypes relevant to this use case. We work on these twoartifacts in parallel because they each approach the problem from a different direction, the use case describeswhat the customer does to place an order and the essential UI prototype specifies what the user interface ofSWA Online must include to support this behavior. Notice how the use case invokes the “Search for Item(s)”use case on line two, consistent with the application of the stereotype in Figure 4. Even thoughthis functionality is invoked in the part of the use case that we’re currently focused on we won’t be implementingthat functionality yet because it’s not in scope. Instead we’ll stub out what we need, perhaps going straight to aresults page listing the theoretical results of our search. Later on in the project the searching functionality willbe added as appropriate, just not now (remember, we’re working incrementally). Also notice how the use casedoesn’t take into consideration any sort of technology issues yet, issues that we may decide to address later.Right now we just want to understand the basic process of placing an order, we can worry aboutimplementation details later (potentially in a few minutes from now). The use case describes logic that we won’tbe implementing this iteration, such as the calculation of taxes and discounts, functionality that we’ll need tostub out when we’re coding.Figure 6. The basic course of action for placing an order.1. The use case begins when a customer chooses to place an order.2. The customer searches for items via the use case “Search for Item(s)”3. The customer selects adds an order item to their order.4. The customer indicates the number of a given item they wish to order.5. The system calculates the subtotal for the item by multiplying the unit price by the number ordered.6. The customer repeats steps 2 through 5 as necessary to build their order.7. The customer finishes adding items to their order.8. The customer provides their ship to and bill to information, including their name, phone number, andsurface address.9. The system calculates the subtotal for the entire order by adding the subtotals of the individual lineitems.