1. Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture #2 Use Case Modeling I

2. Fall 2005 2 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Announcements Project Teams? Project Teams? Please start working on the EVRs Please start working on the EVRs TTA  “Plans and Situated Actions” TTA  “Plans and Situated Actions” Posdata  “Making Use” Posdata  “Making Use” Hyundai  “I Sing the Body Electronic” Hyundai  “I Sing the Body Electronic”

3. Fall 2005 3 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Picture of the Day: The SEI Building

4. Fall 2005 4 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Context Client Requirements Software Design Here a Miracle Happens Technical rqts Architecture Biz, polic, reg Usability Engineering The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

5. Fall 2005 5 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Requirements Analysis Client Requirements Here a Miracle Happens Technical rqts The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

6. Fall 2005 6 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Challenges & Evidences In 1994, $250 billion in US in IT application develop ment; corresponds to 175,000 projects In 1994, $250 billion in US in IT application develop ment; corresponds to 175,000 projects 31% of projects are cancelled = $81 billion 31% of projects are cancelled = $81 billion 52.7% with 187% cost overrun = $59 billion 52.7% with 187% cost overrun = $59 billion 16 % are on time in 1994 16 % are on time in 1994 In 2003, 34 % are on time, a big improvement In 2003, 34 % are on time, a big improvement Challenged projects (most commonly cited): Challenged projects (most commonly cited): Lack of user input (13%) Lack of user input (13%) Incomplete requirements (12%) Incomplete requirements (12%) Changing requirements (12%) Changing requirements (12%) Lack of technical skill (7%) Lack of technical skill (7%) Lack of resource (6%) Lack of resource (6%) Inadequate time (4%) Inadequate time (4%) [Standish Group International, 1994 and 2003 Surveys] 1/2

7. Fall 2005 7 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Largest software development problems by category ESPITI [1995 in Leffingwell and Widrig., 2000. Managing Software Requirements, p. 6-7] Challenges & Evidences Req. Spec Manag. Reqs Docmt. Testing Project Man. Coding 2/2

8. Fall 2005 8 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Plan for This Unit 09/02 : Fundamentals 09/02 : Fundamentals Scoping the problem through use cases Scoping the problem through use cases 09/06 : Structuring a well use case model 09/06 : Structuring a well use case model 09/09 : External viewpoints reports on understanding client ’ s needs 09/09 : External viewpoints reports on understanding client ’ s needs Make a 15 minute presentation Make a 15 minute presentation Send an abstract description of the main idea by 09/06 Send an abstract description of the main idea by 09/06 Suchman: Plans and Situated Accidents  TTA Suchman: Plans and Situated Accidents  TTA Carroll: Making Use  Posdata Carroll: Making Use  Posdata Moody: I Sing the Body Electronic  Hyundai Moody: I Sing the Body Electronic  Hyundai 09/16 : Project presentations of technical requirements of the studio projects through use cases 09/16 : Project presentations of technical requirements of the studio projects through use cases The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

9. Fall 2005 9 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Plan Requirement elicitation techniques Requirement elicitation techniques Use case modeling as a requirement elicitation technique Use case modeling as a requirement elicitation technique Process centered versus problem centered use case modeling Process centered versus problem centered use case modeling Fundamentals Fundamentals Stakeholders, users, actors Stakeholders, users, actors Use cases Use cases Structuring use cases, relationships Structuring use cases, relationships Scenarios Scenarios The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

10. Fall 2005 10 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Overview Use case modeling is a technique for requirement elicitation Use case modeling is a technique for requirement elicitation Facilitates early brainstorming of functional requirements Facilitates early brainstorming of functional requirements Can serve as a powerful tool for inter team and client communication Can serve as a powerful tool for inter team and client communication Helps bridge business and domain specific concerns with software design requirements Helps bridge business and domain specific concerns with software design requirements Provides mechanisms for problem scoping Provides mechanisms for problem scoping The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

11. Fall 2005 11 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University No Silver Bullet There is no method suitable for all problems There is no method suitable for all problems There may be alternative ways to apply one method in different contexts There may be alternative ways to apply one method in different contexts Resources will affect the method of choice Resources will affect the method of choice Good tools may become handy at even unexpected circumstances Good tools may become handy at even unexpected circumstances The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

