Information AboutUse Case |
| CATEGORIES ABOUT USE CASE | |
| project management | |
| software engineering | |
| systems engineering | |
| sysml | |
|
In 1986, , in his 2000 book ''Writing Effective Use Cases''. During the 1990s use cases became one of the most common practices 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 oriented in nature. SCOPE AND GOALS OF A USE CASE Each 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 embrace the scope of 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 the system, including system responses, are as perceived from outside the system. This is a 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 DIAGRAMS Many people are introduced to use cases via UML, which defines A Graphical Notation For Representing Use Cases called the Use Case Model . 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 the graphical notation of use cases. However, there are a number of alternative standards. UML Use Case diagram OMG 's UML standard defines a graphical notation for Use Case s, but it refrains from defining any written format for describing use cases in detail. Many people suffer under the misapprehension that a use case is its graphical notation (or is its description). While the graphical notation and descriptions are important, they are documentation of the use case -- a purpose that the actor can use the system for. The true value of a use case lies in two areas. The first is the written description of system behavior regarding a business task or requirement. This description focuses on the value provided by the system to external entities such as human users or other systems. The second is the position or context of the use case among other use cases. As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team. It is common practice to create supplementary specifications to capture requirement details that lie outside the scope of use case descriptions. Examples of these topics include performance, scale/management issues, or standards compliance. The diagram on the right describes the functionality of a simplistic ''Restaurant System''. Use cases are represented by ovals and the Actors are represented by stick figures. The Patron actor can Eat Food, Pay for Food, or Drink Wine. Only the Chef actor can Cook Food. Note that both the Patron and the Cashier are involved in the Pay for Food use case. The box defines the boundaries of the Restaurant System, i.e., the use cases shown are part of the system being modelled, the actors are not. Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case. However, note that actors are a form of role, a given human user or other external entity may play several roles. Thus the Chef and the Cashier may actually be the same person. Three major relationships among use cases are supported by UML. The UML standard describes graphical notation for these relationships. In one form of interaction, a given use case may ''include'' another. The first use case often depends on the outcome of the included use case. This is useful for extracting truly common behaviors from several use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label < In another form of interaction, a given use case, (the extension) may ''extend'' another. This relationship indicates that the behavior of the extension use case may be inserted in the extended use case under some conditions. The notation is a dashed arrow from the extension to the extended use case, with the label < In the third form of relationship among use cases, a generalization/specialization relationship exists. A given use case may be a specialized form of an existing use case. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general use case. This resembles the object-oriented concept of sub-classing, in practice it can be both useful and effective to factor common behaviors, constraints and assumptions to the general use case, describe them once, and deal with ''same as except'' details in the specialized cases. WRITING A USE CASE Degree of detail Alistair Cockburn in ''Writing Effective Use Cases'' identifies three degrees of detail in writing use cases... Brief A 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 ... Casual A 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. Detailed A detailed 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. Detailed use cases are discussed in detail in the next section on use case templates. Appropriate detail Some software development methodologies do not require anything more than a simple use case to define requirements. However, some other development methodologies require detailed use cases to define requirements. The larger and more complex the project, the more likely it will be necessary to use detailed use cases. The level of detail in a use case often differs according to the progress of the project. The initial use cases may be brief; but as the development process unfolds the use cases become ever more detailed. This reflects the different requirements of the use case. Initially they need only be brief; because they are used to summarise the business requirement from the point of view of users. However, later in the process, software developers need far more specific and detailed guidance. Rational Unified Process invites developers to write a brief use case description in the diagram, with a casual description as comments and details description of the flow of event in a textual analyse. All those can usually be input in the UML software, or can be written seperately in a text editor.
USE CASE TEMPLATES There is no standard template for documenting detailed 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 within each project is more important than the detail of a specific template. There is, however, considerable agreement about the core sections; beneath differing terminologies and orderings 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 name The use case name provides a unique identifier for the use case. It should be written in verb-noun format (e.g., ''Borrow Books'', ''Withdraw Cash''), should describe a completable goal (e.g., ''Register User'' is better than ''Registering User'') and should be sufficient for the end user to understand what the use case is about. Goal-driven use case analysis will name the use cases according to the Actor's goals thus ensuring use cases are strongly user centric. Two to three words is the optimum length. If four or more words are proposed in the name there is usually a shorter better name that can be used. Iteration Often 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 from the 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. Summary The ''summary'' section is used to capture the essence of the use case 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. Ideally a summary is just a few sentences or a paragraph in length and includes the goal and principal actor. Preconditions A ''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. Where one or more preconditions are not met, the behaviour of the use case should be considered indeterminate. Triggers The ''Triggers'' section describe the starting condition(s) which cause a use case to be initiated. Can be external, temporal or internal Basic course of events At 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: # The system prompts the user to logon. # The user enters his name and password. # The system verifies the login information. # The system logs user on to system. ...and so on. Alternative paths Use cases may contain secondary paths, or alternative 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: # The system recognizes cookie on users machine. # Go to step 4 (Main path) An example of an exception path would be: :3. The system does not recognize users logon information :4. Go to step 1 (Main path) Postconditions The ''post-conditions'' section summarizes the state of affairs after the scenario is complete. Business rules Business 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. Notes Experience 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 date This 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. USE CASES AND THE DEVELOPMENT PROCESS The specific way use cases are used within the development process will depend on which development methodology is being used. In certain development methodologies, a brief Use Case Survey is all that is required. In other development methodologies, the use cases evolve in complexity and change in character as the development process proceeds. In some methodologies, they may begin as brief business use cases, evolve into more detailed system use cases, and then eventually develop into highly detailed and exhaustive test cases. BENEFITS OF USE CASES Use 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 CASES Use cases are not without their limitations:
SOFTWARE See also the List Of UML Tools . SEE ALSO EXTERNAL LINKS
|
|
|