Use Cases - PowerPoint PPT Presentation

marlow
use cases l.
Skip this Video
Loading SlideShow in 5 Seconds..
Use Cases PowerPoint Presentation
play fullscreen
1 / 71
Download Presentation
Use Cases
179 Views
Download Presentation

Use Cases

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Use Cases A Holistic Approach to Requirements Extraction

  2. Overview • The challenge of requirements capture • Requirements defined • Requirements standards • The “Yes, but…” syndrome • Poor requirements are expensive • What makes requirements difficult • The benefits of the use-case approach • Examining the system from the frame of reference of the user • Benefits for test planning • Benefits for project planning and estimation • Key use-case attributes • Intent, description, pre-conditions, etc. • Post-conditions as use-case discriminators • Holistic Requirements Extraction Process • Brainstorming, idea reduction, storyboarding, etc. • Facilitating use-case workshops

  3. The Challenge of Requirements Capture Let’s explore some of the special problems and challenges that make requirements capture and project success difficult

  4. What is a requirement? • A requirement is defined as: • “A condition or capability to which the system [being built] must conform” • Definition adopted by the OMG, Rational Software, Inc., and IEEE

  5. What is a requirement? • A requirement can also be defined as: • A software capability needed by the user to solve a problem or achieve an objective • A software capability that must be met or possessed by a system or system component to satisfy a contract, specification, standard, or other formally imposed documentation • Dorfman, M. and R. Thayer, Software Engineering, IEEE Computer Society Press, Los Alamitos, CA, 1997, p. 79

  6. Requirements Standards • Requirements should be (IEEE 830 standard): • Correct • Unambiguous • “if and only if it can be subject to only one interpretation” (IEEE 830-1993, § 4.3.2, 1994) • Complete • Consistent • Ranked for importance and stability • Verifiable • Modifiable • Traceable • Understandable

  7. The Rock • Customer says “bring me a rock” • We deliver a rock • Customer looks at it and says, “Yes, but, what I really wanted was a small blue rock.” • We deliver a small, blue rock

  8. The Rock • Customer says “actually, I want a spherical one…” • We deliver a spherical blue rock • Ultimately, it becomes clear that the customer really wanted a blue cat’s eye marble. • We shall refer to this as the “Yes, but…” syndrome

  9. Standish Group, 1994 • In the US, we spend on average over $250 billion on IT projects per year • Approximately 170,000 projects • Average for large companies: $2,322,000 • Average for medium companies: $1,331,000 • Average for small companies: $434,000

  10. Standish Group, 1994 • 31% of these projects get cancelled before they are even completed • $81,000,000,000 wasted per year • (adding in projects that were completed before they were cancelled) • 52.7% of these projects were more than 189% over budget when delivered • $59,000,000,000 spent on budget overruns

  11. Poor Requirement Result in Project Failure • Studies from recent software projects show that: • The most significant contributors to project failure relate to requirements • The Standish Group International, Inc.’s CHAOS Reports from 1994 to 1997, Dennis, MA

  12. Requirements Defects are Expensive • Requirements defects represent more than 70% of rework costs • Rework consumes about 30-50% of a project budget • Lack of user input was listed as the most frequent problem

  13. Requirements: Are not always obvious and have many sources Are not always easy to express clearly in words Change Can be time-sensitive Requirements have unique properties or property values For example, they are neither equally important or equally easy to meet What Makes Requirements Difficult?

  14. What Makes Requirements Difficult? • Requirements are related to one another and other deliverables of the process in a variety of ways • The number of requirements can become unmanageable if uncontrolled • There are many different types of requirements at various levels of detail • There are many interested and responsible parties, which means requirements need to be managed by cross-functional groups of people

  15. What Makes Requirements Difficult? • “It is absurd to believe that the human mind can come up with a consistent and relevant list of thousands of requirements in the form ‘The system shall….’ What’s more, these requirements specifications [do] not readily transform into design and implementation specifications.”

  16. Benefits of Use Cases Let’s look at the potential benefits of the use-case approach

  17. Benefits of Use Cases • Use Cases are: • Systematic • Intuitive • Assist in extracting and capturing functional requirements • Are scenario-based • Focus on the value added to the user • Serve as a launch point for analysis, design, and testing

  18. Benefits of Use Cases • Use cases have the following advantages: • Easy to write • Written in the language of the user • Provide cohesive scenarios • Maps easily to design • Scenarios can be used almost directly as test scripts

  19. Industry-standard Approach • Use Cases have been used to model complex systems for the last decade • Originally Published by Jacobson in 1992 • Functional specification of object-oriented systems • The Unified Modeling Language and Unified Process have been accepted as the international standard by OMG • Largest standards organization in history • over 900 companies make up the group

  20. Use Cases • Captures system functionality from the perspective of the value expected by the user • Captured early in the development lifecycle • Purpose • Specify the context of a system • Capture the requirements of a system • Validate a system’s architecture • Drive implementation and generate test cases • Developed by analysts and subject matter experts (SME)

  21. The Unified Process

  22. Use Case 1 Use Case 2 Use Case 3 Actor2 Actor1 Use Cases Drive Analysis and Design Efforts • Specify system capabilities from user perspective • Form basis for system construction • Trace directly to system architecture • Two primary artifacts • Actors • Use Cases

  23. From the Perspectiveand Vocabulary of the User • Use case descriptions • Describe the basic course • Are written from the user’s perspective • Using the actor’s vocabulary • Clearly define the user’s intent

  24. Users “Own” Use Case Descriptions • Use cases form “contract” between users and developers • Users can evaluate the system before construction begins • To change system behavior users remodel the appropriate actor and the use case • The system architecture will be controlled from what the users wish to do with the system Own = Responsible For

  25. Use Cases Provide a Key Source for Estimation • As we begin to approach the system requirements using use cases, we gain incrementally more accurate views of • How long it will take to build each use case • How much each use case will cost • What the inherent risks are for each use case • How important each use case is to the business • In what order the use cases should be delivered, based on the dependencies between the use cases

  26. Define Actors Identify Primary Use Cases Cross-reference Use Cases with Actors Describe the Use Case Model Add Secondary Use Cases Use Cases Provide a Key Source for Estimation • Define Actors • Identify Primary Use Cases • Cross-reference Use Cases with Actors • Describe the Use Case Model • Intent and black-box description • Add Secondary Use Cases

  27. Package Use Cases Identify Primary and Secondary Scenarios Detail Secondary Scenarios Prioritize Use Cases for Delivery Detail Primary Scenario Use Cases Provide a Key Source for Estimation • Package the Use Cases • Prioritize Use Cases for Delivery • Identify Primary and Secondary Scenarios • Detail Primary Scenario • Detail Secondary Scenarios

  28. Sequence/ Collaboration Diagrams Refine Use Case Based on OIDs and GUI Prototypes GUI Prototype Refine Use Case Based on Design Use Cases Provide a Key Source for Estimation • Realize the Use Cases using Object Interaction Diagrams • Create GUI Prototype • Refine Use Cases based on OIDs and Prototypes • Refine the Use Cases based on Design

  29. Define Actors Cross-reference Use Cases with Actors Add Secondary Use Cases Identify Primary Use Cases Describe the Use Case Model Use Cases Provide a Key Source for Estimation • 1 Primary Use Case Count • Estimating Secondary Use Case by Percentage • 2 Adjusted Primary Use Case Count • Based on description • 3 Use Case Count • Adding actuals for secondary use cases   

  30. Package Use Cases Identify Primary and Secondary Scenarios Detail Secondary Scenarios Prioritize Use Cases for Delivery Detail Primary Scenario Use Cases Provide a Key Source for Estimation • 4 Prioritized Use Cases • 5 Scenario Count • 6 Primary Scenario • Event Count • 7 Complete Scenario • Event Count    

  31. Sequence/ Collaboration Diagrams Refine Use Case Based on OIDs and GUI Prototypes GUI Prototype Refine Use Case Based on Design Use Cases Provide a Key Source for Estimation  • 8 Realized Use Cases • Object Count • Function Count

  32. Questions, Comments, and Discussion...

  33. The Use Case Document A detailed description of the elements contained in the Use Case Document

  34. Use Case Intent Description Requirements Mapping Special Requirements Pre-conditions Post-conditions Flow of events Primary scenario Secondary scenario Use case business rules (optional) Use Case Document

  35. Use Case Document • Use Case • Intent • Mission Statement for the use case that helps define crisp conceptual boundaries around the use case • Provides a means of differentiating between similar use cases, while supplying a basis for allocating requirements to one use case or another • Must describe something of measurable value that the use case offers the actor • Attempts to capture the compelling business need that clearly identifies the “measurable value” • Has a strong relationship to the post-condition of the use case, in that both describe the goal of the use case.

  36. Use Case Document • Use Case • Intent (Cont.) • Describes the business goal of the use case, while the post-condition describes the goal of the system in support of the business goal • Description • A brief high-level description of what the use case does from a black-box perspective, from the frame of reference of the user (actor) • Identifies individual aspects of functionality with which the user is familiar • Should be written in active voice (i.e., the system displays a message to the actor)

  37. Use Case Document • Use Case • Description (Cont.) • Describes the basic course (primary scenario) • Written from the frame of reference of the user (actor) • Uses consistent terminology reflecting the vocabulary of the customer, not “system language” • Describes testable system requirements • Requirements Mapping [optional] • This section lists the respective requirement Ids for functional requirements related to each requirement addressed by the use case • Use this if the customer provides you with a set of requirements that you must reference • “what” the system does

  38. Use Case Document • Use Case • Special Requirements • Details special requirements as well as other types of considerations for the use case • How fast, how much, how big, how many, and how the feature will be used (usability requirements) • Details availability, accuracy, security, and performance (response time), archiving requirements, transactional volume, etc. • Pre-conditions • The state of the System at the start of the use case represented as a list of conditions that must be true prior to the use case

  39. Use Case Document • Use case • Post-conditions • The state of the system at the end of the use case regardless of which scenario has ecxecuted (except for scenarios ending in FAIL) • A list of conditions that must be true when the use case has completed its successful execution • Represented the overall goal of the use case from a system perspective • Describes the effect (goal) of the use case in terms of the altered system state (either transient or persistent) in the wake of the instantiation (execution) of the use case • Every use case must have at least one post-condition

  40. Use Case Document • Use case • Post-conditions (Cont.) • If a use case has more than one post-condition, and they are antagonistic, then it should be decomposed until multiple use cases • Flow of Events • Numbered series of declarative statements listing the steps of a use case • Collection of all scenarios that comprise the use case • Primary scenario • Secondary scenario • Alternate scenario • Exceptional scenario

  41. Use Case Document • Use case • Primary scenario • There is only one Primary Scenario for each use case that represents the most important course of events providing the best understanding of the use case • Detailed in table format with one column devoted to Event (Actor), one column devoted to Response (System), and one column devoted to Secondary Scenarios

  42. Use Case Document • Use case • Secondary scenario • Variants on the Primary Scenario • Exception cases that need to be handled • For exception scenarios, name the scenario after the condition that fired the scenario (I.e., Invalid Username, Illegal Action, etc.) • Normally terminate with RETURN or FAIL • Rarely, if ever, terminate with END

  43. Use Case Document • Use case • Scenario terminators • A terminator of END in a primary scenario means that the use case instance has completed successfully • The post-condition has necessarily been met • In a secondary scenario, END implies that execution control has been passed permanently to the secondary scenario • Such as a shutdown request)

  44. Use Case Document • Use case • Scenario terminators (Cont.) • A terminator of RETURN only applies to secondary scenarios • Indicates that the scenario returns to the event or response immediately following the one from which it branched • Unless followed by the specific Event or Response reference number, such as “RETURN to P-R4,” indicating that he scenario returns to the fourth system response in the Primary Scenario

  45. Use Case Document • Use case • Scenario Terminators (Cont.) • A terminator of FAIL only applies to secondary scenarios • FAIL indicates the abandonment of the use case • Necessarily means that the use case post-condition has not been met

  46. Use Case Document • Use case • Use case business rules (optional) • Must appear whenever business rules exist at the use case or scenario level • Each business rule shall be assigned a number and a name, which together are used to reference the business rules whenever they appear within the use case and scenarios • Use case package business rules (optional) • Business rules that apply globally to the use case package • Each business rule shall be assigned a number and a name, which together are used to reference the business rules that appear in the use case package

  47. Questions, Comments, and Discussion...

  48. A Holistic Approach to Requirements Extraction Applying requirements elicitation techniques to extract and specify system requirements

  49. Define the System • Early in system definition, decisions are made on what constitutes a: • Requirement • Documentation format • Language formality • Degree of requirements • Request priority and estimated effort • Technical and management risks • Scope

  50. Requirements Elicitation Techniques • Interviewing and questionnaires • Requirements workshops • Brainstorming and idea reduction • Storyboards • Prototyping