12. Fall 2005 12 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Requirement Elicitation Techniques The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. Ethnographic Observation and Protocol Analysis Ethnographic Observation and Protocol Analysis Interview Interview Requirement Workshop Requirement Workshop Brainstorming Brainstorming Storyboarding Storyboarding Use Cases Use Cases Role Playing Role Playing Prototyping Prototyping Task Analysis Task Analysis Contextual Design Contextual Design

13. Fall 2005 13 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use Case Modeling as a Requirement Elicitation Technique Pros Mechanisms to separate business context from system context Mechanisms to separate business context from system context A use case model can serve as a problem scoping communication medium between the client and the developers A use case model can serve as a problem scoping communication medium between the client and the developersCons Tempts direct transformation of use cases to user interfaces, function calls, and object decompositions of the system Tempts direct transformation of use cases to user interfaces, function calls, and object decompositions of the system The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

14. Fall 2005 14 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Process vs. Problem First there were use cases (Jacobsen early 1990s) First there were use cases (Jacobsen early 1990s) Then there was Rational Approach which combined with OOSE to form Rational Objectory (1996)…. Then there was Rational Approach which combined with OOSE to form Rational Objectory (1996)…. Then there was use case driven, architecture centric, iterative and incremental Rational Unified Process Then there was use case driven, architecture centric, iterative and incremental Rational Unified Process The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 1/2

15. Fall 2005 15 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Process vs. Problem Use cases are very often used within unified process driven software development management Use cases are very often used within unified process driven software development management Use cases are invented in the context of object-oriented methodology and UML Use cases are invented in the context of object-oriented methodology and UML Yet, they are also very widely utilized as a design tool isolated from the unified process driven approaches Yet, they are also very widely utilized as a design tool isolated from the unified process driven approaches The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 2/2

16. Fall 2005 16 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University The Relationships Between Stakeholders and Actors/Use Cases http://www.awprofessional.com/articles/article.asp?p=30162&rl=1

17. Fall 2005 17 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Stakeholders A stakeholder is someone who gets a benefit from the outcome of software development A stakeholder is someone who gets a benefit from the outcome of software development Identifying the stakeholders correctly helps in scoping the problem Identifying the stakeholders correctly helps in scoping the problem Asking the questions to the right people Asking the questions to the right people Negotiating the business case and requirements with the decision makers Negotiating the business case and requirements with the decision makers Different stakeholders will bring different constraints which often times may contradict: financial, technical, long-term impact, privacy … Different stakeholders will bring different constraints which often times may contradict: financial, technical, long-term impact, privacy … The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 1/2

18. Fall 2005 18 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Stakeholders Users have an added special impact as a stakeholder, we design for the users Users have an added special impact as a stakeholder, we design for the users They directly interact with the outcome They directly interact with the outcome They may or may not be aware of (not to mention careless) other constraints, e.g. time to ship They may or may not be aware of (not to mention careless) other constraints, e.g. time to ship The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 2/2

19. Fall 2005 19 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Actors Actors: an entity that interacts with the system Actors: an entity that interacts with the system The stakeholders that interact with the system influence how it may be designed The stakeholders that interact with the system influence how it may be designed Software development is seldom from scratch, often there are multiple interacting components where the new application is the member of a larger collaborative scenario of multiple applications Software development is seldom from scratch, often there are multiple interacting components where the new application is the member of a larger collaborative scenario of multiple applications Defining the actors helps define the boundaries of the system Defining the actors helps define the boundaries of the system Actors that interact with the system are roles, i.e. generally defined designations, not specific people or instances Actors that interact with the system are roles, i.e. generally defined designations, not specific people or instances The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 1/4

20. Fall 2005 20 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Actors Who interacts with the system in what way may not always be easy to distinguish Who interacts with the system in what way may not always be easy to distinguish Business use case modeling  business actors and business use cases Business use case modeling  business actors and business use cases Helps resolve conflicts later on as more constraints and requirements start building up Helps resolve conflicts later on as more constraints and requirements start building up Aids in separating business goals from system goals Aids in separating business goals from system goals System use case modeling  system actors and system use cases System use case modeling  system actors and system use cases What we are eventually interested in What we are eventually interested in Focus is directly on the system to be built Focus is directly on the system to be built The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 2/4

21. Fall 2005 21 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Actors Personality Types: what is the relationship of each actor to the overall system Personality Types: what is the relationship of each actor to the overall system Initiator Initiator External Server External Server Receiver Receiver Facilitator (Proxy) Facilitator (Proxy) Abstract and Concrete Actors Abstract and Concrete Actors As a rule of thumb  any actor who does not have a direct relationship with a use case is an abstract actor As a rule of thumb  any actor who does not have a direct relationship with a use case is an abstract actor The benefit of such categorizations is in structuring the stakeholders domain and fine-tuning the roles and responsibilities The benefit of such categorizations is in structuring the stakeholders domain and fine-tuning the roles and responsibilities The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 3/4

