Writing Effective Use Cases

Harsh Jegadeesan’s CLASSROOM EFFECTIVE USE-CASE WRITING BITS Pilani Off-Campus Work-Integrated Learning Programmes

AGENDA Requirements Engineering What is a Use-Case? Sections in a Use-Case Goals & Scope of Use-Case 4 Steps to Use-Cases Supplementary Specification 2 9/22/2008 Object Oriented Analysis & Design

ACKNOWLEDGEMENT This part of the lecture is based on: Integrated Requirements Engineering: A Tutorial Ian Sommerville, Lancaster University International Requirements Engineering Conference (RE ’04). A copy of this could be got from: IEEE Software January- February 2005 3 9/22/2008 Object Oriented Analysis & Design

MOTIVATION FOR REQUIREMENTS ENGINEERING Before any software system is developed: We must understand what the system is supposed to do How its use can support goals of individuals / organizations This involves: Understanding Application Domain Systems Operational Constraints Specific Functionality Required by stake-holders Essential characteristics like performance, security, reliability and dependability 4 9/22/2008 Object Oriented Analysis & Design

WHAT IS REQUIREMENTS ENGINEERING? Requirements Engineering is the structured set of activities which: Help develop system understanding Identifying stake-holders and needs Document system specification for stake-holders and engineers involved Challenges: Numerous and distributed stake-holders Varying and conflicting goals Difficulties in Articulating these goals 5 9/22/2008 Object Oriented Analysis & Design

RELATIVE COSTS OF FIXING SOFTWARE FAULTS 200 30 10 3 4 1 2 6 Requirements Specification Planning Design Implementation Integration Maintenance 9/22/2008 Object Oriented Analysis & Design

THE FUNDAMENTAL PROCESS DISCLAIMER RE varies significantly with: - Size and type of the application developed - Size and Culture of the companies involved - The Software Acquisition Process For Instance, Large Military and Aerospace Projects – Formal RE Small Companies – RE is Brainstorming 7 9/22/2008 Object Oriented Analysis & Design

THE RE ACTIVITY CYCLE 8 Courtesy: The Integrated Requirements Engineering: A Tutorial 9/22/2008 Object Oriented Analysis & Design

ELICITATION Process: Identify sources of information about the system and discover requirements from these Identifying stakeholders & user classes Customers or Clients Developers Users - novice users, expert users, occasional users, disabled users Goals & Tasks Focus on Problem domain And needs of stakeholders 9 Scenarios & Use cases 9/22/2008 Object Oriented Analysis & Design

ELICITATION -TECHNIQUES Elicitation Techniques Traditional techniques Questionnaires, surveys, interviews, documents Group elicitation techniques Prototyping Model-driven techniques Cognitive techniques Contextual techniques Need for guidance on use of these Techniques 10 9/22/2008 Object Oriented Analysis & Design

THE RE ACTIVITY CYCLE Courtesy: The Integrated Requirements Engineering: A Tutorial 11 9/22/2008 Object Oriented Analysis & Design

ANALYSIS Process: Understand the Requirements their overlaps and conflicts Enterprise Modeling Organizational Structure Business Rules Data Modeling Entity-Relationship-Attribute Behavioral Modeling Functional behavior of Stakeholders. Existing Required 12 9/22/2008 Object Oriented Analysis & Design

ANALYSIS [2] Domain Modeling Abstract description of the world Advantage: Requirement reuse within a domain Advantage: detailed reasoning about the domain Modeling Non-Functional Requirement Difficult to measure and test Analyzing Requirement Models Requirement animation, automated reasoning 13 Knowledge based critique, consistency check 9/22/2008 Object Oriented Analysis & Design

VALIDATION Process: Go back to system stake-holders and find out whether requirements are what they really need A prototype may be needed to capture requirements depending on the software process that is followed. Validation of requirements could be done using a throw-away prototype or through incremental development 15 9/22/2008 Object Oriented Analysis & Design

NEGOTIATION Process: Inevitably, stakeholders’ views will differ, and proposed requirements might conflict. Try to reconcile conflicting views and generate a consistent set of requirements. Negotiation must be done using techniques like group discussions whereby all the stake-holders are in a common platform. This helps in the emergence of a clear holistic view from the stakeholders’ end. 17 9/22/2008 Object Oriented Analysis & Design

