 |
 |
|
 |
 |
|
|
|
|
|
|
Encyclopedia :
U :
US :
USE :
Use case |
|
|
Use caseIn software engineering, a use case is a technique for capturing the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by software developers and end users.In 1986, Ivar Jacobson, an important contributor to the UML and Unified Process, originated the concept of the use case. Jacobson’s idea was influential and seminal. Numerous contributions have been made to the subject since then, but the most significant, influential and comprehensive, in terms of defining what use cases are and how to write them effectively, was provided by Alistair Cockburn, in his 2000 book Writing Effective Use Cases. During the 1990's use cases have rapidly become the most common practice for capturing functional requirements. This is especially the case within the object-oriented community where they originated, but their applicability is not restricted to object-oriented systems, because use cases are not object orientated in nature. Scope and goals of a use caseEach use case focuses on describing how to achieve a single business goal or task. From a traditional software engineering perspective a use case describes just one feature of the system. For most software projects this means that multiple, perhaps dozens, of use cases are needed to fully specify the new system. The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case. A use case defines the interactions between external actors and the system under consideration to accomplish a business goal. Actors are parties outside the system that interact with the system; an actor can be a class of users, roles users can play, or other systems. Use cases treat the system as a "black box", and the interactions with system, including system responses, are as perceived from outside the system. This is deliberate policy, because it simplifies the description of requirements, and avoids the trap of making assumptions about how this functionality will be accomplished. A use case should: Use Case diagramsMany people are introduced to use cases via UML, which defines a graphical notation for representing use cases. UML does not define standards for the written format to describe use cases, and thus many people have the misapprehension that this graphical notation defines the nature of a use case; however, a graphical notation can only give the simplest overview of a use case or set of use cases. The UML standard is the most popular standard for graphical notation of use cases. However, there are a number of alternative standards. Writing a use caseDegree of detailAlistair Cockburn in Writing Effective Use Case identifies three degrees of detail in writing use cases. BriefA brief use case consists of a few sentences summarizing the use case. It is highly suitable to use a spreadsheet for planning software development. A brief use case can be easily inserted in a spreadsheet cell, and allows the other columns in the spreadsheet to record business priority, technical complexity, release number, etc. CasualA casual use case consists of a few paragraphs of text, covering the items mentioned above, elaborating the use case in the form of a summary or story. Fully dressedA fully dressed or complex use case is a formal document based on a long template with fields for various sections; and it is the most common understanding of the meaning of a use case. Fully dressed use cases are discussed in detail in the next section on use case templates. Appropriate useSome software development methodologies do not require anything more than a casual use case to define requirements. However, some other development methodologies require fully dressed or detailed use cases to define requirements. The larger and more complex the project, the more likely it will be necessary to use fully dressed use cases. Use case templatesThere is no agreed template for documenting detailed or fully dressed use cases. There are a number of competing schemes and individuals are encouraged to use templates that work for them or the project they are on. Standardization for each project is more important than the detail of a specific template. However, there is considerable agreement about the core sections; and so beneath different terminology and order there is an underlying similarity between most use cases. Typical sections include: Different templates often have additional sections, e.g. assumptions, exceptions, recommendations, technical requirements. There may also be industry specific sections. Use case nameThe use case name provides a unique identifier for the use case. It should be written in the verb/noun format and should be sufficient for the end user to understand what the use case is about. IterationOften an iteration section is needed to inform the reader the stage a use case has reached. The initial use case developed for business analysis and scoping may well be very different to evolved version of that use case when the software is being developed. Older versions of the use case may still be current documents, because they may be valuable to different user groups. SummaryThe summary section is used to capture the essence of the scenario before the main body is complete. It provides a quick overview which is intended to save the reader from having to read the full contents of a use case to understand what the use case is about. PreconditionsA preconditions section is used to convey any conditions that must be true when a user initiates a use case. They are not however the triggers that initiate a use case. TriggersThe Triggers section describe the starting condition(s) which cause a use case to be initiated. Basic course of eventsAt a minimum, each use case should convey a primary scenario, or the typical course of events. The main basic course of events is often conveyed as a set of usually numbered steps, for example: ...and so on. Alternate pathsUse cases may contain secondary paths, or alternate scenarios which are variations on the main theme. Exceptions, or what happens when things go wrong, may also be described, either within the alternative paths section or in a section on their own. The Alternative paths make use of the numbering of the basic course of events to show at which point they differ from the basic scenario, and if appropriate where they rejoin. The intention is to avoid repeating information unnecessarily. An example of an alternative path would be: An example of an exception path would be: PostconditionsThe post-conditions section summarizes the state of affairs after the scenario is complete. Business rulesBusiness rules are written or unwritten rules that determine how an organization conducts its business with regard to a use case. Business rules are a special kind of assumption. Business rules may be specific to a use case or apply across all the use cases, and indeed all the business. NotesExperience has shown that whatever template is used, analysts discover there is always important information that doesn't fit the structure of the template. Therefore each template usually includes a section for such seemingly inevitable information. Author and dateThis section should list when this version of the use case was created and who documented it. It should also list and date any versions of the use case from an earlier stage in the development which are still current documents. The author is traditionally listed at the bottom, because it is not considered to be essential information; use cases are intended to be collaborative endeavors and they should be jointly owned. Benefits of Use CasesUse cases are a newer, more agile format for capturing software requirements. They are often contrasted to large, monolithic documents that attempt but fail to completely convey all possible requirements before construction of a new system begins. Use cases have a number of advantages: Limitations of Use CasesUse cases are not without their limitations: SoftwareSee alsoExternal links
|
|
|
This article is from Wikipedia. All text is available under the terms of the GNU Free Documentation License. |
|
| © 2008 Chamas Enterprises Inc. |
