USE Case Model

1. USE Case Model

2. Use-case model • The use case model captures the requirements of a system. Use cases are created based on identified functional requirements but are not mapped one-to-one to requirements • Use case models are a means of communicating with users and other stakeholders what the system is intended to do. • Use case models specify the expected behavior [what], and not theexact method of making it happen [how] • Use case models once specified can be denoted using a clear and precise visual modeling language such as UML

3. Scenarios • Ause-case is made up of a set of scenarios.  Each scenario is a sequence of steps that encompass an interaction between a user and a system.  The use case brings scenarios together that accomplish a specific goal of the user.

4. Scenarios • Specify behavior of use case by description, not modeling • Examples include informal structured text, formal structured text with conditions, and pseudo-code • Typically specifies: • How and when the use case starts and ends • Interaction with the actors and the exchange of objects • Flow of events: main / typical (success), alternative (success), and exceptional (failure) flows

5. Elements of a use-case description/scenario Use Case Name: ID: Importance Level: Primary Actor: Use Case Type: Stakeholders and Interests: Brief Description: Trigger: Relationships: (Association, Include, Extend, Generalization) Normal Flow of Events: Subflows: Alternate/Exceptional Flows:

6. Actor • An actor is a role that a user plays in the system.  • Represent roles that humans, hardware devices, or external • systems play while interacting with a given system • They are not part of the system and are situated outside of the system boundary • Actors may be both at input and output ends of a use case

7. Examples of actors • sales person • manager • support person • web store system It is possible that the same person may be a sales person and also provide support.  When creating a use case model, we are not concerned with the individuals, only the roles that they play.

8. Identifying Actors • Define system boundary to identify actors correctly • Identify users and systems that depend on the system’s primary and secondary functionalities • Identify hardware and software platforms with which the system interacts • Select entities that play distinctly different roles in the system • Identify as actors external entities with common goals and direct interaction with the system • Denote actors as nouns

9. Use-cases • A use case illustrates the activities that are performed by users of a system. • Use cases describe the activities of a system without specifying how the activities are implemented.

10. Identifying Use Cases • Business / Domain Use Cases: • Interactions between users and the business (or domain) • System Use Cases: • Interactions between users and the system • One business use cases contains a set of system use cases • To name the use cases, give it a verb name to show the action that must be performed • Describe a transaction completely • No description of user interface whatsoever

11. Capture use-cases • Capture use cases during requirements elaboration • Use cases are not mapped one-to-one to requirements • Each requirement must be covered by at least one use case • However, use cases may contain many requirements • Use scenarios to model assumptions and define system scope • List exceptions separately

12. Major steps in writing use-cases • Identify the major use-cases • Expand the major use-case • Confirm the major use-cases • Create the use-case diagram

13. Identifying the major use-cases • Identify the system’s boundaries • List the primary actors • List the goals of each primary actor • Identify and write the major use-cases • Carefully review use-cases

14. Expand the major use-cases • Choose one major use-case to expand • Fill in details on the use-case template • Fill in the steps of the normal flow of events • Normalize the size of each step • Describe alternate or exceptional flows • Simplify and organize as necessary

15. Confirm the major use cases • Review the current set • Consider semantics and syntax • Helpful to involve the users • Iterate the entire set of steps until all use cases are defined

16. Create the use-case diagram • Start with system boundary • Place elements in order to be easy to read • Place actors on the diagram • Conclude by connecting actors to use cases by lines

17. Use-case diagram • The use-case diagram allows a designer to graphically show these use cases and the actors that use them. 

20. Putting it all Together • When starting a use case model, it is very important to keep it simple.  Often it is easiest to first determine the actors of the system, and then flush out the use cases that they perform.  • Your use case diagrams can be as simple or complex as you wish, however simpler, less cluttered diagrams are easier to understand, and are often more powerful in capturing the tasks of the system. • Remember that a use case represents a goal of a user, not an atomic programming operation.  Your use case design should be simple and help to clarify the user's goals and expectations for the system.

21. Courseware System Task: Create a use case model for a system that can be used to manage courses and classes for an organization that specializes in providing training. The name of the system is Courseware System.

22. The organization offers courses in a variety of areas such as learning management techniques and understanding different software languages and technologies. Each course is made up of a set of topics. • Tutors in the organization are assigned courses to teach according to the area that they specialize in and their availability. • The organization publishes and maintains a calendar of the different courses and the assigned tutor every year. • There is a group of course administrators in the organization who manage the courses including course content, assigning courses to tutors, and defining the course schedule. • The training organization aims to use the Courseware System to get a better control and visibility to the course management and to also streamline the process of generating and managing schedules for different courses.