22. Fall 2005 22 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Actors Identifying the stakeholders narrows down the problem scope one step Identifying the stakeholders narrows down the problem scope one step Identifying the actors narrows down the problem scope even further and focuses on the technical aspects of the problem Identifying the actors narrows down the problem scope even further and focuses on the technical aspects of the problem Focus on how the system will be used Focus on how the system will be used The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 4/4

23. Fall 2005 23 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Defining the System Boundary Studio projects are defined by multiple possible paths Studio projects are defined by multiple possible paths System actors are not always as obvious System actors are not always as obvious Their role in the system may change depending on how the problem is scoped Their role in the system may change depending on how the problem is scoped Possible Human Actor Possible System Actor TTA Software Testers Test Scenario Generator Posdata Car Drivers Automobile Information System Hyundai Car Drivers Automobile Multimedia Unit The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

24. Fall 2005 24 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use Cases A use case is a story about some way of using a system to do something useful A use case is a story about some way of using a system to do something useful Describe what the system does at a conceptual level Describe what the system does at a conceptual level A use case is goal oriented A use case is goal oriented Not necessarily functionality oriented, but functionality covers a lot of the use cases Not necessarily functionality oriented, but functionality covers a lot of the use cases A use case outlines a single goal and all the possible things that can happen as the users tries to reach that goal A use case outlines a single goal and all the possible things that can happen as the users tries to reach that goal Use cases are not simply menu items or functions Use cases are not simply menu items or functions The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

25. Fall 2005 25 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Why Use Cases? Elicit functional requirements with a focus on the user Elicit functional requirements with a focus on the user “ abuse ” and “ use-less ” cases “ abuse ” and “ use-less ” cases All the possible ways of using the system All the possible ways of using the system Form a conceptual model of the system Form a conceptual model of the system Bind analysis, design and tests Bind analysis, design and tests Introduce traceability Introduce traceability Devise architecture Devise architecture Aid creating user manual Aid creating user manual The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

26. Fall 2005 26 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Functional Decomposition Example: Order processing system Example: Order processing system The user perspective  place order The user perspective  place order All the above are alternative flows of the place order use case All the above are alternative flows of the place order use case The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. Customer Delete Order Change Order Add OrderApprove Order Order Quantity 1/3

27. Fall 2005 27 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Functional Decomposition Cockburn view [Cockburn 2001] Cockburn view [Cockburn 2001] In principle they are separate if we take a goal centered approach In principle they are separate if we take a goal centered approach They may be carried out by different actors with different requirements They may be carried out by different actors with different requirements Each represents a separate goal Each represents a separate goal Initial requirement elicitation activities call for the bigger goal Initial requirement elicitation activities call for the bigger goal There is no general consensus There is no general consensus The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 2/3

28. Fall 2005 28 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Functional Decomposition Decomposing the system into small, isolated chunks of behavior is the most appealing Decomposing the system into small, isolated chunks of behavior is the most appealing At first it seems easier to attack problems as small bits of behavior At first it seems easier to attack problems as small bits of behavior The focus of use case modeling should be on what the system does The focus of use case modeling should be on what the system does How the use cases fit together should be apparent How the use cases fit together should be apparent The user should not need to reassemble the value the system is to bring The user should not need to reassemble the value the system is to bring List of features do not map one to one with use cases List of features do not map one to one with use cases The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 3/3

29. Fall 2005 29 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use Case Modeling Use case model is the collection of diagrams, descriptions needed to represent the use cases and actors Use case model is the collection of diagrams, descriptions needed to represent the use cases and actors Use case modeling process Use case modeling process Defines the system boundary Defines the system boundary Finds the actors Finds the actors Finds the use cases Finds the use cases Describes each use case Describes each use case Refactors the use case model Refactors the use case model Prioritizes use cases Prioritizes use cases Adds future requirements (change cases) Adds future requirements (change cases) Organizes the use case model (packages) Organizes the use case model (packages) The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

