Overview >

Guidelines >

Requirements: Use-Case Model

Guidelines: Use-Case Model
The use-case model is a model that describes a system's requirements in terms of use cases.

Use-Case Model Topics         
Explanation How the use-case model evolves Avoiding functional decomposition Non-functional requirements The what versus how dilemma Concrete and abstract use cases Structuring the use-case model Are use cases always related to actors? The survey description

A use-case model is a model of the system's intended functions and its surroundings, and serves as a contract between the customer and the developers. Use cases serve as a unifying thread throughout system development. The same use-case model is the result of the Requirements discipline, and is used as input to Analysis & Design and Test disciplines. The diagram below shows a part of a use-case model for the Recycling-Machine System.

A use-case diagram, showing an example of a use-case model with actors and use cases.

There are many ways to model a system, each of which may serve a different purpose. However, the most important purpose of a use-case model is to communicate the system's behavior to the customer or end user. Consequently, the model must be easy to understand. The users and any other system that may interact with the system are the actors. Because they represent system users, actors help delimit the system and give a clearer picture of what it is supposed to do. Use cases are developed on the basis of the actors' needs. This ensures that the system will turn out to be what the users expected.

How the Use-Case Model Evolves

Example: In the Recycling-Machine System. They are often requirements that specify need of compliance with any legal and regulatory requirements. and that together they can provide what the customer wants. the use-case model should be reviewed by the customer to verify that all the use cases and actors are found. Example: . the use cases and the actors should be briefly described. watch for the following symptoms:    "Small" use cases. performance. These descriptions show how the system interacts with the actors and what the system does in each individual case. rather than a multiple of ten. Use-case names that are constructions like "do this operation on this particular data" or "do this function with this particular data". Before the use cases are described in detail. To avoid functional decomposition. the flow of events of each use case is described in detail. meaning that the description of the flow of events is only one or a few sentences. the completed use-case model (including the descriptions of use cases) is reviewed. Many non-functional requirements apply to an individual use case and are captured within the properties of that use case. you should make sure that the use-case model helps answer questions like:     What is the context of the system? Why is the system built? What does the user want to achieve when using the system? What value does the system add to the users? Non-Functional Requirements It is quite easy to see that use cases are a very good way of capturing functional requirements on a system. In that case. As they are discovered. Avoiding Functional Decomposition It is not uncommon that the use-case model degenerates into a functional decomposition of the system. "Enter Personal Identification Number in an ATM machine" should not be modeled as a separate use case for the ATM machine.Both the actors and the use cases are found by using the requirements of customers and potential users as vital information. and substitutabilityrequirements (see also Concepts: Requirements). In an iterative development environment. But what about the non-functional requirements? What are they and where are they captured? Non-functional requirements are often categorized as usability-. Finally. or as a special requirement of the use case (see Guidelines: Use Case). compatibility issues. In general. "Many" use cases. They can also be design constraints due to the operating system used. Such requirements are captured in the Supplementary Specifications (see Artifact: Supplementary Specifications). they are captured within the flow of events of the use case. When the actors and use cases have been found. To avoid this. since no one would use the system to do just this. For example. and the developers and customers use it to agree on what the system should do. you will select a subset of use cases to be detailed in each iteration. Often the non-functional requirements apply to the whole system. A use case is a complete flow of events that results in something of value to an actor. you can say that any requirement that does not allow for more than one design option should be regarded as a design constraint. meaning that the number of use cases is some multiple of a hundred. the platform environment. a non-functional requirement specific to the Return Deposit Items use case could be: The machine has to be able to recognize deposit items with a reliability of more than 95 percent. reliability. or any application standards that apply.

An abstract use case is never instantiated in itself. When a concrete use case is initiated. The What Versus How Dilemma One of the more difficult things is to learn how to determine at what level of detail the use cases should "start and end". Consider the following graph: One person's destination is another's starting point. The distinction between the two is important. and where does use cases end and design begin? We often say that use cases or software requirements should state "what" the system does. no separate instances are created from abstract use cases. Abstract use cases are included in. a non-functional requirement that applies to the whole system could be: The machine will allow only one user at a time. This needs to be taken into consideration when determining whether or not a certain detail should be left out of the use-case model. Thus.In the Recycling-Machine System. Depending on your background. Where does features start and use cases begin. Concrete and Abstract Use Cases There is a distinction between concrete and abstract use cases. A concrete use case is initiated by an actor and constitutes a complete flow of events. You indicate that a use case is abstract by writing its name in italics. Example: . because it is concrete use cases the actors will "see" and initiate in the system. you will use a different context to decide what you think is "what" and what is "how". an instance of the use case is created. "Complete" means that an instance of the use case performs the entire operation called for by the actor. This instance also exhibits the behavior specified by its associated abstract use cases. but not "how" it does it. extend into. or generalize other use cases.