DOCUMENTATION AND MANAGEMENT Write down the requirements in a way that stakeholders and software developers can understand. Control the requirements changes that will inevitably arise. This leads to effective communication of requirements (Improving Requirements Engineering Communication in Multiproject Environments) 19 9/22/2008 Object Oriented Analysis & Design

OUTCOME OF RE PROCESS Statement of Requirements (a.k.a A Requirements Document) that defines what is to be implemented Research Community argues that, more complete and consistent a requirement document is more likely that the software would be reliable Formal Description Vs Natural Language Description Formal – Complete, Concise yet costly Natural Language – Vague, client disputes yet cheap during changing requirements 20 9/22/2008 Object Oriented Analysis & Design

WHAT IS A USE-CASE? “A set of user instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor” Actor – Something with a behavior such as person, computer system etc. Scenario – Specific sequence of actions and interactions between actors and system under discussion (SuD) 22 9/22/2008 Object Oriented Analysis & Design

ACTORS Actors have ‘goals’ in the system There are three kinds of actors Primary Actor: has user goals fulfilled through using services of the SuD Supporting Actors: provides a service to the SuD E.g. Automated payment authorization service Offstage Actor: has interest in the behavior of the use-case E.g. Government tax Agency 23 9/22/2008 Object Oriented Analysis & Design

SCHEMATIC DIAGRAM AN ACTOR HAS GOALS; GOALS NAME USE CASES; A USE CASE HAS SCENARIOS NAMING SUB-USE CASES. Actor has Goal names Use case contains calls condition Scenario succeed / fail 24 Courtesy: Use-Cases in Theory & Practice, Alistair Cockburn 9/22/2008 Object Oriented Analysis & Design

ALISTAIR COCKBURN’S DEFINITION Use-Case : Purpose = requirements Contents = consistent prose Plurality = multiple scenarios per use case Structure = semi-formal 25 9/22/2008 Object Oriented Analysis & Design

KEY POINTS ABOUT USE-CASES Use-cases are requirements, primarily functional requirements Use Cases are text documents, not diagrams and use-case modeling is primarily an art of writing texts, not drawing Any use-case must add observable value to an actor Use-Cases are important part of the iterative planning Use-Case realizations drive design 26 9/22/2008 Object Oriented Analysis & Design

USE CASE TYPES Define ‘what’ the system must do (functional requirements) without deciding ‘how’ it will do it (design)- Black Box Use-cases Formality Types: Brief: Terse one-paragraph summary; covers main success scenario Casual: multiple paragraphs; cover various scenarios Fully dressed: most elaborate; all steps and variations are discussed in detail (www.usecases.org format) 27 9/22/2008 Object Oriented Analysis & Design

ALISTAIR COCKBURN’S TEMPLATE Run through of Alistair Cockburn’s Template 29 9/22/2008 Object Oriented Analysis & Design

SECTIONS IN USE-CASE Primary Actor Principal actor who calls upon system services to fulfill a goal Stakeholders and Interests Contract between stakeholders within the system boundary Pre-Conditions / Post-Conditions Pre-conditions must always be true before starting Post-Conditions suggest what might be true on success 30 9/22/2008 Object Oriented Analysis & Design

SECTIONS IN USE-CASE [2] Main Success Scenario (Basic Flow) ‘Happy path’ scenario Defer all conditional and branching statements to the extension section A Scenario could be three types: Interaction between actors A validation by the system A state change by the system 31 9/22/2008 Object Oriented Analysis & Design

SECTIONS IN USE-CASE [3] Extensions (Alternate Flow) Indicates all other scenarios or branches, both success and failure These branches are from the main scenario and hence labeled ‘1a’, ‘3b’ etc At the end of the extension, the scenario merges back with the main success scenario Sometimes a particular extension point might be quite complex and might be expressed as a separate use-case E.g. ‘Paying by Credit card’ 32 9/22/2008 Object Oriented Analysis & Design

SECTIONS IN USE-CASE [4] Special Requirements If a non-functional requirements relates specifically to a use-case then record it with the use-case These are normally qualities like performance, reliability and usability Technology and Data variation list ‘How’ something must be done Technical constraint imposed by the stakeholder and hence necessary to capture 33 9/22/2008 Object Oriented Analysis & Design