30. Fall 2005 30 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Describing a Use Case Tedious to do all, but is worth spending time in early on as a requirement elicitation tool Tedious to do all, but is worth spending time in early on as a requirement elicitation tool The templates give guidance for the thinking process The templates give guidance for the thinking process Which actor(s), use cases initiate the use case Which actor(s), use cases initiate the use case What are the preconditions of the use case What are the preconditions of the use case How does the use case proceed, i.e. what are the flow of events How does the use case proceed, i.e. what are the flow of events What happens once the use case is over, what are the post conditions What happens once the use case is over, what are the post conditions What are the alternative sequences of events (exceptions), what are the decision points that may lead the user into alternative paths What are the alternative sequences of events (exceptions), what are the decision points that may lead the user into alternative paths The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 1/2

31. Fall 2005 31 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Describing a Use Case Name: Actors: Description: Name: Actors: Description: Initial use case descriptions Name: Actors: Description: Sequence of Events: Preconditions: Postconditions: Assumptions: Name: Actors: Description: Sequence of Events: Preconditions: Postconditions: Assumptions: Base use case descriptions The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 2/2 Broad descriptions of system behaviors initiated by actors Name: Actors: Description: Sequence of Events: Preconditions: Postconditions: Assumptions: Name: Actors: Description: Sequence of Events: Preconditions: Postconditions: Assumptions: Elaborated use case descriptions Detail descriptions of behaviors including condition logic and alternative flows

32. Fall 2005 32 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use case Diagram – The UML Context Concrete Actors Generalization Relationship Use Cases Unidirectional Association Abstract Actor Student Full time student Register Part time student Enroll evening classes The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 1/3

33. Fall 2005 33 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use case Diagram – The UML Context Relationships Communication Generalization Includes or uses Extends [Booch, Rumbaugh, Jacobsen (1999) The Unified Modeling Language Guide] communication generalization Validate User Check Password Retinal Scan Place Rush OrderPlace Order set priority > Customer Track Order > The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 2/3

34. Fall 2005 34 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Use case Diagram – The UML Context Communication Communication The only relationship permissible between actors and use- cases The only relationship permissible between actors and use- cases Generalization Generalization Similar to parent/child relationship Similar to parent/child relationship The specific elements share structure and behavior with the general element The specific elements share structure and behavior with the general element Includes/Uses Includes/Uses Used when a base use-case instance includes the behavior specified by another use-case Used when a base use-case instance includes the behavior specified by another use-case Models common behavior among use-cases Models common behavior among use-cases Extends Extends Used when one use-case adds functionality onto another use case Used when one use-case adds functionality onto another use case Extending use-case continues the activity of the starting base use-case Extending use-case continues the activity of the starting base use-case The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 3/3

35. Fall 2005 35 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Scenarios Use cases describe abstract and general behavior Use cases describe abstract and general behavior Use cases do not describe what happens when a specific actor performs a specific action with specific values Use cases do not describe what happens when a specific actor performs a specific action with specific values Scenarios: specific executions  also denoted as use case instances Scenarios: specific executions  also denoted as use case instances Variations of input and output parameters Variations of input and output parameters Variations on flow of events Variations on flow of events The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 1/2

36. Fall 2005 36 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Scenarios Scenarios carry use cases to a larger requirement elicitation context Scenarios carry use cases to a larger requirement elicitation context Validate requirements Validate requirements Identify any unaddressed nonfunctional requirements Identify any unaddressed nonfunctional requirements Performance and usability commonly Performance and usability commonly Create a broader system prototype Create a broader system prototype Flow nicely into test cases Flow nicely into test cases Success and failure scenarios (primary and secondary use cases) Success and failure scenarios (primary and secondary use cases) Scenarios can be used to structure use cases  Bottom up approach Scenarios can be used to structure use cases  Bottom up approach Using scenarios ensures that the use case covers all of the possible attempts to reach a goal Using scenarios ensures that the use case covers all of the possible attempts to reach a goal The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. 2/2

37. Fall 2005 37 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Benefits of Use Case Modeling to Stakeholders Customers Customers  customer requirements, system scope, schedule & budget, acceptance criteria Users Users  user requirements, user interactions Project Managers Project Managers  schedule & budget, feasibility & risk analysis, tracking development progress 1/2

38. Fall 2005 38 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Benefits of Use Case Modeling to Stakeholders System Architects System Architects  architectural requirements, technology selection System Developers System Developers  design requirements, system documentation System Maintainers System Maintainers  guidance for system modification and evolution Make the stakeholders be involved early in the system development effort! 2/2

39. Fall 2005 39 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Questions??