2 Outline Introduction Use case model Unified Modeling Language Actor Use casesUC Description PropertiesRelationships between ActorsUse Case RelationshipsSharif Univ. of Tech.
3 IntroductionThe main purpose of the Requirements discipline is to establish and maintain agreement with the customers and other stakeholders on what the system should do.To this aim, the discipline produces some artifacts such as: Vision, Stakeholder requests, requirements management plan, supplementary specifications, Use-Case model, etc.But the one which is more useful in the next steps of the process is Use-Case Model. Because it is a common language between people in the project team and also other stakeholders.Sharif Univ. of Tech.
4 Introduction (Cont.)One of the most important artifacts of the requirements disciplines is use-case model.Sharif Univ. of Tech.
5 Use case modelUse cases are usually described in a textual document that accompanies a use case diagram; the combination of these use case diagrams & their supporting documentation is known as a use case modelIllustrate a system’s intended functions (use cases), its surroundings (actors) & the relationships between them (use case diagrams)Are used to communicateProvide a vehicle used by customers & developers to discuss the system’s functionalitySharif Univ. of Tech.
6 Unified Modeling Language The Unified Modeling Language (UML) is the industry-standard language for specifying, visualizing, constructing & documenting artifacts of complex software systemsThe UML:Is a languageApplies to modeling and systemsIs based on the object-oriented paradigmSharif Univ. of Tech.
7 ActorSomeone or something that interacts with the system (exchanges information with the system)Typically, an actor represents a role that a human, a hardware device, or even another system plays with a system.use case is always initiated by an actorFinding the actors also means that you establish the boundaries of the systemA single user may play more than one roleSharif Univ. of Tech.
8 Identifying Actors Who will use the main functionality of the system? Who is interested in a certain requirement?Who will need to maintain, administrate and keep the system working?With which other software/hardware systems does the system need to interact?Other computer systemsOther applications on the same computer (I.e. X client/server)Pitfall: don’t confuse interaction with inputSharif Univ. of Tech.
9 Notation Operator is the only actor of the model. OperationA simple Use-Case Model:Operator is the only actor of the model.Operator is the initiator of the Operation Use Case.Sharif Univ. of Tech.
10 Use casesA use case describes a set of sequences, in which each sequence represents the interaction of the things outside the system (its actors) with the system itselfUse cases form the basis of how the system interacts with the outside world (users, other systems, etc.)“A use case is a sequence of transactions in a system whose task is to yield a measurable value to an individual actor of the system”Describes WHAT the system (as a “Black Box”) does from a user’s perspectiveA set of scenarios tied together by a common user goalSharif Univ. of Tech.
11 Why Use Case? Captures functional requirements from user’s perspective Gives a clear and consistent description of what the system should doA basis for performing system testsProvides the ability to trace functional requirements into actual classes.Serves as a unit of estimationThe smallest unit of deliverySharif Univ. of Tech.
12 People who use use cases. Customers will use the use cases to understand the system's behavior, and, since they must approve the use case's flow of events, customer will also use the use cases to approve the result of use-case modeling.Potential users will use the use case to understand the system's behavior.Software Architects will use the use cases to identify architecturally significant functionality.People who analyze, design, and implement the system will use the use case to understand the required system behavior and to refine the system.Use-case designers will use the use cases' flows of events to find classes. (These are the most important artifacts for use-case designers.)Testers will use the use cases as a base for identifying test cases.Managers will use the use cases to plan and follow up the use-case modeling.Documentation writers will use the use cases to understand what sequence of use should be described in the documentation (such as the system user guide).Sharif Univ. of Tech.
13 Finding Use Cases For each of the actors previously defined: Which services does the actor require from the system?Read, create, destroy, modify, store informationDoes the actor have to be notified about events in the system, or does the actor need to notify the system about something?Could the actor’s daily work be simplified?Don’t concentrate only on the current systemSharif Univ. of Tech.
14 Validating Use Cases Is the use case complete? Is the actor’s goal going to be met?Are there any changes that would simplify the process depicted in the use case?Are there any additional goals that are not addressed?Are there any additional actors that are not represented?Sharif Univ. of Tech.
15 UC Description Properties NameName of use case, usually close to the user’s goalForward traceability (unique)DescriptionA brief description of the role and purpose of the use case.Flow of Events (Main Flow)A textual description of what the system does in regard to the use case (not how specific problems are solved by the system). The description is understandable by the customer.Alternative flowsA textual description of the exceptional paths in the main flow of the use-caseSharif Univ. of Tech.
16 UC Description Properties (cont.) Pre-conditionsThe necessary conditions that have to be met before the use case can be performedCould be other Use Cases as well (not equivalent to <<include>> at the beginning of the description)Post-conditionsThe state of the system after the use case is performedThe value delivered to the actorDistinguishes between variations and exceptionsSpecial RequirementsA textual description that collects all requirements, such as non-functional requirements, on the use case, that are not considered in the use-case model, but that need to be taken care of during design or implementation.Reference to requirementsBackward traceabilitySharif Univ. of Tech.
17 Some Notes The first four properties construct UC outline. Business UC are which describe current system.Basic flow denotes successful scenario which should also contain:How the UC will be started.How the UC will be finished.Sharif Univ. of Tech.
18 Recommended WorkflowIdentify actors (and their relationships if necessary)For each actor identified and until no new UC is discovered doFind all the goals of the actorDecide on the main course of success for each goalCreate a Use Case for each of the goalsNew actors/goals may be discoveredValidate/correct existing Use CasesDraw the Use Case diagramSimplify model by repeating the process incase the produced diagram is too complexSharif Univ. of Tech.
19 Relationships between Actors When several actors as part of their roles, also play a more generalized role, it is described as generalizationThe behavior of the general role is described in an actor super-classThe specialized actors inherit the behavior of the super-class and extend it in some wayRelationships between actors are not always necessaryManagerSupervisorClerkSharif Univ. of Tech.
20 Use Case Relationships Include relationship (“uses” in older versions)When a number of Use Cases have common behavior, this behavior can be modeled in a single use case that is used by the other use casesX << includes >> Y indicates that the process of doing X always involves doing Y at least onceBeware of functional decompositionsThe included Use Case must be completeX must satisfy the pre-conditions of Y before including it<< include >>XYSharif Univ. of Tech.
21 Use Case Relationships (cont.) Generalization relationshipUsed when a number of Use Cases all have some subtasks in common, but each one has something different about it that makes it impossible to lump them all in a single use caseThe generalized and specialized use cases must share the same goalA specialized Use Case may capture an alternative scenario of the generalized Use CaseThe generalized Use Case must be completeThe Specialized use case may interact with new actors.The Specialized use case may add pre-conditions and post-conditions (AND semantics).SpecializedGeneralizedSharif Univ. of Tech.
22 Use Case Relationships (cont.) Extend relationshipModel conditional, or optional behavior in a business use case by describing the workflows in different use cases, where conditional or optional behavior is distinguished from mandatory behavior.Model a complex workflow that seldom occurs.Model a separate subflow that is only run under certain conditions.Model several different business use cases that can be inserted at a certain point (the order being governed by the business actorSharif Univ. of Tech.
23 Use Case Relationships (cont.) Extend relationshipThe business use cases being extended have to be meaningful and complete in themselves, even if the workflow of the added business use case is not executed.Sharif Univ. of Tech.