use case creation training

Welcome to Use Case Model Development Training- Specifying Requirements Using Use Case Diagrams Prepared on November 22nd 2010 :

Welcome to Use Case Model Development Training- Specifying Requirements Using Use Case Diagrams Prepared on November 22 nd 2010

Training Agenda:

Training Agenda What is meant by Requirement Types of requirements History about use case What does a use case meant? ‘Who’ can do ‘what’ Based on the degree of detail (brief, casual, and full dressed – Alistair Cockburn) Use case relationships (generalization, association, include, extend) Different ways to determine a use cases Creating a normal flow / success scenario/happy flow Identify and documenting the alternate flows Determining the exceptional flow Modeling a use case Standard UML notations for use case modeling Documenting a use case ( who, what, when-frequency of occurrence, where, and how-represents the functional specification, Effective usage of extend and include property of a use case Questions & Answers

Learning Outcome:

Learning Outcome Understand and recollect what is meant by requirements Know different types of software requirements Understand the meaning of use case Able to create use case model diagrams using UML notations Understand and create use case elements Appreciate the need of use case modeling as essential part of software requirements development.

Requirement Defined:

Requirement Defined A condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents. A documented representation of a condition or capability.

Sources of Requirement:

Sources of Requirement Initial requirements come from the customer, by: Documents, such as RFI/RFP Meetings, reports Advanced requirements come from the analysts, after studying: Scope and price Feasibility (technological, organizational etc) Prototypes Final requirements are stabilized in an iterative process. Requirements Sources Stakeholders Regulators Legacy Systems Customers

Requirement Types:

Requirement Types Business Requirements High level objective of the organization or the Goal of the project to be achieved. What the customer desire and needs who request the system. Examples There should be an alternate channel through which the customers will be able to buy tickets using the internet. The product should allow sending of automated marketing campaigns to our customers. The system should provide opportunity to promote the products online to customers. Conti…

Requirement Types:

Requirement Types User Requirements Describes the user goals or tasks that user must be able to accomplish using the product. Represents ‘what’ the user will be able to perform with the system or product. Examples Customers should be able to ‘view list of trains between stations.’ Should be able to ‘View the past booked history.’ I should be able to ‘Add products to shopping cart.’ Conti…

Requirement Types:

Requirement Types Functional Requirements Represents the software functionality the developers must build enabling the users to perform the user tasks leading to achieve the business requirements. It is driven towards the behavioral aspects of the system to be implemented. Helps developers in design, developments, testing the product. Examples System shall send an email confirmation of the booked tickets to the customers. System shall display the recent 5 orders booked in the order history summary. System shall generate a unique ID for each placed orders. System shall allow the run the monthly sales report by Sales Area, Sales Executives. Conti…

Requirement Types:

Requirement Types Non- Functional Requirements Describes the system or products quality attributes. Typically represents the Usability, Portability, Integrity, Efficiency, Maintainability, Durability, Extensibility, etc., Examples The website should open within 5sec after providing the IRCTS web address. Should be able to handle 1,000,000 number of hits at any given time. System should allow to add change of name when an employee gets married. Product would allow developers to easily migrate to Java technology in the future. Conti…

Quick Recap!:

Quick Recap! What is a requirements? Types of requirements Business User Functional Non-Functional or Quality Sources of various requirements types.

Requirements Relationships:

Requirements Relationships Stakeholder Goals and objectives User Requirements Use cases Functional Requirements Business Rules User Interface Requirements Design Specifications Data Requirements Interfacing System Requirements Quality Requirements

User Requirements:

User Requirements Common methods used to capture user requirements are: Usage / User scenario Use Case approach E-R (Event-Responses) table.

History about Use Case:

History about Use Case In 1986, Ivar Jacobson, later an important contributor to both the Unified Modelling Language (UML) and the Rational Unified Process (RUP), first formulated the visual modelling technique for specifying use cases. Originally used the names usage scenarios or usage case , then, later renamed it as Use Case . In 1990’s use cases became one of the most common practices of capturing the functional requirements. Use case support objected oriented development approach.

Requirements Elicitation ‘Use Case Approach’:

Requirements Elicitation ‘Use Case Approach’ Use case forms part of Requirements development process. One of the useful technique in requirements elicitation and modeling workshops . A necessary prerequisite to know what the users intended to with the system or product! Illustration Use Case Use case in diagram Use Case in script Actor

What Use Case mean?:

What Use Case mean? A use case describes a system behavior and response when triggered by an request outside of the system. Typically a use case tells ‘Who’ can do ‘what.’ F ocuses on describing how to achieve a goal or a task. Represents sequence of interactions between a System and an external Actor. Captures a system’s behavioral requirements using usage scenario. Scenario represents a single instances of usage of the system. Conti… Use Case System-Actor Interaction System Scope Primary & Secondary Actors User Goal/Task

What Use Case mean?:

What Use Case mean? Typically use case treat system under analysis as Black Box . Primary focus is on what user should do rather than asking how the system should do what to be performed. Use case shall describe about: what should be accomplished by the user i.e goal and tasks. what system shall do to accomplish what user need. the conditions with specific to user goals and tasks.i.e. Business Rules. Use case should not explain about: how to implement the solution user Interface design elements and screen designs. system design requirements.

Use case - Actor:

Use case - Actor Actor represents a Person, another software system or a hardware device that interface with the system to achieve a useful goal. An Actor can be a Human or System or Sub-system. a.k.a User Role. Actors are roles the members of one or more user classes can perform with respect to the system. Examples Registered members, Ticket administrator, Booking agent, etc., Human System Sub-system Hardware

Types of Use case:

Types of Use case Based on the scope of usage use case is of 2 types: Business Use case high level use cases details what the business process does will describe a process that provides value to the business actor, and it describes what the process does considers system as Black Box and describes the business process used by actors to achieve the goal. Examples Manage customer information, Manage ticket history, etc.,

Types of Use case:

Types of Use case Based on the scope of use age use case is of 2 types: System Use case describe what system does and actor performs. Uniquely identified using Verb + Object combination words. Typically describes the system functionality Examples View History, Cancel Ticket, Pay Bill

Types of Use case:

Types of Use case Based on the degree of writing levels: Casual – Few lines of description Brief – Contains few paragraphs of what use case does. Fully Dressed – Completely documented using a use case template

Use case Modeling:

Use case Modeling Use case diagrams provide a high-level visual representation of the user requirements. Describes the levels of relationship between the different Actors and the Systems/sub-systems. Represents the system scope in terms of user requirements. Specified using OMG’s Unified Modeling Language (UML) notations or SysML (System Modeling Language)

Use case Modeling UML Notations:

Use case Modeling UML Notations Represents an Association between Actor and System

Use case Determination:

Use case Determination Identify the Actors and the respective business tasks/goals performed. Identification of the business processes and then mapping to use case and actors. Find Tasks and then map with user role Find Business Process and then derive use cases and actor roles

Essential Use case Elements:

Essential Use case Elements Each use case will have the following essential elements: A Unique Identifier (e.g. UC_01_Successful Logon) A name which will state the actor task. Use Verb+Noun(Object) combination . (e.g. Plan my Trip) Short description of the use case. List of Pre-conditions Post-conditions that will state the successful user outcome. Actor-System interaction scenario showing the normal course of steps user will follow to achieve that specific use case goal. It can also be represented using simple steps. This is also called as Happy Path or Normal Path or Basic Flow. Steps should be explained in normal layman English terms. Alternative Paths (AR) Exceptional Paths Business Rules (BR) Use case Priority Author and Date of Creation An Example “Happy Path” The system prompts the user to log on The user enters his email ID and password, The system verifies the logon information The system logs user on to system A Success Scenario Describes the most normal path which the actor performs to achieve their goal. Does not take into account the errors and exceptions. also called as Happy Path or Basic Flow

Use case Alternative Paths:

Use case Alternative Paths Basic flow can branch off at a specific step leading towards an alternative path. Alternative path or secondary scenario also results in successful task completion and satisfies a use case post-condition. An activity diagram would provide the step at which the system will break into an alternate path. They are referenced to the step in the basic flow. Examples Search train name using train number, quick book a ticket

Use case Exceptional Paths:

Use case Exceptional Paths These are basically to identify and represent what happens when something wrong happens at the system level. Exceptional flow is a kind of alternative flow. However, it is good practice to keep them unique and separate. Examples Train Name entered is incorrect, Member ID entered is incorrect.

Use case – Relationships:

Use case – Relationships In UML modeling a relationship represents a connection between model elements. The following presents the relationships that can be used in the use case diagrams: Association Generalization Include Exclude

Use case – Relationships:

Use case – Relationships Association Relationship between two classifiers, such as classes or use cases. Describes the reasons for the relationship and the rules that govern the relationship Generalization Generalization relationship is a relationship in which one model element (the child) is based on another model element (the parent). Include Is a relationship in which one use case (the base use case) includes the functionality of another use case (the inclusion use case). The include relationship supports the reuse of functionality in a use case model. Extend Extend relationship specifies that one use case (extension) extends the behaviour of another use case (base). Reveals details about a system or application that are typically hidden in a use case.

Use case – Benefits:

Use case – Benefits Use cases provide a good basis for the verification of the higher-level models and for the validation of the functional requirements (via acceptance testing). Use cases provide an objective means of project tracking in which earned value can be defined in terms of use cases implemented, tested, and delivered. Use cases can form the foundation on which to specify end-to-end timing requirements for real-time applications.

Use case – Exercise:

Use case – Exercise Let’s try to create a use case by identifying the essential elements.

Remember & Recollect! Summary:

Remember & Recollect! Summary Meaning of Requirements Types of Requirements Business User Functional Non-Functional Relationship between requirements Use case definition Type of use case (Business & System) Use case diagram Use case UML notations Use case relationships Use case benefits

Thank You Question & Answers? Please forward any queries and feedback to grafinfly@gmail.com:

Thank You Question & Answers? Please forward any queries and feedback to grafinfly@gmail.com