LEM THEMEN fm PECES taney ee oe ee at Sadine mmm RUN RAMS GEnNR RANE SSNDRNTSLONONAINEModeling System Requirements with Use Cases Chapter Preview and Objectives In this chapter you will learn about the tools and techniques necessary to perform use- ccase modeling to document system requirements. Capturing and documenting system requirements have proved to be critical factors in the outcome of a successful information systems development project. Documenting the requirements from the perspective of the users in a manner that they can understand promotes user involvement, which greatly en- ‘hances the probability for the success of the project. You will know that you understand requirements use-case modeling when you can: Describe the benefits of use-case modeling. Define actors and use cases and be able to identify them from context diagrams and other sources. 1 Describe the four types of actors. 1 Describe the relationships tat can appear ona use-case model diagram. 1 Describe the steps for preparing ause-case mode. 1 Describe how to construct use-case model diagram. 1 Describe the varios sections ofa usecase narrative and be able to prepare one. 1 Define the purpose of the use-case ranking and priority matrix and the use-case dependency diagram.244 Part wo Systoms Anelysis Methods Introduction ) Following the joint requirements planning GRP) meeting that was held as one task of the requirements analysis phase, the SoundStage Member Services system project team has built list of use cases that specify all the required functionality of the sy tem. At first each use case was just a simple verb phrase (such as“Place New Order”) that described something one or more users wanted to do with the system. Next, each use case was documented with a narrative describing in detail the desired inter action between the user and the system. Then Bob Martinez and other systems ana- Iysts held a series of interviews with users to verify those use-case narratives. Finally they are analyzing which use cases are the highest priority to the system. Bob's boss, Sandra, says that will identify for them what functionality has to be included in the first build cycle of the system. The plan is to take those highest priority use cases into the logical design and later phases and implement a working version 1.0 ofthe system on schedule and within budget. An Introduction to Use-Case Modeling ) (One of the primary challenges of vital importance to any information systems devel- ‘opment team, and especially the systems analyst, is the ability to elicit the correct and necessary system requirements from the stakeholders and specify them in a manner that is understandable to the stakeholders in order for those requirements to be veri fled and validated. In fact, this has been the case for many years, as the distinguished author Fred Brooks wrote in his famous 1987 article: ‘The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to ma- chines, and to other software systems. No other work so cripples the resulting system if done wrong. No other partis more difficult to rectify later. ‘The information technology community has always had problems trying to specify requirements, especially functional requirements, to users. In the past we have used tools such as data models, process models, prototypes, and requirements specifications that we understood and were comfortable with, but they were hard to understand for any user who wasn't educated in software development practices. Because of this, many development projects were and still are plagued with scope creep, cost overruns, and schedule creep problems. Very often systems are devel- oped and deployed that really don’t satisfy the user's needs. Some are shelved and not used at all, and a large percentage are canceled even before the development effort is complete. A very well known research firm, the Standish Group, studied 23,000 IT applications in 1994, 1996, and 1998." As shown in Figure 7-1, the 1998 study found that only a little more than a quarter of the projects in 1998 were suc- cessful (on budget, on time, and included all features). More than a quarter of them failed (canceled before completion). little less than half were what Standish con- sidered challenged—the project was complete and operational, but it was com- pleted either over budget, over the time estimate, or without all the features specified by the users. The good news reflected in these studies and others is that the ways and means we are using to develop information systems are improving, ‘The software development industry has learned that in order to successfully plan, ‘tye Seek Group Itrata ne, "CHAOS: A Recipe ft Seen” (ectonic veo), 199, Ratcwed Dect 5, 200, fom rr igo ca /ntnlret hace 198 pu. The th Group est knw for independent Pity rene sab of he I daoModeling System Requirements with Uso Cases Chapter Seven 245 Project Success Rate FIGURE 7-1 100% Project Success cox Rates As Reported 0% TH Succeeded 40% 1 Challenged i Failed 20% 0% 1008 1996 "1908 Yeor sey dean conte an dpa maton sen, he te aa Cee ee a ee Se tee ee eset eee on the users of the system, the analyst can concentrate on how the system will be evelopment a process of used and not how it will be constructed. Use-case modeling is an approach that S/S devopmentbased frelitates usage centered development on understanding the road ree sie ie Neneorkednockae anyon wien cognate Oe et an Seats Jape r edpopa een cect cao will learn throughout the remaining chapters of this book how use-case modeling cee ee en saan SEAT ee etc neal ieansinaaige oe Imei dckndciow een eg, Use-case modeling was originally conceived by Dr. Ivar Jacobson in 1986 and jne gents and how tte aye suntan an nna nt oneroncns sma begnces Sareea ete saa Bi kemom dete mse incon acer nasou whine mecca acolrsenpea eaves arene Mana eres tanrareds hes ouhicaas wc hehe acinar wre cgune oars nd oka ees cee ee ee arma cian omtcce sees ftontese Se ee ee scat wt onc gas ming in nage wen ra athe sesh eh ene + Provides a tool for capturing functional requirements. ‘+ Assists in decomposing system scope into more manageable pieces. + Provides a means of communicating with users and other stakeholders con- cerning system functionality. Use cases present a common language that is easily understood by various stakeholders *+ Provides a means of identifying, assigning, tricking, controlling, and managing ‘system development activities, especially incremental and iterative development. + Provides an aid in estimating project scope, effort, and schedule. + Provides a baseline for testing in terms of defining test plans and test cases, Provides a baseline for user help systems and manuals as well as system development documentation, Provides a tool for requirements traceability Provides a starting point for the identification of data objects or entities. Provides functional specifications for designing user and system interfaces. Provides a means of defining database access requirements in terms of adds, ‘changes, deletes, and reads. + Provides a framework for driving the system development project.246 Part wo Systoms Anelysis Methods System Concepts for Use-Case Modeling ) ‘usecase diagram adia- ‘ram that depicts the inter- Aaotons betwaen the system and external systems and Users. In other words, it ‘graphically ascribes who wil use the systam and in vwhatways the user expects to interact wth the system, ‘functional decomposition the actof breaking a system ito subcomponents. ‘use-case narrative a textual description ofthe business ever and how ‘the user wil iteract withthe system to accomplish the task. ‘use case a behaviorally related sequence of stops (@ scenario), both automated ‘and manual, forthe purpose cof completing a single business task. FIGURE 7-2 Sample Use-Case ‘Model Diagram ‘There ase two primary artifacts involved when performing use-case modeling. The first is the use-case diagram, which graphically depicts the system as a collection of use cases, actors (users), and their relationships. This diagram communicates ata high level the scope of the business events that must be processed by the system. An ex- ample of a usecase diagram is shown in Figure 7-2. It shows each system function, or business event (in the ellipses), and the actors, or system users, who interact with those functions. As you can see in Figure 72, actors can be placed on either side of the set of usecase figures and can interact with one or more use cases. The use-case diagram is extremely simple, But it begins an important process called functional decomposition, the act of breaking a system apart into its subcomponents. It is im- possible to understand the entire system at once, but it is possible to understand and specify each part of the system, ‘The second artifact, called the use-case narrative, fillsin the details of each busi- ness event and specifies how the users interact with the system during that event. The uuse-case narrative will be discussed in detail later in the chapter. > Use Cases Use-case modeling identifies and describes the system functions by using a tool called use cases. Use cases describe the system functions from the perspective of external users and in a manner and terminology they understand, To accurately and thoroughly accomplish this demands a high level of user involvement and a subjectmatter expert ‘who is knowledgeable about the business process or event. Use cases are represented graphically by a horizontal ellipse with the name of the use case appearing above, below, or inside the ellipse. A use case represents a single goal of the system and describes a sequence of activities and user interactions in try- ing to accomplish the goal. The creation of use cases has proved to be an excellent technique to better understand and document system requirements. use case itself is not considered a functional requirement, but the story (scenario) the use case tells consists of one or more requirements Use cases are initially defined during the requirements stages of the life cycle and will be additionally refined throughout the life cycle. During requirements system © © betor 8‘Modeling Systom Requirements with Use Cases discovery, use cases are used to capture the essence of the business problems and to model (at a high level) the functionality of the proposed system. Additionally, they are the starting point for identifying the data entities (covered in Chapter 8) or objects of the system (covered in Chapter 11). During requirements analysis the use cases are refined to model usage of the system in more detail. In other words, they are updated to specify what the users are trying to accomplish and why. These use cases aid in the definition of any prototypes or user interfaces. During design the use cases are refined to model how the users will actually use the system with regard to any interface and system constraints (covered in Chapter 18). These types of use cases aid in identifying object or system behavior and in designing in- terface and code specifications, as well as serve as the plan for testing the system. In construction, use cases aid developers in programming and testing. These use cases also serve as the baseline for preparing any user and system documentation, plus they serve as tools for user training. And, because use cases contain an enor. ‘mous amount of system functionality detail, they will be a constant resource for validating the system. > Actors Use cases are initiated or triggered by external users called actors. An actor initi- ates system activity, a use case, for the purpose of completing some business task that produces something of measurable value. Let's use the example of a college student enrolling for the fall semester's courses. The actor would be the student, and the business event, or use case, would be Enrolling in Course, An actor repre- sents 2 role fulfilled by a user interacting with the system and is not meant to por- tray a single individual or job title. In fact, an actor doesn’t have to be human. It can be an organization, another information system, an external device such as a heat sensor, or even the concept of time (which will be discussed a litte later). An ac- tor is represented graphically as. stick figure labeled with the name of the role the actor plays tis important to note that there are primatily four types of actors: + Primary business actor—the stakeholder that primarily benefits from the ‘execution of the use case by receiving something of measurable or observ. able value. The primary business actor may or may not initiate the business ‘event. For example, in the business event of an employee receiving a pay- ‘check (something of measurable value) from the payroll system each Friday, ‘the employee does not initiate the event but is the primary recipient of the something of value. + Primary system actor—the stakeholder that diectly interfaces with the sys- ‘tem to initiate or trigger the business or system event. Primary system actors ‘may interact with primary business actors for the purpose of using the actual system. They facilitate the event through the direct use of the system for the benefit of the primary business actor. Examples include a grocery store ‘clerk who scans the items for the customer buying groceries, a telephone ‘operator who gives directory assistance to a customer, and a bank teller who processes a banking transaction. The primary business actor and primary system actor may be the same person for events where the business actor interfaces with the system directly—for example, a person reserving a rental car via a Web site. + External server actor—the stakeholder that responds to a request from the use case (e.g., a credit bureau authorizing the charging by a credit card), + External receiver actor—the stakeholder that is not the primary actor but receives something of measurable or observable value (output) from the use case (e.., a Warehouse receiving a packing order to prepare a shipment after a customer has placed an order) Chaptor Sovon 247 ‘actor anything that needs to interact with the system to ‘xchange information ‘Actor Symbol248 Part wo temporal event asysiom ‘event thats triggered by time, ‘association a relationship between an actor and a use case in which an interaction ‘oours between them, ‘extension use case ause caso consisting of stops ex- ‘tracted from a more complex use case inorder to simply the original case and thus extend ts functionality. The extension use case avtends the functionality of the original FIGURE 7-3 Example of an ‘Association Relationship Systoms Anelysis Methods In many information systems there are business events triggered by the calendar or the time on a clock. Consider the following examples: + ‘the billing system for a credit card company automatically generates its bills on the Sth day of the month (billing date). + Abank reconciles its check transactions every day at 5 PM. + On a nightly basis a report is automatically generated listing which courses have been closed to enrollment (no open seats available) and which courses are still open, ‘These events are examples of temporal events. Who would be the actor? All of the events listed above were performed (or triggered) automatically—when it became a certain date or time. Because of that we say the actor of a temporal event is time. > Relations! ‘A relationship is depicted as a line between two symbols on the use-case diagram. The ‘meaning of the relationships may differ depending on how the lines are drawn and ‘what types of symbols they connect. In the following sections we will define the different relationships found on a use-case diagram, Associations _A relationship between an actor and a use case exists whenever the use case describes an interaction between them. This relationship is referred to as an association. As indicated in Figure 7-3, an association is modeled asa solid line con- necting the actor and the use case. An association that contains an arrowhead on the end touching the use case (@) indicates the use case was imitated by the actor on the other end of the line. Associations without arrowheads (@) indicate an interaction be- ‘ween the use case and an external server of receiver actos. When any actor is assoc ated with a use case, we say the actor communtcates with the use case, Associations may be bidirectional of unidirectional, Extends A use case may contain complex functionality consisting of several steps making the use-case logic difficult to understand. For the purpose of simplifying the use case and making it more easily understood, we can extract the more come plex steps into their own use case. The resulting use case is called an extension ‘use case in that it extends the functionality of the original use case. The relation. ship between the extension use case and the use case it is extending is called an extends relationship. A use case may have many extends relationships, but an ex- tension use case can be invoked only by the use case it is extending. As depicted Jn Figure 7-4, the extends relationship is represented as an arrowheaded line (Gither solid or dashed) beginning at the extension use case and pointing to the use case itis extending. Each extends relationship line is labeled *<>" Generally extension use cases are not identified in the requirements phase but in the analysis phase. fey et (club Member Dietibution Center‘Modeling System Requirements with Use Cases Extension Use i oe ‘Generate Warehouse’ a toeed Coe ons eas Order Uses (or Includes) Very commonly, you may discover two or more use cases that perform steps of identical functionality. It is best to extract these common steps into theie own separate use case called an abstract use case. An abstract use case represents a form of “reuse” and is an excellent tool for reducing redundancy among use cases. An abstract use case is available for referencing (or use) by any other use ‘case that requires its functionality The relationship between the abstract use case and the use case that uses tis called a uses relationship (some use-case modeling tools re- fer to itas an includes relationship). The uses relationship as presented in Figure 75 is depicted as an arrowheaded line (either solid or dashed) beginning at the original use case and pointing to the use case it is using, Each uses relationship line is labeled “>” Generally abstract use cases are not identified in the requirements phase but in the analysis phase. Depends On As the project manager of lead developer, it is very helpful to know which use cases have a dependency on other use cases in order to determine the se- quence in which use cases need to be developed. Using the banking business as an example, the use case Make a Withdrawal cannot be performed until the use case Make a Deposit has been executed, and that use case cannot execute until the use case Establish Bank Account has occurred. Because of these dependencies the devel ‘opment team will most likely choose to develop the use case Establish Bank Account first, the Make a Deposit use case second, and the Make a Withdrawal use case third for usability and testing purposes. A use-case diagram modeling the system's use-case dependencies using the depends on relationship provides a model that is an excel- lent tool for planning and scheduling purposes. The depends on relationship as Abstract eae Use Case Chapter Sovon 249 FIGURE 7-4 ‘abstract use case aus case that reduces redundancy among two or more other use cass by combining the com mon slaps found in thase cases. Another usa case uses or includes the abstract use ‘depends on a lationship between use cases indicating ‘that one use case cannet be performed uni another use case has been performed. FIGURE 7-5 Example of a Uses Relationship250 Parttwo FIGURE 7-6 Example of a inheritance in use cases, a relationship between actors ceatadto simpli the drawing \when an abstract actor inher- its the role of mulipl real actors FIGURE 7-7 Example of an Inheritance Relationship Systoms Anelysis Methods Cs ‘Account Cree ot ‘presented in Figure 7.6 is depicted as an arrowheaded line (either solid or dashed) be- ‘ginning at one use case and pointing to a use case it is dependent on. The depends on, relationship line is labeled “<" Inheritance When two of more actors share common behavior—in other words, they can initiate the same use case—it is best to extrapolate this common behavior and assign it to a new abstract actor in order to reduce redundant communication ‘with the system. For example, a library patron is a card-carrying member who is au- thorized to “Search library inventory” as well as “Check out books’ from the library. Since many lbraties are public institutions, they welcome visitors to use their services onsite such as“Search library inventory.’ but the visitors are aot allowed the extended services (such as “Check out books”) that are reserved for the patrons. By creating an abstract actor called customer, from which patron and visitor will inherit, ‘we have to model only once the relationship initiating the use case Search Library Inventory. In the usecase diagram the inheritance relationship is depicted by the type of arrow shown in the“After" section of Figure 77. srs sc 5 @& 7 i Visttor "Search library \ 9 Before After‘Modeling System Requirements with Uso Cases Chapter Seven 251 (The Process of Requirements Use-Case Modeling ‘The objective of constructing the requirements use-case model isto elicit and analyze enough requirements information to prepare a model that communicates what is re quired from a user perspective but is free of specific details about how the system will be built and implemented. Following this approach will later produce a design that is more robust and less likely to be impacted by change. But to effectively esti mate and schedule the project, the model may need to include preliminary “system implementation assumptions” to aid in those activities. Itis critical that the analyst does not slip into a state of analysis paralysis when preparing this model. Speed is the key. Not all of the facts will be learned during this phase of the life cycle, but by utilizing iterative and incremental development, the methodology allows the in- troduction of new requirements later in the project without seriously impacting the deployment of the final solution. The steps required to produce this model are the following: 1. Identify business actors 2, Identify business requirements use cases, 3. Construct use-case model diagram. 4, Document business requirements use-case narratives. > Step 1: Identify Business Actors Why identify actors first? By focusing on the actors, you can concentrate on how the system will be used and not how it will be built. Focusing on the actors helps to re fine and further define the scope and boundaries of the system. Actors also determine the completeness of the system requirements? A benefit of identifying actors first is that doing so identifies candidates we can later interview and observe to complete the use-case modeling effort. Plus, those same individuals can be used to verify and validate the use cases when they are finished, ‘Where do you look for potential actors? The following references are excellent A contest diagram that identifies the scope and boundaries of the system. Existing system documentation and user manuals. ‘Minutes of project meetings and workshops. Existing requirements documents, project charter, or statement of work, ‘When looking for actors, ask the following questions: ‘Who or what provides inputs to the system? ‘Who or what receives outputs from the system? Ase interfaces required to other systems? ‘Are there any events that are automatically triggered at a predetermined time? ‘+ Who will maintain information in the system? Actors should be named with a noun or noun phrase: ‘When you identify an actor, create a textual definition of that actor according to the users’ perspective and using their terms. Figure 7-8 is a template of an actor glos sary that can be used to document actors. This example contains a partial listing of the SoundStage Member Services System's actors. "Yt Asmout ad Grille Mile Adonce Ut Case Modeling (Both: Adie Wee, 2000252 Parttwo FIGURE 7-8 Partial List of SoundStage ‘Member Services System’s Actors business requirements lise case a use case created during requirements analysis. to capture the intoracons be- ‘ween a user and the system {ee of technology and imple- ‘mentation details aloo called an essential use casa Systoms Anelysis Methods Actor Glossary Term Description Potential ‘An individual or corporation that submits a subscription member ‘order in cer to join the club, Qu member ‘An individual or corporation that has joined the club via en agreement Pastrmember ‘Atype of member that has fuliled the ageement ‘Obligation but hasnt placed an orler within the last six months tut is stil in good standing. Marketing (Organization responsible for creating promotion and subscription programs andl generating sales fr the ‘company. (Organization responsible for provcing point of contact for SoundStage Entertainment customers in ters of ‘2greements and orders. Enity that houses and maintains Soundstage Entertainment product inventory and processes customer shipments and retums. (Organization responsible For processing customer payments and biling as well as maintaining customer ‘account information. ‘Actor concept responsible for tiggering termporal events > Step 2: Identify Business Requirements Use Cases A typical information system may consist of dozens of use cases. During require. ments analysis we strive to identify and document only the most critical, complex, and important ones, often referred to as essential use cases because of time and cost considerations. A business requirements use case captures the interactions with the user in a manner that is free of technology and implementation details, Since a use case describes how a realworld actor interacts with the system, an excellent technique for finding business requirements use cases is to examine actors and how they will use the system. When looking for use cases, ask the following questions: ‘What are the main tasks of the actor? ‘What information does the actor need from the system? ‘What information does the actor provide to the system? Does the system need to inform the actor of any changes or events that have occurred? + Does the actor need to inform the system of any changes or events that have occurred? Agnin, a context diagram is an excellent source for finding potential use cases. Context diagrams were discussed in Chapter 5.'They come from traditional process modeling (Chapter 9) but are useful even for projects that take an objectoriented ap- proach. Let's examine the Soundstage Member Services System's context diagram in Figure 7-9. We can identify potential use cases by looking at the diagram and identify- ing the primary inputs and outputs of the system and the external parties that submit and receive them. The primary inputs that trigger business events (for example, Submit Member Order) within the organization are considered use cases, and the external parties that provide those inputs are considered actors (for example, Cub Member). {tis important to note that inputs that are the result of system requests do‘Modeling Systom Requirements with Use Cases Chapter Seven Member Services Context Diagram coun tenver anstng nur azz (ace payers a rca Carma nq Responses —— - Sere Send ronnion oer Genoa Varun —— rarer pers tionber ‘Siahepore sin susten ore ‘opp or nar << ser sunsctten omer — sens pacing ——satzaree | << retazon sepone ‘itouton eco, arenes) Nera epons + aah 253 € IGURE 7-9 SoundStage Member Services System Context Diagram. not indicate a separate use case—such as a credit card company responding to an authorization request or, as presented in Figure 7-9, the Accounts Recefvable actor responding with Member Credit Status Information. Use cases are named with a verb phrase specifying the goal of the actor, such. as Submit Subscription Order. Use cases that are temporal events are usually254 — Parttwo Systoms Anelysis Methods identified as a result of analyzing the key outputs of the system. For example, any output that is generated on the basis of time or a date, such as monthly or annual reports, is considered a use case, and the actor, as your recall, is time. In Figure 7-9 let's assume that one of the various reports that Member Services receives is a 10-30-60-day default agreement report that is automatically generated on 2 daily basis. Since the generation of the report is triggered by time, a use case is required to process the event, and we would name it Generate Daily 10:30-60-Day Default Agreement Report. Its important to note that many times individual reports are not, listed on a context diagram because they are too numerous and would clutter the diagram and make it hard to read. Itis the system analyst's responsibility to research ‘with the appropriate stakeholders the type of outputs they receive and their char- acteristics, in terms of volume, frequency, and triggering mechanism, in order to identify “hidden use cases” Figure 7-10 isa template of a use-case glossary that can be used to document use cases, This example contains a partial listing of the SoundStage Member Services System's use cases and actors identified from the context diagram as well as from other sources, > Step 3: Construct Use-Case Model Diagram Once the use cases and actors have been identified, a use-case model diagram can be used to graphically depict the system scope and boundaries. The use-case FIGURE 7-10 Partial List of SoundStage Member Services System's Use Cases Use-Case Glossary Use-Case Name Use-Case Description Participating Actors and Roles Submit Subscription | This usecase describes the event of a + Potential mambor (primary business) Order potenti member requesing fo jin the dub_| « Distibution Center (ectornal receiver) by subscribing, ("Take any 12 CDs for ene penny and agree to buy 4 more at regular prices within lwo years.") ‘Submit Subscription | This use case describes the event ofa past | * Past member (primary business) Renawal Order ‘member requesting fo rejoin the cub by | « Disirbuion Canter (axtrnal receiver) subscribing. ("Take any 12 CDs for ona penny and agree to buy 4 more at regular prices wihin two years.") Submit Mamber This us case describes the event ofa dub | * Club member (primary business) Profile Changes ‘member submiting changes this or her profile for such things as postal address, ‘email address, privacy codes, and order preferences. Place New Order | This use case describes the event of a ‘+ Club mambo (primary business) dub member submiting an order for ‘* Distribution Center (external receiver) ‘SoundStage products. '* Accounts Payoble/Receivable (external server) Revise Order This vse case describes the event ofa dub | © Club member (primary business) ‘member revising an order previously * Distibuton Canter (actrnal receiver) pplaced. (Order must not have shipped.) ‘+ Accounts Payable/Receivable {external server)‘Modeling System Requirements with Uso Cases Chapter Seven 255 FIGURE 7-10 Concluded > Cancel Order This use case describes the event of a dub ‘member cancsling an order previou cal (Ordo tot hore oped * Club member (primary business) + Distribution Center (extemal receiver) ‘+ Accounts Payaible/Receivable (external server] ‘Make Product Inquiry This use case describes the event of a dub member viewing products for possible purchase. (Driven by Web accoss requirement) * Club member (primary business) number of products oufined when Sasa rest oa Se members who are 10 days past dve, 30, days past due, and 60 days past due. ‘Mako Purchase This use case describes the event ofa dub | * Club member (primary business) History Inquiry member viewing her or his purchasing history (Three-year fim limit) Establish New Member | This use case describes the event of he | * Markelng (primary business) Subscription Program | marketing depariment establishing a new membership subscription plan to entice new Submit Subscription | This us case describes the event ofthe | * Marking (primary business) Program Changes | marketing depariment changing a subscription plan for dub members (o. ‘extonding the fulfilment period). Establish Past Mamber | This use case describes the event ofthe | * Marketing (primary business), Resubscription marketing depariment estblshing Program resubscription plan to lure back former members. Submit Member This use case describes the event fhe | © Marketing (primary business) Profile Changes marketing depariment establishing a new promotion plan fo entice acve and inactive members fo order the product. (Nols: A promotion features specific tiles, usuclly rw, thatthe company i rying sell ata special pric. These promotions are inlegrated into a caicog sent (or communicated) fo all members.) Revise Promotion | This use case describes the event ofthe | © Markelng (primary business) marketing depariment revising « promotion. ote Gonerate Daily This use case describes the event of a report | * Time initiating acor) 10-30-60-Day Default | that is gonerated on a daily basis folist he | « Member Services (primary"—axlernal ‘Agreement Report | members who have not lille their receiver) agreement by purchasing the required256 PartTwo Systoms Analysis Mothods Order Subsystem ‘Subscription Subsystem] a QS ao Ss @ roams] NN a @.) oa ee (Fieure 7-11 SoundStage Member Services System's Use-Case Model Diagram ) diagram for the use cases listed in Figure 7-10 is shown in Figure 7-11. It was cre- ated using Popkin Software's System Architect and represents the relationships be- tween the actors and the use cases. In addition, the use cases have been grouped into business subsystems. The subsystems (UML's package symbol) represent logi- cal functional areas of business processes. The portioning of system behavior into subsystems is very important in understanding the system architecture and is a key to defining your development strategy—which use cases will be developed first and by whom. We have labeled the associations between the actors and the use cases “initiates” because the tool did not support lines with arrowheads at the time. We also didn't include the external server and receiver actors because of space limitations. To model all the use cases of a particular system may require the creation of several use-case model diagrams—as you recall, a system may contain dozens of use cases. In that event you may want to create a separate use-case ‘model diagram for each subsystem. > Step 4: Document Business Requirements Use-Case Narratives ‘When you are preparing the narratives, itis wise to first document them at a bigh evel to quickly obtain an understanding of the events and magnitude of the system. ‘Then return to each use case and expand it to a fully documented business require- ‘ment narrative. Figure 7-12 represents a requirements use-case narrative for the‘Modeling Systom Requirements with Uso Cases Chapter Seven 257 Member Services System Author (5): Date: @ Version: ° Unease Nomen | Pace New Orcer_ © Use-Caze Type Urecese iD: | wss-AUCO.0 © Business Requirements: oj Priority High ° Source: Requirement — MESH. O Primary Business | Cumember_@ Actor! Other + Warehouse ecemal receiver) Participating Accounts ReceWvable (extemal server) © Actors: Other + Mating — Interested insales activity in oder to plan new promotions: Interested © © Procurement — Interested in sales activity in order to replenish inventory. ‘Stakeholders: © Management — Interested in order activity in order to evaluate company performance and customer (member satsfaction, Deseription: | This use case describes the event of a cldb member submiting ane orde er Soundstage products Te memba’s demoaraphic information as well as his or her account standings validated, Once the ® [products are verified as being in stock, a packing order is sent to the warehouse for it to prepare the Shipment. For ery product notin stock, aback ordi created, On completion, he member wil be sent an order corfiraton (Fieure 7-12 High-Level Version of Place New Order Use-Case Narrative ‘Member Services System's Place New Order use case, Notice that it tersely describes the event, which includes the following items: @ Author—The names of the individuals who contributed to the writing of the use case and who provide a point of contact for anyone requiting additional information about the use case. Date—The date the use case was last modified Version—The current version of the use case (€., 1.0) Use-case name—The use-case name should represent the goal that the use case is trying to accomplish. The name should begin with a verb (e.g., Enter New Member Order) © Wse-case type—in performing usecase modeling, business requirements tse cases, which focus on the strategic vision and goals of the various stakeholders, ‘are constructed first. This type of use case is businessoriented and reflects a hhighlevel view of the desired behavior of the system. It is free from technical details and may include manual activities as well as the activities that will be ‘automated. Business requirements use cases provide a general understanding of the problem domain and scope but don't include the necessary detail to com- ‘municate to developers what the system should do, © Use-case 1D—An identifier that uniquely identifies the use case © Priority—The priority communicates the importance of the use case in terms of high, medium, or low. © Source—The source defines the entity that triggered the creation of the use case. This could be a requirement, a specific document, or a stakeholder. © Primary business actor—The primary business actor is the stakeholder that primarily benefits from the execution of the use case by receiving something of measurable or observable value. >258 Part Two Systoms Anelysis Methods © Other participating actors—Other actors that participate in the use case to accomplish its goal include initiating actors, facilitating actors, server/receiver actors, and secondary actors. Always include the manner in which the actor participates. ® Interested stabebolder(s)—A stakeholder is anybody who has a stake in the development and operation of the software system. An interested stakeholder is a person (other than an actor) who has a vested interest in the goal of the use case. © Description—A short summary description that consists of a couple of sentences outlining the purpose of the use case and its activities Documenting the Use-Case Course of Events For each hightlevel use case iden- tified, we must now expand it to include the use case’s typical course of events and its alternate courses. A use case's typical course of eventsis a step-by-step description starting with the actor initiating the use case and continuing until the end of the busi ness event. In this section we include only the major steps that occur the majority of the time (its typical course). The alternate course documents the exceptions or the conditional branching of the use case. Figure 7-13 represents a requirements use-case narrative for the Member Services System's Place New Order use case, Notice that it includes the following additional items: © Precondition—A precondition is a constraint on the state of the system before the use case can be executed. Typically this refers to another use case that must be previously executed, @ Trigger—The trigger is the event that initiated the execution of the use case. This often is a physical action, such as a customer walking up to a sales counter or a check arriving in the mail. Time can also trigger use © 1ypical course of events—The typical course of events is the normal sequence of activities performed by the actor(s) and the system in order to satisfy the goal of the use case. These include the interactions between the system and the actor and the activities performed by the system in response to the interactions. Note that the actions of the actor are recorded in the left hand column while the actions of the systems are recorded in the right hand column. © Alternate courses—Alternate courses document the behaviors of the use case if an exception or variation to the typical course occurs. This can happen when a decision point occurs within the use case or an exception ‘occurs that requires additional steps outside the scope of the typical © Conclusion—The conclusion specifies when the use case successfully ends—in other words, when the primary actor receives something of measurable value. © Postcondition—A postconcition is a constraint on the state of the system after the use case has been successfully executed. This could be data recorded in a database or a receipt delivered to a customer. © Business rules—Business cules specify policies and procedures of the business that the new system must abide by. This could include the calcula. tion of shipping charges or rules for granting credit terms. © Implementation constraints and specifications—Implementation constraints and specifications specify any nonfunctional requirements that may impact the realization of the use case and may be helpful in any architectural planning and scoping. Items that may be included are security specifications, interface requirements, and so on. © Assumprions—Any assumptions that were made by the creator when docu- ‘menting the use case. © Open issues—Any questions or issues that need to be resolved oF investi- gated before the use case can be finalized.‘Modeling Systom Requirements with Uso Cases Chapter Seven 259 ‘Member Services System Author(s): Date: Version: UseCase Names| Place New Order Use-Case Type Usetase ID: | MSS-BUCO0R.00 Business Requirements: Priority: High Source: Requirement — MSS-R1.00 Primary Business | Club member Actor: ‘Other ‘> Warehouse (extemal recewver) Participating ‘+ Accounts ReceWable (extemal server) Actors: ‘Other ‘> Marketing — Interested in sales actviy inorder to plan new promotions, Interested ‘* Procurement — Interested in sales activity in order to replenish ventory eee ‘+ Management — interested in order activity in order to evaluate company performance and customer (member) satisfaction Description: | This use case describes the event of club member suomiting a nav order fer SoundStage produc The member's demographic information as well s his or her account standing i validated, Once the products are verified as being n stock, a packing order I sent to the warehouse for it to prepare the shipment. For ary product notin tock, a backorce is created. On completion, the member will be sent an order confimation, Precondition ©] The patty Gndividhal or company )avomiting the order mustbe a member. Tigger © Ts use case is intiated wihen a new order is submited, Typkeal Course ‘Aetor Action ‘System Response of Events: Step 1: The cho member ‘Step & The system responds by veiying that al required provides his orher demographic | information has been provided, information aswell as order and | Step 3: The system verifies the club member's demographic Payment information information agaiet what has been previously recorded. ‘Step 4: For each product oncered, the system validates the Product identity. ‘Step 5: For each product ordered, the system vetfes the product avail, Step 6: For each availble proc, the system determines the price to be chargedto the club member. Step 7: Once all ordered products are processed, the system determines the total cost of the order, ‘Step 8: The system chects the status ofthe club member's account. ‘Step 9: The system validates the club member's payment provided, ‘Step 10: The sjstem records the order information and then releases the order tothe appropriate dlsttoution certer (warehouse) to be fille, Step 11: Once the order is processed, the system generates an ‘order confirmation and sends it to the club member, (Fieure 7-13 Expanded Version of Place New Order Use-Case Narrative Business requirements use cases are excellent tools in that they describe the events the organization must process and respond to, but they lack information re- garding the interfaces and the activities that are targeted to be automated by informa- tion technology. Later, in Chapter 11, you will learn how to evolve the use case to include technical and implementation details260 Part Two Systoms Anelysis Methods “Aikemate: Courses: “AltStep The club membarhas not provided al the information necessay to process the order. The ‘lub member is notified ofthe alsctepancy and prompted to resubmit. AltStep 3: Ifthe clubs member information provided is diferent fom what was previously recorded, \etfy what was recorded is curtent, then upclate the clup member information accordingly. ‘AltStep 4: Ifthe prodlict information the club member provided does not match ary of SoundStage's Products, notiy the clu member ofthe discrepancy and request clafcation, Alttep 5: Ifthe quantity ordered ofthe product isnot avalable, a back order is create. ‘Alt-Step &: Ifthe status of the club member's account isnot in good standing, record the order information and place it in hod status. Notify the club member ofthe account status and the reason the ‘orders being held, Terminate use case. AltStep 9: Ifthe payment the club member provided (credit card) cannot be validated, notify the club member and request an atemative means of payment. the club member cannot provide an altemate means, cancel the order and terminate the use case. Conclusions ©] Tris use case concludes when the cle memiber receives a confirmation ofthe orden Postcondltfons | The order has been recorded and ifthe ordered products were avalabl, they were released. Foray © cracuct not avaiable aback order has been created Business Rules: | + The cub member responding toa promotion ora meribar sig credits may affect the pce of cach erderediter ©) casherchectswill not be accepted with the orders. If provided, they willbe retunedito the cub member, +The cio member iste for products only when they are shipped. Implementation | + GUI to be provided for Member Savices associat, and Web screen fo be provided for cub Constraints and member. Specifications: O| ‘Assumptions: ©| Macurement will benolified of back orders by a dally repor (Geparate Use Case) Open sues Gy ‘Need to defemine how cisiieution centars are assigned, G GURE 7-13 Conclued > Use Cases and Project Management ) usecase ranking and priority matrix a tool used {evaluate use oases and datermine thir pron. As you recall, one of the benefits of usecase modeling is thatthe use-case model can be used to drive the entire system development effort. Once the business requirements use- case model is complete, the project manager or systems analyst uses the business re- quirements use cases to plan (estimate and schedhl) the build cycles of the project. This 4s especially crucial when applying the iterative and incremental approach to software development. A build cycle, which consists of the system analysis, design, and construc- tion activities s scoped on the basis of the importance of the use case and the time it takes to implement the use case. In other words, one or more use cases will be devel ‘oped in each build cycle. For a use case that is too large of complex to be completed in cone build cycle, a simplified version will be implemented initially, followed by the fall version in the next build cycle. To determine the importance of the use cases, the project ‘manager of systems analyst will complete a use-case ranking and evaluation matrix and construct a usecase dependency diagram with input from the stakeholders and the de- velopment team. You will learn how to use these tools in the following sections > Ranking and Evaluating Use Cases In most software development projects the most important use cases are developed first. In order to determine the priority of the use cases, the project manager uses a tool called the use-case ranking and priority matrix. This matrix is completed‘Modeling Systom Requirements with Use Cases Chapter Sovon 261 co Err) reed Counce Oe Pei akon 1[/2][3 [4][s]6 ‘Submit Subscription Order ss [5 ss | 9 [aa] 7 Place New Order epeps |!ps | s | 7 | ven [2 “Make Product Inquiry 74 Tp? [4 7 6 | tow [3 Establish New Member +ps]>s | s ps ps | 37 | xian [7 Subscription Program Generate Daily 10-30-60-Day Ta a 7 6 | ew [3 Default Agreement Report Revise Order Spe ype fs pe | + |e [ medium | 2 (Fieure 7-14 Partial Use-Case Ranking and Priority Matrix with input from the stakeholders and the development team.'This matrix, adapted from Craig Larman’s work, evaluates use cases on a scale of 1 to 5 against six criteria ‘They are as follows: 1. Significant impact on the architectural design. Easy to implement but contains significant functionality. Includes risky, time-critical, or complex functions. Involves significant research of new of risky technology. Includes primary business functions. Will increase revenue or decrease costs. Once each category has been scored, the individual scores are tallied, resulting in the use case's final score. The use cases with the highest scores are assigned the highest priority and should be developed fist. Figure 7-14 is a partial usecase ranking and priority matrix for the Member Services System. Based on the results of the analysis, the use case Submit Subscription Order should be developed first. But we can’t be sure until we analyze the use-case dependencies, > Identifying Use-Case Dependencies Some use cases may be dependent on other use cases, with one use case leaving the system in a state that is a precondition for another use case. For example, a precond- tion of sending a club promotion is that the promotion must first be created. We use a diagram called the use-case dependency diagram to model such dependencies, ‘The usecase dependency diagram provides the following benefits: + ‘The graphical depiction of the system's events and their states enhances the understanding of system functionality. + Ithelps to identify missing use cases. A use case with a precondition that is not satisfied by the execution of any other use case may indicate a missing + Ithelps facilitate project management by depicting which use cases are more critical (have the most dependencies) and thus need to have a higher priority. Figure 7-15 is the usecase dependency diagram for the use cases listed in Fig- ure 7-14. The use cases that are dependent on each other are connected with a dashed "chag Laman, plying UE Petts (Upper fade Rive Nf Prentice Hal, 198), ‘usecase dependency a graphical depic- tion ofthe dependencies among use cases.262 Part Two Systoms Analysis Mothods Depends on Depends on Depends on so FIGURE 7-15 Sample Use-Case Dependency Diagram line labeled “Depends on” In Figure 7-15, the use case Submit Subscription Order has a dependency (precondition) on the use case Establish New Member Subscription Program, Because of this dependency the use case Establish New Member Subscrip- tion Program should be developed first even though Submit Subscription Order had a higher score as reflected in Figure 7-14 ‘This chapter provided an introduction to use cases and how they can be used to doc- lument functional requirements, Also, you have learned that use-case modeling based on objectoriented concepts is an excellent complementary tool for traditional sys. tems analysis and design tools such as process modeling and data modeling, Many of ‘you will proceed directly to Chapter 8, Data Modeling and Analysis” All information systems include databases, and data modeling is an essential skill for database devel ‘opment. Also, itis easier to synchronize early data models with later process models than vice versa. Your instructor may prefer that you first study Chapter 9, “Process Modeling” Process modeling is an effective way to analyze and document functional system requirements, Courses that want to follow an objectoriented approach may lect to jump straight to Chapter 10, Object Oriented Analysis and Modeling Using the UML? which teaches emerging objectmodeling techniques using the unified modeling language. Learning Roadmap Summary sh 1. There are two primary artifacts involved when per- forming use-case modeling. The firstis the use-case liagram, which graphically depicts the system as a collection of use cases, actors (users), and theie re- lationships. Details of each business event and hhow the users interact with the system are de- scribed in the second artifact, called the use-case zarrative, which is the textual description of the business event and how the user will interact with the system to accomplish the task. 2. Usecase modeling utilizes two constructs: actors, and use cases. An actor represents anything that needs to interact with the system to exchange in- formation, An actor is.a user, role, which could be an external system as well as a person. A use ‘case is a behaviorally related sequence of steps (a‘Modeling Systom Requirements with Use Cases scenario), both automated and manual, for the pur- ‘pose of completing a single business task. 3. There are primarily four types of actors: 4. Primary business actor—The stakeholder that primarily benefits from the execution of the use case by receiving something of measurable ‘or observable value. b. Primary system actor—The stakeholder that directly interfaces with the system to initiate or ‘rigger the business or system event. . External server actor—The stakeholder that responds to a request from the use case. 4. External receiver actor—The stakeholder that. isnot the primary actor but receives something, ‘of measurable or observable value (output) from the use case. 4, Temporal events are business events that are per- formed (or triggered) automatically —when it be comes a certain date or time. Because of that, we say the actor of a temporal event is time. 5. A relationship is depicted asa line between two symbols on the use-case diagram. 4. An association isa relationship between an ac- tor and a use case. Chapter Seven 263 b. ‘The relationship between the extension use case and the use case itis extending is called an extends relationship. . The relationship between the abstract use case and the use case that uses it is called a uses, relationship. . The inheritance relationship occurs when an actor inherits the ability to initiate a use case from another. . The dependson relationship indicates a depen- dency between use cases. In other words, the precondition of one use case is dependent on. the postcondition of another use case. 6. ‘The steps required to produce a requirements use- ‘case model are the following: a. Identify business actors. b, Identify business requirements use cases. c. Construct use-case model diagram. . Document business requirements usecase narratives. 7. ‘The use-case ranking and priority matrix and the usecase dependency diagram are tools used by project managers for prioritizing and scheduling usecase development. a Review Questions 1. What is user-centered development and why is it critical to the success of the system development process? 2. How is usecase modeling related to user-centered development? 3. In addition to encouraging user involvement, use- case modeling provides numerous other benefits. List the benefits that use-case modeling provides. 4, Use-case modeling uses two primary artifacts— the use-case diagram and the usecase narrative. How are these two artifacts used and what are their differences? 5. Use case diagrams consist of three components, ‘What are these three components, and what is their purpose? 6, How are use cases used throughout the entire system development life cycle? 7. Of the four primary categories of actors, who is the primary system actor? ‘8. What are the different types of relationships em- ployed in a use-case diagram, and what is their purpose? 9. What is the objective of constructing the require: ments use-case model and what steps are to be followed? 10, Why is identifying the actors the frst step in use- case modeling? LL, What should we be aware of when we are look- ing for business requirements use cases? 12, What is a use case's typical course of events? 13. Why is ranking and evaluating of use cases essential? 14, What are the six criteria in the use-case ranking, and priority matrix? 15. What is the usecase dependency diagram, and why do we use it?264 Part Two Systoms Anelysis Methods on Problems and Exercises gs L According to author Fred Brooks, what isthe sin- le most difficult thing to do in systems develop ‘ment? How does use-case modeling help in this area? In use case modeling, what two main artifacts does the systems analyst use? Describe each of these artifacts and explain their purpose. ‘What should a systems analyst always keep in ‘mind in identifying and developing use cases re- garding theie purpose? Since requirements fact finding has been completed previously ist really necessary to spend much time with users at this point? Just what should a use case represent? Is a use case the same as a functional requirement? During what part of the development life cycle are use cases first defined? When are they used during the development life cycle, and for what purpose? Match the following stakeholders and external users with the correct actor. What is a temporal event? Who or what is considered to be the actor ina temporal event, and why? Stakeholders and external users Actor + United States Postal Primary business Service actor + Computerized door lock with key pad + Rental car agent + Sales manager gener. Primary system actor External server actor External receiver ating regional sales. actor report + Sales manager receiv. Time ing regional sales report + Automatic lawn, sprinkler system + Driver purchasing gasoline with ATM card + Bank loan authoriza- ton service ‘What is the type of relationship for each of the following examples? + ‘The relationship between the use case “Print Form’ and several other use cases that involve printing different types of forms. + The relationship between a motorcycle off cer and a handheld citation writing device. + ‘The relationship between a customer and a sales clerk who can each query the inventory system to see if an item is in stock, and an actor created specifically to minimize duplica- tive system communication. + The relationship between the use case “Cal cculate GPA" and the lengthy use case “Create “Transcript.” + The relationship between the use case “Ship Order" and the use case “Submit Order” 7. Y¥&J Cookbooks is fictional small business ‘owned and operated by a retired couple. Up to this time, Y8&J Cookbooks has sold its books by ‘mail order only. The owners now want to develop an online system to sell rare and out-of-print ‘cookbooks over the Internet. Visitors will be able to browse a variety of cookbooks, but they will have to create a customer account before being able to make a purchase. Payments will be 2c- cepted only online with a major eredit card, and the creditcard will be verified before the order ‘can be approved, Based upon this information, identify the main business actors. 8. Inuuse-case modeling, once you identify the bus ness actors, what perspective and language should you use in defining them? Use that per- spective and language to construct an actor glos. sary using Figure 7-8 as an example. ‘9. Acontext diagram can help tremendously in iden- tifying different use cases. Prepare a highdevel context diagram for the Y8J Cookbooks Web site, using Figure 7.9 as an example. 10. The next step in requirements use-case modeling is to identify the business requirements use cases. ‘What should each use case capture? What effec- tive technique can you use to identify use cases? ‘What questions might you ask in order to identify use cases? What isthe difference between a use case and an essential use case? 111, The third step in use-case modeling is to con- struct the use-case model diagrams. Based upon. the Y&J Cookbooks actor glossary and context, diagram, create a hightevel use-case model diz- ‘gram, showing the interactions between the shoppet/customer actor and the system, includ. ing searching and browsing for books, purchas- ing, and managing the customer account. Make ‘sure to show the relationships between the actor and each of these use cases. 12, The next step is creating use-case narratives to document the business requirements. Why is preparation of the narratives generally done in a ‘two-step process, and what are these two steps? Based upon the preceding high-level use-caseModeling System Requirements with Uso Cases Chapter Seven 265 ‘model diagram, create an expanded narrative, us. ing Figure 7-13 as an example. 13. ‘What is the relationship of use-case modeling to project management? Why is this important? Why. ‘are use cases ranked, and what tool is used to sank them? Who provides the input for ranking them? What criteria are used for ranking? Explain why use-case dependencies need to be identified, and provide an example. What tool is used to identify dependencies? 1. At the beginning of Chapter 7, there is a quote taken from an article by Frederick P Brooks Jr, ‘who is generally considered to be one of the lead- ing authors and contributors to the field of project management and software development. Search the Web for this article and for other articles by and/or about Fred Brooks. a. In conducting your search, how many refer- ‘ences to the author did you find? b. Based upon the information presented in the previous chapters, explain Brooks's statement that the hardest single part of building a soft ware system is deciding precisely what to build” ‘c. What was the name of the article in which Brooks made the preceding statement, and ‘what was the article's main theme? 4. What is Brooks's best known book that i stil in print and widely read decades after its original publication? What was the main theme of this book? €@. What do you consider to be Brooks's greatest contribution to date? Why? 2. The Standish Group, which was mentioned in Chapter 7, is an independent research group that studies changes and trends in information technology. In 1994, the Standish Group published its groundbreaking CHAOS Report, which ‘ex- pose[d] the overwhelming failure of IT application development projects in today’s MIS environment.” Since that time, the Standish Group has published periodic updates to their original report. Go to their Web site at wnewistandishgroup.com, and. follow the links to their public access area, where you can find a summary of their latest CHAOS. research report, as well as the original 1994 report itself 4. What criteria does the Standish Group use to determine whether a project succeeded, was challenged, or failed? b. Based upon the latest research report, what percentage of projects succeeded, were chal- lenged, or failed? 2° Projects and Research How do these latest rates compare to the proj- cect success, challenge, and failure rates shown in Figure 7-1 of the textbook? How would you describe the overall trends, if any? 4. Based upon your reading and experience, what, do you believe to be the reason(s) for the ‘changes in project success, challenge, and fail- ure rates? e, Do you think that current project management, and system development methodologies will re- ‘main essentially the same but continue to be re- fined, or do you foresee the emergence of, ‘dramatically different methodologies for manag- ing projects and developing systems over the next decade? Select an information system used in your organi- zation or in your school. Interview a systems ana- lyst or designer who is familiar with the system. Based upon the information provided, do the following: 4. Describe the information system and organiza- ton you selected. Greate a context diagram of the system. Identify the business actors. Greate an actor glossary. dentify the business requirements essential use £ Create a use case glossary. Based upon the information provided regarding the system you selected in the preceding question: pees 1. Construct a use-case model diageam that in- cludes all major subsystems, b. Prepare expanded use-case narratives for three of the essential use cases. c. Prepare a use-case ranking and priority matrix, then use it to rank and evaluate the use cases, 4. Identify use case dependencies. fe, Prepare a use-case dependency diageam.266 Part Two Systoms Anelysis Methods 5. Search the Web or professional journals in your ‘school library for research articles on new and ‘emerging developments in use-case modeling. Select two articles, then do the following: 4. Provicle a bibliography for each article. Use the format used by your school.) . Create an abstract in your own words for each. article . Compare and contrast the methodologies de- scribed in each article. Describe which one you feel is more viable and/or significant, and ‘explain why. Conduct interviews with several developers segarding their views on use-case modeling. If possible, try to find developers from different organi- zations and/or with diferent lengths of experience, as well as different types of experience (ie. a devel ‘oper who has experience mostly asa systems an lyst, one mostly asa designer, and one as a builder). 4. Describe the developers that you interviewed in terms of their experience. For example, how Jong have they worked in IT, what is their area of expertise, and how familiar are they are with uuse-case modeling? b. What is the nature of their organization(s)? ‘What questions did you ask? ‘What are the viewpoints of each developer re- garding the importance and value of use-case modeling? €. Do these developers actually employ use-case ‘modeling in their current organization? Why or why not? £. Ifthey were CIOs of their organization for a day, would they change their organization's IT architecture regarding use-case modeling? If so, how? Using the capability maturity model, how would you rate the maturity level oftheir orga. nization? Why? hh, What conclusions, a any, can you draw from the interviews regarding the practical application of use-case modeling? i. What were your views regarding the impor- tance and value of use-ease modeling before the interviews? Did your views change any asa re- sult ofthe interviews? If so, how did they change and why? Minicases 1 Ina mincase for Chapter 6, you interviewed stake- holders for an online class registration system. In that exercise, you were to develop an understand. ing of any issues and needs those stakeholders had in regards to the system. Review your findings from those interviews. . Visit other school registration systems. Is there any functionality of ease of use differences? ‘Are there any features that you think the stake- holders would particularly like/dislike? Make ‘notes and create screen dump examples of other systems. . Create a follow-up interview with those stake- holders you previously spoke to and determine specific functionality and ease-ofsuse require- ‘ments for your school. . Create a use-case description for at least one of the functionality requirements you found in the ‘previous problem. Follow the example shown in Figure 710. . Identify all of the actors for the school registration system, Which uses cases will each initiate? . Using your answer to the previous problem, draw a use-case diagram of the school registration system. Team and Individual Exercises ww 1 Roundtable discussion: Do you think people are al- ‘ways absolutely truthful in their responses to inter- view questions? ‘Watch a silent movie. Roundtable discussion: What ‘communication is taking place other than words? Roundtable discussion: When you determine re- quirements for a system through a method such as ‘an interview, you assume that the person you are interviewing and collecting information from ‘wants the system to be successful. Is this always the case? How can you handle requirements gathering if itis not?‘Modeling Systom Requirements with Uso Cases Chapter Seven 267 fo] u Suggested Readings Ambler, Scott W The Object Primer. New York: Cambridge Jacobson, Ivar; Magnus Chisteson;Pattk Jonsson; and Gun- University Press, 2001, Very good information about doc- nat Ovetgaard, Object-Oriented Softuare Engineering — ‘umenting use cases and their use ‘A Use Case Dréven Approach. Workinghatn, England: Armou, Frank, and Granville Miller Advance Use Case Mod- _Adalsot» Wesley, 1992, This book presents detailed cover- felfng. Boston: Addison-Wesley, 2001. This book presents _age of how to identify and document use cases, excellent coverage ofthe use-case modeling process. Larman, Craig. applying UML and Patterns. Upper Saddle Brooks, J, FP, 1987."No SilverBullet—Essence and Accidents ‘Rivet, NJ: Prentice Hall, 1998."This book provides a com- of Software Enginecting” Computer 20(4), April, 10-19. _prchensive overview of a use-case modeling process ‘Proc. IFIP Congress, Dublin, ieland, 1986