0
Harsh Jegadeesan’s CLASSROOM




EFFECTIVE USE-CASE WRITING




                                 BITS Pilani
             ...
AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Goals & Scope of Use-Case
4 Steps to Use-Cases
...
ACKNOWLEDGEMENT
             This part of the lecture is based on:

Integrated Requirements Engineering: A Tutorial
     I...
MOTIVATION FOR REQUIREMENTS
ENGINEERING

 Before any software system is developed:
      We must understand what the syste...
WHAT IS REQUIREMENTS ENGINEERING?
 Requirements Engineering is the structured set
 of activities which:
      Help develop...
RELATIVE COSTS OF FIXING SOFTWARE
FAULTS
                                                                                 ...
THE FUNDAMENTAL PROCESS
DISCLAIMER
RE varies significantly with:
 - Size and type of the application developed
 - Size and...
THE RE ACTIVITY CYCLE




                                                                                                ...
ELICITATION
Process: Identify sources of information about the
 system and discover requirements from these
   Identifying...
ELICITATION -TECHNIQUES
Elicitation Techniques
    Traditional techniques
          Questionnaires, surveys, interviews, d...
THE RE ACTIVITY CYCLE




              Courtesy: The Integrated Requirements Engineering: A Tutorial                     ...
ANALYSIS
Process: Understand the Requirements their
 overlaps and conflicts
 Enterprise Modeling
   Organizational Structu...
ANALYSIS [2]
 Domain Modeling
      Abstract description of the world
      Advantage: Requirement reuse within a
      do...
THE RE ACTIVITY CYCLE




              Courtesy: The Integrated Requirements Engineering: A Tutorial                     ...
VALIDATION
Process: Go back to system stake-holders and find
  out whether requirements are what they really
  need

  A p...
THE RE ACTIVITY CYCLE




              Courtesy: The Integrated Requirements Engineering: A Tutorial                     ...
NEGOTIATION
Process: Inevitably, stakeholders’ views will differ,
 and proposed requirements might conflict. Try to
 recon...
THE RE ACTIVITY CYCLE




              Courtesy: The Integrated Requirements Engineering: A Tutorial                     ...
DOCUMENTATION AND MANAGEMENT
 Write down the requirements in a way that
 stakeholders and software developers can
 underst...
OUTCOME OF RE PROCESS
 Statement of Requirements (a.k.a A
 Requirements Document) that defines what is to
 be implemented
...
AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Goals & Scope of Use-Case
4 Steps to Use-Cases
...
WHAT IS A USE-CASE?
“A set of user instances, where each instance is a
 sequence of actions a system performs that yields
...
ACTORS
 Actors have ‘goals’ in the system
 There are three kinds of actors
   Primary Actor: has user goals fulfilled thro...
SCHEMATIC DIAGRAM

AN ACTOR HAS GOALS; GOALS NAME USE CASES; A USE
CASE HAS SCENARIOS NAMING SUB-USE CASES.

       Actor
...
ALISTAIR COCKBURN’S DEFINITION
 Use-Case :
 Purpose = requirements
 Contents = consistent prose
 Plurality = multiple scen...
KEY POINTS ABOUT USE-CASES
 Use-cases are requirements, primarily functional
 requirements
 Use Cases are text documents, ...
USE CASE TYPES
 Define ‘what’ the system must do (functional
 requirements) without deciding ‘how’ it will do it
 (design)...
AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Goals & Scope of Use-Case
4 Steps to Use-Cases
...
ALISTAIR COCKBURN’S TEMPLATE

Run through of Alistair Cockburn’s Template




                                            ...
SECTIONS IN USE-CASE
 Primary Actor
   Principal actor who calls upon system services
   to fulfill a goal
 Stakeholders a...
SECTIONS IN USE-CASE [2]
 Main Success Scenario (Basic Flow)
  ‘Happy path’ scenario
  Defer all conditional and branching...
SECTIONS IN USE-CASE [3]
 Extensions (Alternate Flow)
   Indicates all other scenarios or branches, both
   success and fa...
SECTIONS IN USE-CASE [4]
 Special Requirements
   If a non-functional requirements relates
   specifically to a use-case t...
INCREASING LEVELS OF PRECISION
 Actor and Goals
   List of Actors and which of their goals the
   system would support.
 U...
AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Goals & Scope of Use-Case
4 Steps to Use-Cases
...
CHALLENGES IN USE-CASE DISCOVERY
 Tasks can be grouped at many levels of
 granularity from one or a few small steps to
 en...
EBP GUIDELINE
 For requirements analysis focus on use-cases at
 the level of a Elementary Business Process (EBP)
 Caveat
 ...
INVESTIGATING USER GOALS VS. INVESTIGATING
USE-CASES
                                                         Goal Hierarc...
DESIGN SCOPE VS. GOAL LEVEL
(SCOPE VS. LEVEL)
 Scope
      Which system boundary do we mean?
              “Spatial extent...
SCOPE

                  Dept. 1                             Dept. 3
                                 Sys. 1


           ...
LEVEL
                                           project goal

 Strategic Goals
                                          ...
AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Design Scope & Goal Level of Use-Case
4 Steps t...
STEP I – CHOOSING SYSTEM BOUNDARY
                                              1
               Choosing the System Bound...
STEP 2 & 3 – FINDING PRIMARY
ACTORS & GOALS
                                                  1
                   Choosin...
ACTOR- GOAL LIST




    Courtesy: Applying UML & Patterns, Craig Larman



     9/22/2008           Object Oriented Analy...
STEP 4 – DEFINE USE-CASES
                                                 1
                  Choosing the System Boundar...
AGENDA
Requirements Engineering
What is a Use-Case?
Sections in a Use-Case
Goals & Scope of Use-Case
4 Steps to Use-Cases
...
SUPPLEMENTARY SPECIFICATIONS
 Apart from use-cases, there are other kind of
 requirements
      Documentation
      Packag...
REFERENCES
 Applying UML & Patterns, Craig Larman
   Text: Part II - Inception 6,7,8, 25

 Writing Effective Use-cases, Al...
Upcoming SlideShare
Loading in...5
×

Writing Effective Use Cases

10,020

Published on

Use-Case Writing

Published in: Technology
1 Comment
16 Likes
Statistics
Notes
No Downloads
Views
Total Views
10,020
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
776
Comments
1
Likes
16
Embeds 0
No embeds

No notes for slide

Transcript of " Writing Effective Use Cases"

  1. 1. Harsh Jegadeesan’s CLASSROOM EFFECTIVE USE-CASE WRITING BITS Pilani Off-Campus Work-Integrated Learning Programmes
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. THE RE ACTIVITY CYCLE 8 Courtesy: The Integrated Requirements Engineering: A Tutorial 9/22/2008 Object Oriented Analysis & Design
  9. 9. 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
  10. 10. 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
  11. 11. THE RE ACTIVITY CYCLE Courtesy: The Integrated Requirements Engineering: A Tutorial 11 9/22/2008 Object Oriented Analysis & Design
  12. 12. 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
  13. 13. 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
  14. 14. THE RE ACTIVITY CYCLE Courtesy: The Integrated Requirements Engineering: A Tutorial 14 9/22/2008 Object Oriented Analysis & Design
  15. 15. 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
  16. 16. THE RE ACTIVITY CYCLE Courtesy: The Integrated Requirements Engineering: A Tutorial 16 9/22/2008 Object Oriented Analysis & Design
  17. 17. 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 stake- holders’ end. 17 9/22/2008 Object Oriented Analysis & Design
  18. 18. THE RE ACTIVITY CYCLE Courtesy: The Integrated Requirements Engineering: A Tutorial 18 9/22/2008 Object Oriented Analysis & Design
  19. 19. 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
  20. 20. 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
  21. 21. 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 21 9/22/2008 Object Oriented Analysis & Design
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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 28 9/22/2008 Object Oriented Analysis & Design
  29. 29. ALISTAIR COCKBURN’S TEMPLATE Run through of Alistair Cockburn’s Template 29 9/22/2008 Object Oriented Analysis & Design
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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 35 9/22/2008 Object Oriented Analysis & Design
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. ACTOR- GOAL LIST Courtesy: Applying UML & Patterns, Craig Larman 9/22/2008 Object Oriented Analysis & Design 45
  46. 46. 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
  47. 47. 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 47 9/22/2008 Object Oriented Analysis & Design
  48. 48. 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
  49. 49. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×