1 / 71

Use Cases

Use Cases. A Holistic Approach to Requirements Extraction. 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

marlow
Download Presentation

Use Cases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related