Download
1 / 73
730 likes | 903 Views
Analysis. Stakeholders Business goals System functions Technical system requirements Fundamental domain concepts and relationships Domain algorithms Domain level state behavior application behavior, look and feel. Define. Requirements Artifacts.
E N D
Stakeholders Business goals System functions Technical system requirements Fundamental domain concepts and relationships Domain algorithms Domain level state behavior application behavior, look and feel Define Requirements Artifacts Information Needed Information Representation • Enhanced actor model • Textual descriptions - must be traced to the architecture • Use case hierarchy • Textual descriptions cross referenced to the use cases • Domain class model • Interaction diagrams • state transition diagrams • prototypes
Actors An actor is an external entity that interacts with the system
Definition • When an actor instance uses a system, it will perform a behaviorally related sequence of transactions with the system. We call such a sequence a use case. • A use case is a specific way of using a system
Use Case Template • Use Case ID:{This should be coded to identify the owning team and the level of the use case} • Use Case Type:{Essential, Concrete, Abstract} • Use Case Name:{Short descriptive phrase} • Basic Course:{This is a complete description of the use. Each subsection is explained below.} • Actor: {Which actor from the actor model initiates this course of the use case?} • Pre-conditions:{Requirements on the state of the system prior to this use being valid.} • Description:{Numbered flow of events: 1 The user initiates an action by… 2 The system responds by...} • {In this section reference is made to sub-use cases that this use case uses.} • Relevant requirements:{Reference to other relevant requirements documents.} • Post-conditions:{This describes the state of the system following the successful completion of this use. Affects on other systems and actors may also be described.} • Alternative Courses: {Structured like the basic course} • Rationale:{Explanation of why this requirement is present in the system. This field is typically only used for essential use cases} • Extensions:{This section presents variations on this use case that “specializes” it. It presents those use cases that have an extends relation with the current use case.} • Exceptions:{This section describes all error conditions that can arise in the use case.} • Concurrent Uses:{This use can occur concurrently with the uses listed in this section.} • Related Use Cases:{use cases that are either usually performed just before or after the current use.}
Use Case Template(Continued) Decision Support Frequency:{How often will this use of the system occur? This field is combined with the criticality field to determine the number of tests that will be used to test the functionality. It may also be used in certain design decisions.} Criticality:{How necessary is this use to the successful functioning of the program from a user’s perspective. This field is used to assist in determining the extent to which the use will be tested.} Risk:{The project risk associated with providing this use. This is used in project planning. Often riskier uses will be implemented early to provide sufficient recovery time.} --------------------------------------------------------------------------------------------------------------------- Modification History -- {Follow the standard corporate document versioning template} Owner: Initiation date: Date last modified:
Good Foundation System Test Process WELL DEVELOPED USE CASES
Use Case to Test Case * Test case 1 Instance 1 Basic Course ... ... Test case n Instance n Test case n+1 Instance n+1 Alternative 1 Use Case ... ... Test case n+m Instance n+m Alternative 2 Test case n+m+1 Instance n+m+1 ... ... Test case n+m+j Instance n+m+j ... ... ... * A use case instance is often called a scenario
No Silver Bullet • Use cases have become the standard for documenting functional requirements, however, • Use cases are no more than a structured format for gathering and expressing requirements • Good format is helpful but not sufficient
Complete Set of Actors Identifying a complete set of actors means I will capture all of the user’s viewpoints What if the actors don't understand the true business needs? What if the development team misunderstands the use cases?
Useful Use Cases • Good use case development relies on knowledge gained during domain analysis • To understand a domain it is useful to to know the actors and the major domain activities
Impossible • Analysts can’t create correct, useful use cases if they don’t understand the domain. • This is as true for the client as for the development team • Developers can’t implement correct use cases correctly if they don’t understand the domain. Never assume the client knows and can articulate real business needs
Fundamental Principles of Requirements Gathering • Requirements should be organized hierarchically • Use cases are best developed iterativaly and incrementally (the same way as the rest of the system deliverables) • Hierarchical classification of use cases need not, and should not, be functional decomposition • Business requirements should be kept separate from interface specifications • Do not directly derive your design from your use cases
Requirements should be organized hierarchically UC 1 UC1.1 UC1.2 UC1.3 UC1.4 UC1.10 UC1.1.1 UC1.1.2 UC1.1.3 UC1.10.1 UC 1.1.1.1 UC1.1.1.2 UC1.1.1.3 UC1.10.1.1 UC 2 UC3 UC2.1 UC2.2 UC2.3 UC2.4 UC2.10 UC2.1.1 UC21.1.2 UC2.1.3 UC2.10.1 UC2.1.1.1 UC2.1.1.2 UC2.1.1.3 UC2.10.1.1
Use Case Hierarchy • Manage complexity • Top level < 12 • No level should have more than 5 to 10 times the number of use cases than in the previous level • Allows for “testing” of models, architectures, etc • Each level should be complete
Use cases are best developed iterativaly and incrementally • The only way to get quality is to iterate • Requirements change while the system is being developed • As the development team better understands the domain, the are better able to review the use cases
Understanding Matures • You can’t get the use cases totally correct at the beginning of the project
Hierarchical classification of use cases need not and should not be functional decomposition UC 1 - customer makes purchase UC 1.1 - scan UPC UC 1.2 - add tax UC 1.3 - calculate total UC 1.4 - accept payment UC 1.5 - make change
Each Level is Complete 1. Define course policies 1.1 Define late policy 1.2 Define category weights Use case 1.1 is a specific, more detailed, complete use case within the category of use cases defined by use case 1.
Use Case 1 • Customer buys soda at vending machine • customer inserts enough coins for purchase • machine displays total deposited • customer pushes button to indicate selection • machine dispenses soda can to bottom tray and change to change tray • customer retrieves soda and change Most OO teams incorrectly think the first level of use cases should jump directly to interface specifications.
Business requirements should be kept separate from interface specifications 1 Accept Payment Electronic Cash 1 This is the idea of essential use cases - see bibliography
How? • Keep first n levels of the use case hierarchy interface neutral • Have a separate field in the use case template for the interface binding
Do not directly derive your design from your use cases • Use cases DO describe sequences of actions that actors follow in using the system • Use cases must NEVER specify what steps the system takes internally in responding to the stimulus from an actor Use Cases architecture Interface System
Concrete use case Abstract use case Complete use case Essential use case Partial use case High-level use case System-level end-to-end use case Functional sub-use case Types of Use Cases
Levels of Use Cases • High Level • Expanded (high) level • Detail level (including exception and alternate courses of action) • Abstract level (for common functionality)
Boiling it down • Essential use cases • Concrete use case • Abstract use case
Essential Use Cases • “are uncontaminated by presumptions about the design of an interface that is yet to be designed” 1 1 Larry Constantine, p70
Essential Use Case TemplateView from 500 - 20,000 feet • Interface neutral • Focus on the basic course (as opposed to alternative courses and exceptions) • Basic course narrative is short prose focusing on goals of the actor • Includes a “Rationale” field - Explanation of why this is a business requirement
Concrete Use Case(In the Trenches) • Interface-specific, complete end-to-end set of interactions between an actor and the system to accomplish an actor’s goal • Focus is on the details of the basic and alternative courses of action
Abstract Use Case(Reusable Use Case) • Sometimes called a partial use case, or functional sub-use case • Captures partial set of interactions that is common across multiple concrete use cases • Focus is on common interface-specific details
Use Case Instance(Scenario) Sue inserts $1.00, selects and recieves a diet coke and $0.15 change
Change Cases • Change cases are use case that the architecture must support, but that will not be built as a part of the current project ? How does one test for extensibility?
Use Cases - Summary • Use cases are an important part of the development process • Most teams do not get as much value from use cases as they should • One can’t build good use cases without good domain knowledge • One size doesn’t fit all. Configure your use case process carefully and manage it wisely
Case of the Useless Use Cases Case Study
Project X • Over 1000 software developers assigned to the project • 3 continents • near-simulations development of a multi-level framework with numerous applications built on the framework
Consequences • Poor quality requirements • Poor quality designs • “functional decomposition” in “object clothing” • Wasted time and effort If use cases misused then
Framework Team Architecture team realized they would need to understand the scope of the requirements
12,386 Use Cases What do you suppose the framework team did with all of these use cases?
12,386 Useless Use Cases • Wrong level of abstraction • 1/2 Million $$ • Morale cost • Confidence in the framework team was eroded
Really Sad Part :-( • Not only too detailed • Typically full of errors • Almost always have to be redone
Continued Information For Articles Regarding Use Cases and E-Mail Updates register at http://www.korson-mcgregor.com/usecase.htm
Use Case Bibliography • Berard, Edward V. “Be Careful with Use Cases” The Object Agency, Inc. Publications On-Line, www.toa.com/pub/html/use_case.html. • Cockburn, Alistair, “Using Goal Based Use Cases,” JOOP, The Journal of Object-Oriented Programming, November/December 1997, p. 56-62. • Constantine, Larry, “The Case for Essential Use Cases,” Object Magazine. May 1997, p. 72, 70 • D’Souza, Desmond Frances, and Alan Cameron Wills, Objects, Components, and Frameworks with UML, The Catalysis Approach, Addison Wesley, Reading, Massachusetts, 1999. • Fowler, Martin with Kendall Scott, UML Distilled, Applying the Standard Object Modeling Language, Addison Wesley, Reading, Massachusetts, 1997. • Jacobson, Ivar, Grady Booch and James Rumbaugh, The Unified Software Development Process, Addison Wesley, Reading, Massachusetts, 1999. • Jacobson, Ivar, Grady Booch and James Rumbaugh, The Unified Modeling Language Reference Manual, Addison Wesley, Reading, Massachusetts, 1999. • Jacobson, Ivar, Object Oriented Software Engineering, A Use Case Driven Approach, Addison Wesley, Reading, Massachusetts, 1992. • Korson, Timothy D., “Constructing Useful Use Cases,” Component Strategies, March 1999, p. 27-28. • Korson, Timothy D., “Configuring A Use Case Process,” Component Strategies, September 1998, p. 20-21 • Korson, Timothy D., “The Misuse of Use Cases” Object Magazine, May 1998, p. 18, 20. • Schneider, Geri and Winters, Jason P., “Applying Use Cases, A practical Guide,” Addison Wesley, 1998.