INCREASING LEVELS OF PRECISION Actor and Goals List of Actors and which of their goals the system would support. Use-Case Brief or Main Success Scenario Pursue main success scenario Failure Conditions Based on MSS, deliberate all failures that could occur Do not worry about Failure handling at this step Failure Handling How system is supposed to respond to each failure. New business rules, new actors and goals could 34 surface 9/22/2008 Object Oriented Analysis & Design

CHALLENGES IN USE-CASE DISCOVERY Tasks can be grouped at many levels of granularity from one or a few small steps to enterprise level activities We use Elementary Business Processes (EBP) and Goals as a framework to identify use-cases Which is a valid use-case? Negotiate a Supplier Contract Handle Returns Log In All these are valid at different levels 36 9/22/2008 Object Oriented Analysis & Design

EBP GUIDELINE For requirements analysis focus on use-cases at the level of a Elementary Business Process (EBP) Caveat Although base-use cases must follow the EBP guideline, there could be sub-use cases which exists at a lower level Actors have goal a EBP use-case is called a user- goal level use-case, this leads to a recommended procedure 1. Find the user goals 2. Define a use-case for each 37 9/22/2008 Object Oriented Analysis & Design

INVESTIGATING USER GOALS VS. INVESTIGATING USE-CASES Goal Hierarchy Prevent theft, data corruption Identify to the system Cashier at PoS Scenario 1. Quickly log-in Sub-goal Log In 2. Capture Sales Main Goal / Base use-case 38 9/22/2008 Object Oriented Analysis & Design

DESIGN SCOPE VS. GOAL LEVEL (SCOPE VS. LEVEL) Scope Which system boundary do we mean? “Spatial extent” of the system Level Why do we want this goal? “strategic” vs. “user task” vs. “sub-function” 39 9/22/2008 Object Oriented Analysis & Design

SCOPE Dept. 1 Dept. 3 Sys. 1 System Organization C1 C2 Component Dept. 2 C3 Sys. 2 Organization 40 9/22/2008 Object Oriented Analysis & Design

LEVEL project goal Strategic Goals “White” advertise order invoice “Blue” User Goals set up reference monitor place create send promotion promotion promotion order invoice invoice “Indigo” Subfunctions identify register user identify identify promotion product customer 41 9/22/2008 Object Oriented Analysis & Design

AGENDA Requirements Engineering What is a Use-Case? Sections in a Use-Case Design Scope & Goal Level of Use-Case 4 Steps to Use-Cases Supplementary Specification 42 9/22/2008 Object Oriented Analysis & Design

STEP I – CHOOSING SYSTEM BOUNDARY 1 Choosing the System Boundary -Clarified by defining what is outside -Once external Actors are identified the boundary becomes clear 43 9/22/2008 Object Oriented Analysis & Design

STEP 2 & 3 – FINDING PRIMARY ACTORS & GOALS 1 Choosing the System Boundary 2 Finding Primary Actors 3 Finding Goals Identify Primary Actors by asking questions e.g. Who start/stops the system? Actors have goals that must be satisfied 44 by the system 9/22/2008 Object Oriented Analysis & Design

ACTOR- GOAL LIST Courtesy: Applying UML & Patterns, Craig Larman 9/22/2008 Object Oriented Analysis & Design 45

STEP 4 – DEFINE USE-CASES 1 Choosing the System Boundary 2 Finding Primary Actors 3 Finding Goals 4 Define Use-Cases Start use-cases with a verb CRUD goals into one use-case Manage ‘X’ 46 9/22/2008 Object Oriented Analysis & Design

SUPPLEMENTARY SPECIFICATIONS Apart from use-cases, there are other kind of requirements Documentation Packaging Supportability Licensing More of non-functional in nature for the scope of the entire SuD 48 9/22/2008 Object Oriented Analysis & Design

REFERENCES Applying UML & Patterns, Craig Larman Text: Part II - Inception 6,7,8, 25 Writing Effective Use-cases, Alistair Cockburn www.usecases.org for the Use-case Template 49 9/22/2008 Object Oriented Analysis & Design

http://www.betterprojects.net	149
http://www.slideshare.net	45
http://www.pmtoolbox.com	1
http://www.lmodules.com	1
http://translate.googleusercontent.com	1

Writing Effective Use Cases

by Harsh Jegadeesan on Sep 22, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 197

Statistics

Writing Effective Use Cases — Presentation Transcript