Create Task. To structure the use cases. The child use cases can insert new behavior and modify existing behavior in the structure they inherit from the parent use case. since they have slightly different properties. It is useful to separate ordinary Customer from Internet Customer. When Register Order is initiated. There is no point in structuring the use cases until you know a bit more about their behavior. their common parts can be factored out to a base use case (parent) that is inherited by addition use cases (children). If there are use cases that have commonalties in behavior and structure and similarities in purpose. You can use actor-generalization to show how actors are specializations of one another. Structuring is. The concrete use cases in this diagram are Phone Order (initiated by the Customer actor) and Internet Order (initiated by Internet Customer). Create Task is an abstract use case. not the method used to produce the result. In the Depot-Handling System the abstract use case. Create Task is therefore an abstract use case. apart from following Register Order's flow of events. These use cases are both variations of the more general Place . or that are specializations or options to the use case. beyond a one sentence brief description. The use case that represents the modification is called the addition use case. you can say that Internet Customer is a specialization of Customer. is included in the use case Register Order. not the first thing you do. You should at least have established a step-bystep outline to the flow of events of the use case.    If there is a part of a base use case that represents a function of which the use case only depends on the result. Structuring the Use-Case Model There are three main reasons for structuring the use-case model:    To make the use cases easier to understand. since Internet Customer does exhibit all properties of a Customer. The addition is implicitly inserted in the base use case. However. you can factor that part out to an addition use case. however. indicated with an actor-generalization. You will use these relationships to factor out pieces of use cases that can be reused in other use cases.The use case Create Task is included in the use case Register Order. The addition is explicitly inserted in the base use case. Example: Consider part of the use-case model for an Order Management System. To partition out common behavior described within many use cases To make the use-case model easier to maintain. always as a part of Register Order (or any other use cases in which it is included). or not necessary to understand the primary purpose of the use case. you can factor that part out to an addition use case in order to simplify the structure of the base use case. using the extend-relationship. If there is a part of a base use case that is optional. Create Task is never performed by itself. also follows the flow of events described in the included use case. to make sure that your decisions are based on an accurate enough understanding of the behavior. we have three kinds of relationships. Create Task. an instance of Register Order is created that. The use case that is modified is called the base use case. using the include-relationship.

Yes. The extension implicitly modifies the behavior of the base use case. . Does the base use Yes. no. express a condition on the inclusion you need to say it explicitly in the base use case. The Supply Customer Data use case represents a segment of behavior that was factored out since it is a separate function of which only the result is affecting the Place Order use case. The inclusion explicitly If the base use case (parent) is modifies the effect of the instantiated. Is the addition use case abstract? Is the base use case modified by the addition? Often yes.Order use case. If you want to No. but not Yes. which in this example is abstract. The following table shows a more detailed comparison between the three different use-case relationships: Question What is the direction of the relationship? Does the relationship have multiplicity? Extend The addition use case references the base use case. Together with the If it is abstract. No. To obtain the effects of the addition. Does the relationship have a condition? Yes. Both Request Catalog and Supply Customer Data are abstract in this example. the child. It has been factored out to an abstract use case to simplify the Place Order use case. that needs to be stated in the base use case. it is unaffected by base use case. If you want to No. include the same segment of behavior more than once. necessarily. No. Often no. Generalization The addition use case (child) references the base use case (parent). the addition use case (child) must be instantiated. on the addition side. The Supply Customer Data use case can also be reused in other use cases. The Request Catalog use case represents an optional segment of behavior that is not part of the primary purpose of Place Order. This use-case diagram shows part of the use-case model for an Order Management System. but it can be. Include The base use case references the addition use case.

The base use case (parent) must in this sense be wellformed in the absence of the addition (child). and nothing else. Having use cases that no one requests is an indication that something is wrong in the usecase model or in the requirements. However. . its behavior may not include interaction with any actor. The inclusion is encapsulated. Yes. No. However. A use case may be initiated according to a schedule (for example. In that case. The reason for this rule is to enforce the system to provide only the functionality that users need. Another aspect of organizing the use-case model for easier understanding is to group the use cases into packages. This implies that every use case should have communicatesassociations with actors. there are some exceptions to this rule:     If a use case is abstract (not separately instantiable). there will not be any communication-associations to actors from that abstract use case. once a week or once a day). which means the system clock is the initiator. with "leaves" that are actors or use cases. Yes. A use case instance is always started by an actor asking the system to do something. Arrows indicate possible ownership. Are Use Cases Always Related to Actors? The execution of each use case includes communication with one or more actors. you can use a fictive actor "Time" to show how the use case is initiated in your use-case diagrams. This graph shows the use-case model hierarchy. A base use case in an include-relationship does not need to have an actor associated with it if the inclusion use case describes all actor communication. No.and the use case is not initiated by an actor. No.case have to be complete and meaningful? Does the addition use case have to be complete and meaningful? Can the addition use case access attributes of the base use case? Can the base use case access attributes of the addition use case? No. yes. for clarity. If no other actor interaction occurs in the use case. it will not have any associations to actors. by the normal mechanisms of inheritance. A child use case in a generalization-relationship does not need to have an actor associated with it if the parent use case describes all actor communication. and only "sees" itself. Together with the base use case (parent). additions. but by an internal system event. The base use case must be well-formed in the absence of the addition. No. yes. The addition is encapsulated. No. The use-case model can be organized as a hierarchy of use-case packages. The base use case only knows about the effect of the addition. The system clock is internal to the system .

Specify functionality not handled by the use-case model. Summarize the system's environment. Administer Deposit Item. which allows an operator to change refund value for a type of deposit item. for example. Copyright: © 2011 École Polytechnique de Montréal . Point out system delimitations . Summarize important technical facts about the system. The primary use case is Recycle Items.things that the system is not supposed to do. Describe any sequences in which use cases are normally performed in the system. or add new deposit item types. which represents the main purpose of the Recycling Machine. which allows an operator to get a report on how many items have been recycled. Supporting use cases are:   Print Daily Report.The Survey Description The survey description of the use-case model should:       State which are the primary use cases of the system (the reason the system is built). target platforms and existing software. Example: Following is a sample survey description of the Recycling Machine's use-case model: This model contains three actors and three use cases.

Sign up to vote on this title
UsefulNot useful