Use Cases: Understanding and Writing Effective Use Cases for Software Requirements - Prof., Study notes of Information Technology

Download Use Cases: Understanding and Writing Effective Use Cases for Software Requirements - Prof. and more Study notes Information Technology in PDF only on Docsity! 45 Chapter 6 6 USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT The indispensable first step to getting the things you want out of life: decide what you want. —Ben Stein Introduction This is worth studying during a first read of the book because use cases are a widely used and useful mechanism to discover and record requirements (espe- cially functional); they influence many aspects of a project, including OOA/D. It is worth both knowing about and creating use cases. Writing use cases—stories of using a system—is an excellent technique to understand and describe requirements. This chapter explores key use case con- cepts and presents sample use cases for the NextGen application. The UP defines the Use-Case Model within the Requirements workflow. Essentially, this is the set of all use cases; it is a model of the system’s function- ality and environment. Objectives
Identify and write use cases.
Relate use cases to user goals and elementary business processes.
Use the brief, casual, and fully dressed formats, in an essential style.
Relate use case work to iterative development. 6 – USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT 46 6.1 Goals and Stories Customers and end users have goals (also known as needs in the UP) and want computer systems to help meet them, whether as mercantile as recording sales or as complex as estimating the flow of oil from future wells. There are several ways to capture these goals and system requirements; the better ones are sim- ple and familiar because this makes it easier—especially for customers and end users—to contribute to their definition or evaluation. That lowers the risk of missing the mark. Use cases are a mechanism to help keep it simple and understandable for all stakeholders. Informally, they are stories of using a system to meet goals. Here is an example brief format use case: Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each pur- chased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items. Use cases often need to be more elaborate than this, but the essence is discover- ing and recording functional requirements by writing stories of using a system to help fulfill various stakeholder goals; that is, cases of use.1 It isn’t supposed to be a difficult idea, although it may indeed be difficult to discover or decide what is needed, and write it coherently at a useful level of detail. Much has been written about use cases, and while worthwhile, there is always the risk among creative, thoughtful people to obscure a simple idea with layers of sophistication. It is usually possible to spot a novice use case modeler (or a serious Type A analyst) by an over-concern with secondary issues such as use case diagrams, use case relationships, use case packages, optional attributes, and so forth, rather than writing the stories. That said, a strength of the use case mechanism is the capacity to scale both up and down in terms of sophistica- tion and formality, depending on need. 6.2 Background The idea of use cases to describe functional requirements was introduced in 1986 by Ivar Jacobson [Jacobson92], a main contributor to the UML and UP. 1. The original term in Swedish literally translates as “usage case.” 49 USE CASE TYPES AND FORMATS 6.5 Use Case Types and Formats Black-Box Use Cases and System Responsibilities Black-box use cases are the most common and recommended kind; they do not describe the internal workings of the system, its components, or design. Rather, the system is described as having responsibilities, which is a common unifying metaphorical theme in object-oriented thinking—software elements have responsibilities and collaborate with other elements that have responsibilities. By defining system responsibilities with black-box use cases, it is possible to specify what the system must do (the functional requirements) without deciding how it will do it (the design). Indeed, the definition of “analysis” versus “design” is sometimes summarized as “what” versus “how.” This is an important theme in good software development: During requirements analysis avoid making “how” decisions, and specify the external behavior for the system, as a black box. Later, during design, create a solution that meets the specification. Formality Types Use cases are written in different formats, depending on need. In addition to the black-box versus white-box visibility type, there are varying degrees of formal- ity:
brief—terse one-paragraph summary, usually of the main success scenario. The prior Process Sale example was brief.
casual—informal paragraph format. Multiple paragraphs that cover vari- ous scenarios. The prior Handle Returns example was casual.
fully dressed—the most elaborate. All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees. The following example is a fully dressed case for our NextGen case study: Black-box style Not The system records the sale. The system writes the sale to a data- base. ...or (even worse) : The system generates a SQL INSERT statement for the sale... 6 – USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT 50 6.6 Fully Dressed Example: Process Sale Fully dressed use cases show more detail and are structured; they are useful in order to obtain a deep understanding of the goals, tasks, and requirements. In the NextGen POS case study, they would be created during one of the early requirements workshops in a collaboration of the system analyst, subject matter experts, and developers. The usecases.org Format Various format templates re available for fully dressed use cases. However, per- haps the most widely used and shared format is the template available at www.usecases.org. The following example illustrates this style. Please note that this is the primary case study example of a detailed use case; it shows many common elements and issues. Use Case UC1: Process Sale Primary Actor: Cashier Stakeholders and Interests: – Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer short- ages are deducted from his/her salary. – Salesperson: Wants sales commissions updated. – Customer: Wants purchase and fast service with minimal effort. Wants proof of pur- chase to support returns. – Company: Wants to accurately record transactions and satisfy customer interests. Wants to ensure that Payment Authorization Service payment receivables are recorded. Wants some fault tolerance to allow sales capture even if server compo- nents (e.g., remote credit validation) are unavailable. Wants automatic and fast update of accounting and inventory. – Government Tax Agencies: Want to collect tax from every sale. May be multiple agen- cies, such as national, state, and county. – Payment Authorization Service: Wants to receive digital authorization requests in the correct format and protocol. Wants to accurately account for their payables to the store. Preconditions: Cashier is identified and authenticated. Success Guarantee (postconditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Main Success Scenario (or Basic Flow): 1. Customer arrives at POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. Cashier repeats steps 3-4 until indicates done. 5. System presents total with taxes calculated. 51 FULLY DRESSED EXAMPLE: PROCESS SALE 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. 8. System logs completed sale and sends sale and payment information to the external Accounting system (for accounting and commissions) and Inventory system (to update inventory). 9. System presents receipt. 10.Customer leaves with receipt and goods (if any). Extensions (or Alternative Flows): *a. At any time, System fails: To support recovery and correct accounting, ensure all transaction sensitive state and events can be recovered from any step of the scenario. 1. Cashier restarts System, logs in, and requests recovery of prior state. 2. System reconstructs prior state. 2a. System detects anomalies preventing recovery: 1. System signals error to the Cashier, records the error, and enters a clean state. 2. Cashier starts a new sale. 3a. Invalid identifier: 1. System signals error and rejects entry. 3b. There are multiple of same item category and tracking unique item identity not important (e.g., 5 packages of veggie-burgers): 1. Cashier can enter item category identifier and the quantity. 3-6a: Customer asks Cashier to remove an item from the purchase: 1. Cashier enters item identifier for removal from sale. 2. System displays updated running total. 3-6b. Customer tells Cashier to cancel sale: 1. Cashier cancels sale on System. 3-6c. Cashier suspends the sale: 1. System records sale so that it is available for retrieval on any POS terminal. 4a. The system generated item price is not wanted (e.g., Customer complained about something and is offered a lower price): 1. Cashier enters override price. 2. System presents new price. 5a. System detects failure to communicate with external tax calculation system service: 1. System restarts the service on the POS node, and continues. 1a. System detects that the service does not restart. 1. System signals error. 2. Cashier may manually calculate and enter the tax, or cancel the sale. 5b. Customer says they are eligible for a discount (e.g., employee, preferred customer): 1. Cashier signals discount request. 2. Cashier enters Customer identification. 3. System presents discount total, based on discount rules. 5c. Customer says they have credit in their account, to apply to the sale: 1. Cashier signals credit request. 2. Cashier enters Customer identification. 3. Systems applies credit up to price=0, and reduces remaining credit. 6a. Customer says they intended to pay by cash but don’t have enough cash: 1a. Customer uses an alternate payment method. 1b. Customer tells Cashier to cancel sale. Cashier cancels sale on System. 7a. Paying by cash: 1. Cashier enters the cash amount tendered. 6 – USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT 54 The Best Format? There isn’t one best format; some prefer the one-column style, some the two-col- umn. Sections may be added and removed; heading names may change. None of this is particularly important; the key thing is to write the details of the main success scenario and its extensions, in some form. [Cockburn1] summarizes many usable formats. 6.7 Explaining the Sections Preface Elements Many optional preface elements are possible. Only place elements at the start which are important to read before the main success scenario. Move extraneous “header” material to the end of the use case. Important: Stakeholders and Interests List This list is more important and practical than may appear at first glance. It sug- gests and bounds what the system must do. To quote: The [system] operates a contract between stakeholders, with the use cases detailing the behavioral parts of that contract...The use case, as the contract for behavior, captures all and only the behaviors related to satisfying the stakeholders’ interests [Cockburn01]. This answers the question: What should be in the use case? The answer is: That which satisfies all the stakeholders’ interests. In addition, by starting with the stakeholders and their interests before writing the remainder of the use case, we have a method to remind us what the more detailed responsibilities of the Personal Practice This is my practice, not a recommendation. For some years, I used the two- column format because of its clear visual separation in the conversation. However, I have reverted to a one-column style as it is more compact and easier to format, and the slight value of the separated conversation does not for me outweigh these benefits. I find it still simple to visually identify the different parties in the conversation (Customer, System, ...) if each party and the System responses are usually allocated to their own steps. Primary Actor: The principal actor that calls upon system services to fulfill a goal. 55 EXPLAINING THE SECTIONS system should be. For example, would I have identified a responsibility for sales- person commission handling if I had not first listed the salesperson stakeholder and their interests? Hopefully eventually, but perhaps I would have missed it during the first analysis session. The stakeholder interest viewpoint provides a thorough and methodical procedure for discovering and recording all the required behaviors. Preconditions and Success Guarantees Preconditions state what must always be true before beginning a scenario in the use case. Preconditions are not tested within the use case; rather, they are conditions that are assumed to be true. Typically, a precondition implies a sce- nario of another use case that has successfully completed, such as logging in, or the more general “cashier is identified and authenticated.” Note that there are conditions that must be true, but are not of practical value to write, such as “the system has power.” Preconditions communicate noteworthy assumptions that the use case writer thinks readers should be alerted to. Success guarantees (or postconditions) state what must be true on success- ful completion of the use case—either the main success scenario or some alter- nate path. The guarantee should meet the needs of all stakeholders. Main Success Scenario and Steps (or Basic Flow) This has also been called the “happy path” scenario, or the more prosaic “Basic Flow”. It describes the typical success path that satisfies the interests of the stakeholders. Note that it often does not include any conditions or branching. Although not wrong or illegal, it is arguably more comprehensible and extend- ible to be very consistent and defer all conditional handling to the Extensions section. Stakeholders and Interests: – Cashier: Wants accurate, fast entry and no payment errors, as cash drawer shortages are deducted from his/her salary. – Salesperson: Wants sales commissions updated. – ... Preconditions: Cashier is identified and authenticated. Success Guarantee (postconditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Suggestion Defer all conditional and branching statements to the Extensions section. 6 – USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT 56 The scenario records the steps, of which there are three kinds: 1. An interaction between actors.3 2. A validation (usually by the system). 3. A state change by the system (for example, recording or modifying some- thing). Step one of a use case does not always fall into this classification, but indicates the trigger event that starts the scenario. It is a common idiom to always capitalize the actors’ names for ease of identifica- tion. Observe also the idiom that is used to indicate repetition. Extensions (or Alternate Flows) Extensions are very important. They indicate all the other scenarios or branches, both success and failure. Observe in the fully dressed example that the Extensions section was considerably longer and more complex than the Main Success Scenario section; this is common and to be expected. They are also known as “Alternative Flows.” In thorough use case writing, the combination of the happy path and extension scenarios should satisfy “nearly” all the interests of the stakeholders. This point is qualified, because some interests may best be captured as non-functional requirements expressed in the Supplementary Specification rather than the use cases. Extension scenarios are branches from the main success scenario, and so can be notated with respect to it. For example, at Step 3 of the main success scenario there may be an invalid item identifier, either because it was incorrectly entered or unknown to the system. An extension is labeled “3a”; it first identifies the condition and then the response. Alternate extensions at Step 3 are labeled “3b” and so forth. 3. Note that the system under discussion itself should be considered an actor when it plays an actor role collaborating with other systems. Main Success Scenario: 1. Customer arrives at a POS checkout with items to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. ... Cashier repeats steps 3-4 until indicates done. 5. ... Extensions: 3a. Invalid identifier: 59 GOALS AND SCOPE OF A USE CASE 6.8 Goals and Scope of a Use Case How should use cases be discovered? It is common to be unsure if something is a valid (or more practically, a useful) use case. Tasks can be grouped at many lev- els of granularity, from one or a few small steps, up to enterprise-level activities. At what level and scope should use cases be expressed? The following sections examine the simple ideas of elementary business pro- cesses and goals as a framework for identifying the use cases for an application. Use Cases for Elementary Business Processes Which of these is a valid use case?
Negotiate a Supplier Contract
Handle Returns
Log In An argument can be made that all of these are use cases at different levels, depending on the system boundary, actors, and goals. Evaluation of these candi- dates is presented after an introduction to elementary business processes. Rather than asking in general, “What is a valid use case?”, a more relevant question for the POS case study is: What is a useful level to express use cases for application requirements analysis? 7b. Credit payment signature captured on paper receipt. But within two years, we pre- dict many customers will want digital signature capture. Suggestion This section should not contain multiple steps to express varying behavior for different cases. If that is necessary, say it in the Extensions section. Guideline: The EBP Use Case For requirements analysis for a computer application, focus on use cases at the level of elementary business processes (EBPs). 6 – USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT 60 EBP is a term from the business process engineering field4, defined as: A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state. e.g., Approve Credit or Price Order [original source lost]. This can be taken too literally: Does a use case fail as an EBP if two people are required, or if a person has to walk around? Probably not, but the feel of the def- inition is about right. It’s not a single small step like “delete a line item” or “print the document.” Rather, the main success scenario is probably five or ten steps. It doesn’t take days and multiple sessions, like “negotiate a supplier con- tract;” it is a task done during a single session. It is probably between a few min- utes and an hour in length. As with the UP’s definition, it emphasizes adding observable or measurable business value, and it comes to a resolution in which the system and data are in a stable and consistent state. Reasonable Violations of the EBP Guideline Although the “base” use cases for an application should satisfy the EBP guide- line, it is frequently useful to create separate “sub” use cases representing sub- tasks or steps within a base use case. Use cases can exist that fail the EBP test; many potentially exist at a lower level. The guideline is only used to find the dominant level of use cases in requirements analysis for an application; that is, the level to focus on for naming and writing them. For example, a subtask or extension such as “paying by credit” may be repeated in several base use cases. It is desirable to separate this into its own use case (that does not satisfy the EBP guideline) and link it to several base use cases, to avoid duplication of the text. Chapter 25 explores the issue of use case relation- ships. Use Cases and Goals Actors have goals (or needs) and use applications to help satisfy them. Conse- quently, an EBP-level use case is called a user goal-level user case, to empha- size that it serves (or should serve) to fulfill a goal of a user of the system, or the primary actor. 4. EBP is similar to the term user task in usability engineering, although the meaning is less strict in that domain. A common use case mistake is defining many use cases at too low a level; that is, as a single step, subfunction, or subtask within an EBP. 61 GOALS AND SCOPE OF A USE CASE And it leads to a recommended procedure: 1. Find the user goals. 2. Define a use case for each. This is slight shift in emphasis for the use case modeler. Rather than asking “What are the use cases?”, one starts by asking: “What are your goals?” In fact, the name of a use case for a user goal should reflect its name, to emphasize this viewpoint—Goal: capture or process a sale; use case: Process Sale. Note that because of this symmetry, the EBP guideline can be equally applied to decide if a goal or a use case is at a suitable level. Thus, here is a key idea regarding investigating user goals vs. investigating use cases: Example: Applying the EBP Guideline As the system analyst responsible for the NextGen system requirements discov- ery, you are investigating user goals. The conversation goes like this: During a requirements workshop: System analyst: “What are some of your goals in the context of using a POS system?” Cashier: “One, to quickly log in. Also, to capture sales.” System analyst: “What do you think is the higher level goal motivating log- ging in?” Cashier: “I’m trying to identify myself to the system, so it can validate that I’m allowed to use the system for sales capture and other tasks.” System analyst: “Higher than that?” Cashier: “To prevent theft, data corruption, and display of private company information.” Imagine we are together in a requirements workshop. We could ask either:
“What do you do?” (roughly a use case-oriented question) or,
“What are your goals?” Answers to the first question are more likely to reflect current solutions and procedures, and the complications associated with them. Answers to the second question, especially combined with an investigation to move higher up the goal hierarchy (“what is the goal of that goal?”) open up the vision for new and improved solutions, focus on adding business value, and get to the heart of what the stakeholders want from the system under discussion. 6 – USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT 64 both. Sometimes, goals reveal the actors, or vice versa. Guideline: Emphasize brainstorming the primary actors first, as this sets up the framework for further investigation. Reminder Questions to Find Actors and Goals In addition to obvious primary actors and user goals, the following questions help identify others that may be missed: Primary and Supporting Actors Recall that primary actors have user goals fulfilled through using services of the system. They call upon the system to help them. This is in contrast to support- ing actors, which provide services to the system under design. For now, the focus is on finding the primary actors, not the supporting ones. Recall also that primary actors can be—among other things—other computer systems, such as “watchdog” software processes. The Actor-Goal List Record the primary actors and their user goals in an actor-goal list. In terms of UP artifacts it should be a section in the Vision artifact (which is described in the next chapter). Who starts and stops the system? Who does system administration? Who does user and security man- agement? Is “time” an actor because the sys- tem does something in response to a time event? Is there a monitoring process that restarts the system if it fails? Who evaluates system activity or performance? How are software updates handled? Push or pull update? Who evalutes logs? Are they remotely retrieved? Suggestion Be suspicious if no primary actors are external computer systems. 65 FINDING PRIMARY ACTORS, GOALS, AND USE CASES For example: Project Planning Dimension In practice, this list has additional columns for priority, effort, and risk; this is briefly covered in Chapter 36. The Messy Reality This list looks neat, but the reality of its creation is anything but. Lots of brain- storming and thrashing about in a requirements workshop goes on. Consider the earlier example that illustrated applying the EBP rule to the “log in” goal. During the workshop while creating this list the cashier may offer “log in” as one of the user goals. The system analyst digs deeper and raises the level of the goal beyond the low-level mechanism of logging in (the cashier was probably thinking of using a dialog box on a GUI) up to the level of “identify and authen- ticate user.” Yet, the analyst then realizes it does not pass the EBP guideline, and discards it as a user goal. Of course, the reality is even somewhat different than this because an experienced analyst has a set of heuristics from past expe- rience or study, one of which is “user authentication is seldom an EBP,” and so is likely to have filtered this out quickly. Primary Actor and User Goals Depend on System Boundary Why is the cashier, and not the customer, the primary actor in the use case Pro- cess Sale? Why doesn’t the customer appear in the actor-goal list? The answer depends on the system boundary of the system under design, as illustrated in Figure 6.1. If viewing the enterprise or checkout service as an Actor Goal Actor Goal Cashier process sales process rentals handle returns cash in cash out . . . System Administra- tor add users modify users delete users manage security manage system tables . . . Manager start up shut down . . . Sales Activ- ity Systema analyze sales and per- formance data . . . . . . . . . . . . a. The Sales Activity System is a remote application that will frequently request sales data from each POS node in the network. 6 – USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT 66 aggregate system, the customer is a primary actor, with the goal of getting goods or services and leaving. However, from the viewpoint of just the POS system (which is the choice of system boundary for this case study), it services the goal of the cashier (and the store) to process the customer’s sale. Figure 6.1 Primary actors and goals at different system boundaries. Actors and Goals via Event Analysis Another approach to aid in finding actors, goals, and use cases is to identify external events. What are they, where from, and why? Often, a group of events belong to the same EBP-level goal or use case. For example: Step 4: Define Use Cases In general, define one EBP-level use case for each user goal. Name the use case similar to the user goal—for example, Goal: process a sale; Use Case: Process Sale. External Event From Actor Goal enter sale line item Cashier process a sale enter payment Cashier or Customer process a sale . . . Goal: Process sales Cashier Customer POS System Checkout Service Goal: Buy items Enterprise Selling Things Sales Tax Agency Goal: Collect taxes on sales Sales Activity System Goal: Analyze sales and performance data Also, name use cases starting with a verb. Note that the dictionary defines goal as a synonym for intention [MW89], illus- trating the connection between the essential style idea of Constantine and the goal-oriented viewpoint previously stressed in this chapter. Indeed, many actor intention steps in an essential use case can also be be characterized as subfunc- tion goals. Contrasting Examples Essential Style Assume that the Manage Users use case requires identification and authentica- tion. The Constantine-inspired essential style uses the two-column format. However, it can be written in one column. In the one-column format this is shown as: The design solution to these intentions and responsibilities is wide open: bio- metric readers, graphical user interfaces (GUIs), and so forth. Concrete Style—Avoid During Early Requirements Work In contrast, there is a concrete use case style. In this style, user interface deci- sions are embedded in the use case text. The text may even show window screen shots, discuss window navigation, GUI widget manipulation and so forth. For example: These concrete use cases may be useful as an aid to concrete or detailed GUI design work during a later step, but they are not suitable during the early requirements analysis work. During early requirements work, “keep the user interface out—focus on intent.” . . . Actor Intention System Responsibility 1. Administrator identifies self. 2. Authenticates identity. 3. . . . . . . 1. Administrator identifies self. 2. System authenticates identity. 3. . . . . . . 1. Adminstrator enters ID and password in dialog box (see Picture 3). 2. System authenticates Adminstrator. 3. System displays the “edit users” window (see Picture 4). 4. . . . 6 – USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT 70 6.12 Actors An actor is anything with behavior, including the system under discussion (SuD) itself when it calls upon the services of other systems.6 Primary and supporting actors will appear in the action steps of the use case text. Actors are not only roles played by people, but organizations, software, and machines. There are three kinds of external actors in relation to the SuD:
Primary actor—has user goals fulfilled through using services of the SuD. For example, the cashier.  Why identify? To find user goals, which drive the use cases.
Supporting actor—provides a service (for example, information) to the SuD. The automated payment authorization service is an example. Often a computer system, but could be an organization or person.  Why identify? To clarify external interfaces and protocols.
Offstage actor—has an interest in the behavior of the use case, but is not primary or supporting; for example, a government tax agency.  Why identify? To ensure that all necessary interests are identified and satisfied. Offstage actor interests are sometimes subtle or easy to miss unless these actors are explicitly named. 6.13 Use Case Diagrams The UML provides use case diagram notation to illustrate the names of use cases and actors, and the relationships between them. A common sign of a novice (or academic) use case modeler is a preoccupation with use case diagrams and use case relationships, rather than writing text. World-class use case experts such as Anderson, Fowler, Cockburn, among oth- ers, downplay use case diagrams and use case relationships, and instead focus on writing. 6. This was a refinement and improvement to alternate definitions of actors, including those in early versions of the UML and UP [Cockburn97]. Older definitions inconsis- tently excluded the SuD as an actor, even when it called upon services of other sys- tems. All entities may play multiple roles, including the SuD. Use case diagrams and use case relationships are secondary in use case work. Use cases are text documents. Doing use case work means to write text. 71 USE CASE DIAGRAMS With that as a caveat, a simple use case diagram provides a succinct visual con- text diagram for the system, illustrating the external actors and how they use the system. A use case diagram is an excellent picture of the system context; it makes a good context diagram, that is, showing the boundary of a system, what lies outside of it, and how it gets used. It serves as a communication tool that summarizes the behavior of a system and its actors. A sample partial use case context dia- gram for the NextGen system is shown in Figure 6.2. Figure 6.2 Partial use case context diagram. Suggestion Draw a simple use case diagram in conjunction with an actor-goal list. NextGen Manage Users . . . Cashier System Administrator actor use case communicationsystem boundary Handle Returns Payment Authorization Service «actor» Tax Calculator «actor» Accounting System alternate notation for a computer system actor Process Rental «actor» HR System Cash In Process Sale «actor» Sales Activity System Manage Security Analyze Activity 6 – USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT 74 pages of low-level, detailed features, a system features list tends to include only a few dozen items. The list provides a very succinct summary of system func- tionality, independent of the use case view. For example: Summary of System Features
sales capture
payment authorization (credit, debit, check)
system administration for users, security, code and constants tables, and so on
automatic offline sales processing when external components fail
real-time transactions, based on industry standards, with third-party systems, including inventory, accounting, human resources, tax calculators, and payment authorization services
definition and execution of customized “pluggable” business rules at fixed, common points in the processing scenarios
. . . This is explored in the next chapter. When Are Detailed Feature Lists Appropriate? Sometimes use cases do not really fit; some applications call out for a feature- driven viewpoint. For example, application servers, database products, and other middleware or back-end systems need to be primarily considered and evolved in terms of features (“We need XML support in the next release”). Use cases are not a natural fit for these applications or the way they need to evolve in terms of market forces. 6.15 Use Cases Are Not Object-Oriented There is nothing object-oriented about use cases; one is not doing object-oriented analysis if writing use cases. This is not a defect, but a point of clarification. Indeed, use cases are a broadly applicable requirements analysis tool that can be applied to non-object-oriented projects, which increases their usefulness as a requirements method. However, as will be explored, use cases are a pivotal input into classic OOA/D activities. 75 USE CASES WITHIN THE UP 6.16 Use Cases Within the UP Use cases are vital and central to the UP, which encourages use-case driven development. This implies:
Requirements are primarily recorded in use cases (the Use-Case Model); other requirements techniques (such as functions lists) are secondary, if used at all.
Use cases are an important part of iterative planning. The work of an itera- tion is—in part—defined by choosing some use case scenarios, or entire use cases. And use cases are a key input to estimation.
Use-case realizations drive the design. That is, the team designs collabo- rating objects and subsystems in order to perform or realize the use cases.
Use cases often influence the organization of user manuals. The UP distinguishes between system and business use cases. System use cases are what have been examined in this chapter, such as Process Sale. They are created in the Requirements workflow, and are part of the Use-Case Model. Business use cases are less commonly written. If done, they are created in the Business Modeling workflow as part of a large-scale business process reengi- neering effort, or to help understand the context of a new system in the busi- ness. They describe a sequence of actions of a business as a whole to fulfill a goal of a business actor (an actor in the business environment, such as a customer or supplier). For example, in a restaurant, one business use case is Serve a Meal. Use Cases and Requirements Specification Across the Iterations This section reiterates a critical idea in the UP and iterative development: The timing and level of effort of requirements specification across the iterations. Table 6.1 presents a sample (not a recipe) which communicates the UP strategy of how requirements are developed. Note that a technical team starts building the production core of the system when only perhaps 10% of the requirements are detailed, and in fact, there is a deliberate delay in continuing with concerted requirements work until near the end of the first elaboration iteration. This is the key difference in iterative development to a waterfall process: Pro- duction-quality development of the core of a system starts quickly, long before all the requirements are known. Observe that near the end of the first iteration of elaboration, there is a second requirements workshop, during which perhaps 30% of the use cases are written in detail. This staggered requirements analysis benefits from the feedback of having built a little of the core software. The feedback includes user evaluation, testing, and improved “knowing what we don’t know.” That is, the act of building 6 – USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT 76 software rapidly surfaces important assumptions and questions that need clari- fication. Table 6.1 Sample requirements effort across the early iterations; this is not a recipe. Timing of UP Artifact Creation Table 6.2 illustrates some UP artifacts, and an example of their start and refine- ment schedule. The Use-Case Model is started in inception, with perhaps only 10% of the use cases written in any detail. The majority are incrementally writ- ten over the iterations of the elaboration phase, so that by the end of elabora- tion, a large body of detailed use cases and other requirements (in the Supplementary Specification) are written, providing a realistic basis for estima- tion through to the end of the project. Workflow Artifact Comments and Level of Requirements Effort Incep 1 week Elab 1 4 weeks Elab 2 4 weeks Elab 3 3 weeks Elab 4 3 weeks Requirements Use-Case Model 2-day require- ments work- shop. Most use cases identified by name, and summarized in a short paragraph. Only 10% writ- ten in detail. Near the end of this iteration, host a 2-day requirements workshop. Obtain insight and feedback from the imple- mentation work, then complete 30% of the use cases in detail. Near the end of this iteration, host a 2-day requirements workshop. Obtain insight and feedback from the imple- mentation work, then complete 50% of the use cases in detail. Repeat, com- plete 70% of all use cases in detail. Repeat with the goal of 80-90% of the use cases clarified and written in detail. Only a small por- tion of these have been built in elaboration; the remainder are done in con- struction. Design Design Model none design for a small set of high- risk architectur- ally significant requiremnts repeat repeat Repeat. The high risk and archi- tecturally signifi- cant aspects should now be stabilized. Implementa- tion Implementa- tion Model (code, etc.) none implement these Repeat. 5% of the final system is built. Repeat. 10% of the final system is built. Repeat. 15% of the final system is built. Project Man- agement SW Develop- ment Plan Very vague esti- mate of total effort. Estimate starts to take shape. a little better... a little better... Overall project duration, major milestones, effort, and cost estimates can now be rationally committed to. 79 CASE STUDY: USE CASES IN THE NEXTGEN INCEPTION PHASE minor use case writing and perhaps requirements workshops, but much less so than in elaboration. By this step, the majority of core functional and non-func- tional requirements should have iteratively and adaptively stabilized. That does not mean to imply requirements are frozen or investigation finished, but the degree of change is much lower. 6.17 Case Study: Use Cases in the NextGen Inception Phase As described in the previous section, not all use cases are written in their fully dressed form during inception. The Use-Case Model at this phase of the case study could be detailed as follows: 6.18 Further Readings The most popular use case guide, translated into several languages, is Writing Effective Use Cases [Cockburn01].7 This has emerged with good reason as the most widely read and followed use case book and is therefore recommended as a primary reference. This introductory chapter is consequently based on and con- sistent with its content. Suggestion: Do not be put off the book by the author’s use of icons for different use case levels, or the early emphasis on levels and use case taxonomy. The icons are optional and minor. And although the discussion of levels and goals may at first seem a diversion to those new to use cases, those who have worked with them for some time appreciate that the level and scope of use cases are key practical issues, because their misunderstanding is a common source of complication in use case modeling. “Structuring Use Cases with Goals” [Cockburn97] is the most widely cited paper on use cases, available online at www.usecases.org. Use Cases: Requirements in Context [GK00] is another useful text. It emphasizes the important viewpoint—as the title states—that use cases are not just Fully Dressed Causual Brief Process Sale Handle Returns Process Rental Analyze Sales Activity Manage Security ... Cash In Cash Out Manage Users Start Up Shut Down Manage System Tables ... 7. Note that Cockburn rhymes with slow burn. 6 – USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT 80 another requirements artifact, but that they are the central vehicle that drives requirements work and information. Another worthwhile read is Applying Use Cases: A Practical Guide [SW98], written by an experienced use case teacher and practioner that understand and communicate how to apply use cases in an iterative lifeycle. 81 UP ARTIFACTS AND PROCESS CONTEXT 6.19 UP Artifacts and Process Context As illustrated in Figure 6.5, use cases influence many UP artifacts. Figure 6.5 Sample UP artifact influence. Vision Supplementary Specification Software Architecture Doc. Glossary Domain Model Requirements Project Management Business Modeling Design Sample UP Artifacts Partial artifacts, refined in each iteration. Test Test Plan Software Dev. Plan Design Model ** Use-Case Model terms, attributes requirements terms, attributes, validation relationships requirements, constraints requirements, priorities acceptance tests key scenarios, requirements requirements, I/O events