CS445 CS645 ECE451 Software Requirements Specification and Analysis

1
CS445 / CS645 / ECE451Software Requirements
Specification and Analysis

• Lecture 07
• The Unified Process and use cases

2
Readings

• Required
• Larman, 3rd ed., Ch. 1-6, 25, 30
• esp. Ch. 6
• Optional
• Fowler, UML Distilled, 3rd ed.
• Ch. 2, 9

3
Process models Quick review

• Waterfall
• Prototyping
• Staged delivery
• Iterative / evolutionary / agile

4
Hidden slide

• Waterfall
• Strict linear progression of stages
• Prototyping
• Iterate over the requirements until you get them
  right
• DISCARD the prototype (in theory -)
• Staged delivery
• Normal requirements gathering, but do development
  (and testing) mini-cycles
• Iterative / evolutionary / agile
• Multiple mini-cycles of the whole shebang more
  requirements done in earlier cycles, more coding
  and QA done in later cycles

5
Waterfall vs. iterative / agile

• The waterfall model does model the logical
  progression of the various development steps
  reasonably well
• It serves as a reference model for the different
  development activities, and what feeds into what
• The real difference is how you break up the
  project into chunks, and how you schedule them

6
Waterfall vs. iterative / agile

• e.g., a 12 months project
• Waterfall
• 2 months analysis, then
• 4 months design, then
• 3 months coding, then
• 3 months testing

7
Waterfall vs. iterative / agile

• e.g., a 12 months project
• Iterative 3 four-month mini-cycles
• Phase 1 build basic infrastructure
• analysis, design, coding, testing
• Phase 2 add the most important features as
  agreed upon by the client and developers
• analysis, design, coding, testing
• Phase 3 add the remaining features
• analysis, design, coding, testing

8
Waterfall vs. iterative / agile

• The reality about waterfall is
• There are always backflows, so even a
  waterfall-like process will have a non-strict
  linear progression and little mini-cycles
• Again, once the system has been released,
  mini-cycles are the norm, and you are doing
  iterative development, sort of ?
• The difference is that in true iterative
  development, you intentionally do smaller chunks
  of the whole system
• You (and the client) get a better feeling for
  what the system will eventually be like sooner
• Fewer surprises for everyone
• Helps to minimize risk all around
• Can re-assess project early, reprioritize
  requirements, renegotiate feature set / cost /
  schedule

9
Waterfall vs. iterative / agile

• Other advantages of iterative development
• You have to decide on a system software
  architecture (high level design) early on
• You get feedback on your architectural decisions
  and can revise requirements as you feel the
  feedback
• These are the design decisions that are most
  important to get right, and cost the most to fix
  later, and may mean the difference between
  project success and failure.
• Thus biggest design risks are faced early on, not
  after complete requirements effort

10
Waterfall vs. iterative / agile

• Other advantages of iterative development
• Process is fairly lightweight, and easy for new
  developers to learn with repetition of the
  mini-cycles
• Process is very human centric developers like
  this!
• Mini-cycles can be improved with experience
  (SPI)
• Easy to ship a scaled down system sooner, if
  thats what client decides later
• Managed complexity rather than big bang
  analysis, design etc
• The entire development team gets familiar with
  Platonic inner nature of the system as it grows
  organically.

11
Iterative development

• is not a wild west / hackfest model
• It is a disciplined development process it just
  allows for you to change your mind more easily.
• Your mini-cycles have firm goals, firm feature
  sets, firm mini-processes, firm schedules
• The output from each mini-cycle is
• a tested, executable, deployable partial system
• If you start to slip the schedule, you need to
• Drop reqs/features (for consideration in the next
  mini-iteration), or
• Explicitly reset the schedule.

12
Iterative development

• Testing and QA are a big part of it
• Regression testing, in particular, is key
• Incremental development requires incremental QA!
• You need to ensure that todays feature doesnt
  break yesterdays, since new features are
  continually being added
• Typically, the coders themselves write the test
  suites.
• Test suites are considered to be part of the
  system source code, and placed under version
  control!
• When you check in your new code, you check in
  your test suites for it too
• And before you check in, you run your new code
  against everyone elses test suites.

13
Iterative development and testing

• Test-driven development
• A new idea from the agile/XP community
• Write the test case first, then the code.
• Write the simplest code possible that will pass
  the test.
• Build one to throw away. Fred Brooks
• Open source JUnit test harness suite for Java
  code lots of followers, docs, etc.
• See http//www.junit.org

14
Waterfall vs. iterative / agile

• Waterfall-like approaches work reasonably well
  when you understand the domain well
• Little risk of doing the wrong thing at a macro
  level
• Easier to measure and manage (if thats what
  youre used to)
• Its often mandated for large projects when the
  customer wants good traceability, clear
  checkpoints, and expects few surprises

15
Waterfall vs. iterative / agile

• Iterative approaches work best when there is some
  novelty / risk
• You get early feedback from the Platonic system
  as it re-ifies into something concrete
• There is discipline but also flexibility
• You have several chances to examine requirements,
  change your mind about priorities, and you get a
  much better feeling for cost and chance of
  success earlier on.

16
UP vs. RUP

• The Unified Process is an OMG standard
• RUP is Rationals instantiation of it
• Rational is now owned by IBM
• Most of the hype and marketing and tools and
  books out there mention RUP
• There are lots of snake oil salesmen out there
  hawking RUP expertise and tools.
• For our purposes, we dont care about any
  differences between the two
• Larman uses UP in his book to be general

17
RUP

• Its an iterative process consisting of four
  major phases
• Inception Make an initial evaluation of the
  project. Is it work carrying on and committing
  funds to for the next phase?
• Elaboration Roughly, reqs analysis and
  high-level design.
• Shake out the architecture of the system
  Fowler
• Construction Roughly, detailed design / coding /
  QA. At this point, you know what youre doing,
  so you do it. Can be more predictive here in
  your expectations
• Transition Roughly, delivery and deployment.

18
RUP

• BUT
• Its NOT a waterfall-like model
• Typically, you do a little bit of everything in
  each mini-cycle, which consists of a well-defined
  set of activities with schedules
• Planning, requirements, design, implementation
  and testing
• The earlier mini-cycles are heavier on planning /
  analysis / requirements activities, and the later
  ones are heavier on coding / testing / deployment
  activities

19
Rational Unified Process
Lifted from the wikipedia.org page on RUP under
the GNU free doc. lic.
20
Evolutionary development example

• Before iteration 1, hold 2-day reqs workshop
• Invite both business and development people
• Day 1 morning
• HL reqs (names of system-level use cases and key
  NFRs)
• Chief architect and business people choose 10 of
  this UCs that are (a) architecturally
  significant, (b) have high business value, and
  (c) have high risk.
• e.g., suppose they pick UC2, UC11, UC14 of the 30
  UCs
• Day 1 afternoon and Day 2
• Do detailed reqs analysis of the FRs and NFRs
  that pertain to the selected UCs
• Larman section 2.4

21
Evolutionary development example

• Before iteration 1, hold an iteration planning
  meeting
• Decide on iteration length of, say, 4 weeks
• Choose a subset from the UCs for design / build /
  test during iter 1
• Break down goals into more detailed tasks
• Development team provides input into likely
  difficulty / schedule of tasks

22
Evolutionary development example

• Perform iteration 1 (over 4 weeks)
• First two days, developers and others do
  modelling and design in pairs at a whiteboard
• Work done in common war room, chief architect
  is coach
• Many informal diagrams used for communication
  (UML-ish)
• Models will be imprecise, vague, wrong
• Communication is what is important!
• Dont waste effort to keep informal docs/diagrams
  up-to-date if key people understand whats
  important/true
• Then development starts (change hats)
• Coding AND testing

23
Evolutionary development example

• Perform iteration 1 (over 4 weeks)
• One week before end of iteration, review if goals
  can be met
• If not, descope some reqs OR revamp schedule
• Tuesday Code freeze and creating of baseline
• Wednesday demo partial system to client /
  external stakeholders
• Ask for feedback

24
Evolutionary development example

• Last few days of iteration 1
• Do another reqs workshop on Wed / Thurs of last
  week
• Incorporate lessons learned from last iteration
  into original vision
• Decide on interesting UCs for iteration 2 and
  analyze them in detail
• Typically, can implement more requirements this
  time as we have learned a lot about the system
  from the first iteration.
• At this point, perhaps 25 of the use cases and
  NFRs will be elaborated in great detail
• Perform another iteration planning meeting on
  Friday.

25
Evolutionary development example

• Repeat steps 3-5
• With each workshop, we model more and more of the
  SUDs reqs, but each development cycle implements
  a small portion of the system
• Note that the reqs will evolve based on feedback
  from both the developers and the external
  stakeholders!
• Eventually, by the end of iteration 4 or 5,
  80-90 of the reqs have been sketched out in
  near-full detail, but only perhaps 10-20 of them
  have been implemented
• At this point, we have finished elaboration and
  have entered construction

26
Evolutionary development example

• (contd)
• At this point, requirement are mostly done but
  never frozen
• Probably dont need any more reqs workshops
• But DO still have iteration planning meetings
• Of the remaining reqs, which are the most
  interesting / valuable / risky?
• Continue with mini-cycles until done

27
Larman Fig. 2.4
28
The Agile Manifesto
We favour
29
Principles behind the Agile Manifesto

• We follow these principles
• Our highest priority is to satisfy the customer
  through early and continuous delivery of valuable
  software.
• Welcome changing requirements, even late in
  development. Agile processes harness change for
  the customer's competitive advantage.
• Deliver working software frequently, from a
  couple of weeks to a couple of months, with a
  preference to the shorter timescale.
• Business people and developers must work together
  daily throughout the project.

30
Principles behind the Agile Manifesto

• We follow these principles
• Build projects around motivated individuals. Give
  them the environment and support they need, and
  trust them to get the job done.
• The most efficient and effective method of
  conveying information to and within a development
  team is face-to-face conversation.
• Working software is the primary measure of
  progress.
• Agile processes promote sustainable development.
  The sponsors, developers, and users should be
  able to maintain a constant pace indefinitely.

31
Principles behind the Agile Manifesto

• We follow these principles
• Continuous attention to technical excellence and
  good design enhances agility.
• Simplicity the art of maximizing the amount of
  work not done is essential.
• The best architectures, requirements, and designs
  emerge from self-organizing teams.
• At regular intervals, the team reflects on how to
  become more effective, then tunes and adjusts its
  behaviour accordingly.

32
Use cases
33
Use cases and the course project

• We will discuss in lecture various approaches to
  doing Use Case modelling
• Different levels of detail, scenarios as numbered
  lists vs. paragraphs vs. multi-column format
• Low detail vs. lots of detail
• Use of includes and extends
• However, there is a specific format required for
  the project!
• Please talk to your TA and attend tutorials for
  details and discussions.
• There is also lots of info on the project web
  page.

34
Object-Oriented Analysis

• The key steps of OOA are
• Define the use cases (stories of use)
• Formatted text descriptions, maybe UML UC
  diagrams
• Define the domain model (find the objects,
  classes)
• UML class diagram
• Define the interactions between domain objects
  and SUD
• UML sequence / communication (aka collaboration)
  diagrams
• The next step define design class diagrams
  is part of OOD and thus not covered in this
  course.

35
Use cases

• Based on work of Ivar Jacobson
• One of the UML/Rational three amigos
• Based on experience at Ericsson building
  telephony systems
• His book is old and considered hard to read.
• Use cases arent inherently OO, but can be used
  in OOAD.
• Recommended refs
• Writing Effective Use Cases,
• by Alistair Cockburn, Addison-Wesley, 2001
• Cockburn is the current grand guru of UCs
• Larman uses his approach
• http//www.usecases.org

36
Use cases
Diagram generated by MagicDraw
A blood bank Client logs in. The Client
requests quantities of various types of
blood. The blood bank generates a notice to
Shipping and considers that the blood has been
removed from the system. An invoice for the order
is send to Billing.

• Basic idea
• Map out desired core system functionality at a
  coarsely-grained level consider variations.
  Explore. Discuss.

37
What are use cases

• Use cases (and scenarios) address the problem of
  
• How can I make functional requirements easier to
  elicit/read/review?
• Other descriptions
• They are stories of using a system. Larman
• Requirements in context. Larman/other
• High-level descriptions of the systems
  functionality and its environment
• Cases of use
• Describe how the system meets user goals
• User stories XP
• A way of doing user-centered analysis
• A first cut at the functionality of an
  application Rumbaugh

38
Use cases Overview

• Uses cases are a simple, powerful technique that
  help you identify and clarify
• Identify the tasks to be performed
• at both macro micro level
• Identify the major actors how they interact
  with system
• Clarify who is responsible for what, hidden
  assumptions and ambiguities from clients.
• Clarify what-ifs, and ensure all possible bases
  are covered.
• Identify and clarify system-level test cases
• what the client is expecting, the real
  requirements

39
Use cases Some definitions

• A use case is a story of using the system to
  fulfill a goal.
• It models an abstract task (with steps) performed
  by a user of the SUD
• Rent videos, Order blood
• An actor is someone/thing external to the SUD
  that interacts with it.
• An actor is an environmental entity that
  initiates
• or is otherwise involved with the system.
• i.e., not a sub-part of the SUD
• May be a human (Client) or not (CreditAuthorizatio
  nSystem, BillingSystem)
• A better term for this idea is role, but

40
Actors

• A primary actor is one that initiates a use case
• Uses cases are (usually) initiated by a primary
  actor
• (Exceptions are those that extend / include
  other UCs)
• A supporting actor may be invoked by the SUD
• Sometimes off-stage actor, who has an interest
  in the UC
• Often this concerns NFRs
• e.g., government regulatory agency
• Suggested notation
• Use a UML stickman to represent a human actor
• Use a non-stick figure diagram to represent a
  non-human actor
• e.g., a box with actor keyword

actor BillingSystem
41
Scenarios

• A scenario is one full execution path through a
  use case
• Typically, each step in a use case may have
  variations and error conditions.
• A scenario traces one path from start until
  ultimate success or failure.
• e.g., A customer tries to rent a video but has
  outstanding overdue fines, which he pays first
  and then completes the rental.
• A full use case comprises the set of all
  possible scenarios from start to finish.
• Can use textual lists, HTML forms, or UML
  diagrams to represent scenarios.

42
Uses cases and scenarios

• More formally
• A use case is a collection of success failure
  scenarios describing a primary actor using a
  system to support a particular goal.
• Cockburn says Think of like stripes down a
  trouser leg.

• UC7 Order Books
• Client requests book order
• Check book in catalog
• Check customer credit
• Check inventory
• Process payment
• Ship books.

SC1
SC5
SC4
SC6
SC3
SC2
S
S
S
S
F
S
S
F

F
S
F
S
S
S
S
S
S
Success leg
Failure leg
43
Not all failures are fatal

• Note that some failures are recoverable!
• This is a simple example where goals have obvious
  success or failure values.
• In more complicated situations, you may have
  multiple possible values, complicated if-stmts,
  and even loops.
• For these cases, textual lists and UML sequence
  diagrams may not be enough
• Could use UML activity diagrams (flow charts)
  to illustrate scenarios BUT remember that use
  cases are basically textual in their
  heart-of-hearts

44
Use cases and UML UC diagrams

• Fundamentally, use cases are text, not diagrams.
• Use case analysis is a writing effort, not
  drawing.
• But a short time drawing a UML use case diagram
  provides a context for
• identifying use cases by name
• creating a context diagram
• Larman slide

45
Showing context of UCs
Larman slide
Warning Dont spend much time on
diagramming. Use case work means to write text,
not draw diagrams
46
UML use case diagrams
Larman slide
system drawn as a box
47
Use case diagrams

• Describes the set of all use cases graphically
• Models the systems top-level functionality and
  environment
• Context diagram
• Use cases requirements in context Larman
• System drawn as a box
• Can collect related use cases into packages
  inside the box
• Shows which actors involved in which use cases
• Primary actors on left supporting actors on
  right
• Use a difference visual rep. for non-human actors
  (plus actor stereotype)
• Sometimes shows relationships between use cases
• includes and extends

48
includes and extends

• UC1 includes UC4
• includes is used for services common to
  several use cases, e.g., QueryBlood used by
  OrderBlood
• Its like a procedure call control returns to
  UC1 at the inclusion point after UC4 is
  executed
• UC7 extends UC5
• extends used for important variations
• At extension point in use case UC7, control is
  transferred to UC5 and does not return.
• Fowler and others recommend not using these UML
  features
• It encourages you to get too complicated too
  quickly
• Stick to simple textual descriptions instead.
  KISS.

49
Use Case Descriptions

• Use cases are fundamentally textual!
• There may be a predefined structure too
• Possible formats
• Brief
• Only contain main scenario
• Casual
• Paragraph format may cover multiple scenarios
• Fully Dressed
• Sequence of interactions written in column format
  with sections such as preconditions and
  cross-referencing
• You will get instructions from the TA on the
  format expected for the project

50
A brief format example Larman

• Rent Videos
• A Customer arrives with videos to rent. The Clerk
  enters their ID, and each video ID. The System
  outputs information on each. The Clerk requests
  the rental report. The System outputs it, which
  is given to the Customer with their videos

51
A fully dressed example

• Name Buy a book online
• Use Case Number UC32
• Authors John Doe
• Event Customer requests to buy one or more
  books. The choice of books is passed as the
  input.
• System Customer and Vendor computers with a Web
  application that implements online book selling
• Actors
• Customer (initiator)
• Credit-card authorisation service
• Bookseller
• Overview This use case captures the process of
  purchasing one or more books from an online book
  seller.
• References R23, R34, and R45.
• Related Use Cases UC11

52
Typical process description
53
Typical process description
54
Use case descriptions

• Use case number
• a unique number for referencing UC elsewhere in
  the specification
• use cases are numbered UC1, UC2, etc.
• Name
• indicating what is captured by UC
• A Names should start with a verb
• Authors
• the names of the people who discovered the use
  case

55
Use case descriptions

• Event/Pre-condition
• the description of the event that initiates UC
  indicate information that is passed as input with
  the event
• a use case should be triggered by a single event
• preconditions are noteworthy condition that are
  assumed to be true before beginning a scenario
  (not tested in the scenario)
• System
• a declaration of what you consider to be the
  system for UC
• business (interaction with business)
• system (interaction with software)
• Business use cases describe how the business as a
  whole deals with customers, etc.
• Suggest start with business use cases, and
  elaborate to get down to what is wanted in the
  software.

56
Use case descriptions

• Actors
• a list of the actors that participate in UC,
  giving UCs initiator as the first element of the
  list
• The Actors names should always be capitalized
  within the UC
• Overview/Post-conditions
• a brief 2-3 sentence description of UC this
  overview serves also as a high-level description
  of UC. Describe what should be true on successful
  completion of the use case.
• References
• a list of the numbers of all requirements
  captured by UC (This will make more sense later.)

57
Use case descriptions

• Related Use Cases
• a list of the numbers of all related use cases
  for each element of the list, describe the
  relationship of the identified use case to UC
• Typical Process Description
• in a multi- (or single) column format, a
  description of the most usual instance scenario
  of UC, the so-called normal interaction of actors
  and the system that leads to the successful
  outcome of the process that UC captures. This is
  also called the main scenario or basic flow.
• one column for each actor or process that is
  visible at the users level.
• sometimes, there will be only two columns, at
  least at the highest level view of the system,
  (1) the user or initiator of the system and (2)
  the system itself.

58
Use case descriptions

• Typical Process Description (contd)
• In the left-most column, first row, list the
  initiators actions.
• In each of the remaining rows, the reactions by
  one of the systems processes to the initiators
  or other actors actions are listed in the
  appropriate column.
• Typical actions
• interaction between actor and system
  (input/output)
• validation by system
• state change in the system
• e.g., record some information

59
Use case descriptions

• Typical Process Description (contd)
• Indicate branches on certain conditions (e.g.,
  see Section Credit Card Payment). Branch may
  refer to another use case described elsewhere or
  subsections of this use case.
• Branches must be based on conditions that the
  system or an actor can detect.
• Alternatively, use Larmans method where branches
  are not indicated in the main scenario, but later
  sections, show a branch of step 7 as 7a . . .
• Subsections describe actions on branches.
• Subsections are assumed to merge back with the
  main flow, unless they indicate otherwise.

60
Use case descriptions

• Alternative Flows
• subsections for different actions that an actor
  can take in the main scenario. Start the line
  numbers at the point where the alternative flow
  diverges from the main scenario.
• Exceptions/Extensions
• subsection for alternative behaviours of the
  system based on certain conditions.
• Be careful to make it clear which the scenario
  (main or subsection) to which alternative flows
  or exceptions belong.
• Almost every step can fail in some way.

61
Level of Description

• What level of description belongs in a use case?
• Larman/Cockburn recommend focusing at the level
  of elementary business processes (EBPs)
• A task performed by one person in one place at
  one time, in response to a business event, which
  adds measurable business value and leaves the
  data in a consistent state.
• An EBP should capture a users goal (intention)
• Usually consists of several steps, do-able in one
  session
• Has an obvious beginning and end

62
EBPs

• Which of these are EBPs?
• Negotiate a Supplier Contract
• Rent Videos
• Log In
• Start up System
• Print a Document
• Can model some non-EBPs in your use case
  collection, but focus should be on EBPs

63
Hidden slide

• Which of these are EBPs?
• Negotiate a Supplier Contract
• Not doable by a single person in a single session
• Rent Videos
• Yup
• Log In
• A system event, not a business event
• Not very interesting
• Start up System
• A system event, probably trivial
• Print a Document
• No business value

64
Common UCs

• Most systems have a Start Up, Shut Down, and
  Configure System use cases anyway
• Often trivial and low level, but sometimes,
  important.
• e.g., an avionics system
• Its also common to group CRUD operations into
  one use case
• e.g., Manage User Account UC combines create /
  read / update / delete user account operations
  into one UC

65
A simple use case process

• Decide on the system boundaries.
• Identify the primary and supporting actors
• i.e., the environmental entities (human, sw, hw)
  that will interact with the SUD.
• For each, identify the distinct roles each will
  play
• Each role (not each person/hw/sw) is an actor.
• e.g., Pat might be a sysadmin and a customer
  service rep.
• Optional
• Look for inheritance groupings among the actors
• e.g., PreferredCustomer is-a Customer

66
A simple use case process

• For each actor, determine the set of
  tasks/services (EBPs) each expects from the SUD.
• Many of EBPs will have multiple primary actors
• Spend time organizing and naming the UCs
• Ideally, youll have a few high level tasks and
  little detail
• These will be the main use cases of your system!
• Optional
• Identify common subparts (includes) and
  variations (extends)
• You can use UML packages to group similar /
  related UCs.

67
A simple use case process

• For each use case
• Choose a name that represents a goal to be
  achieved start with a verb.
• e.g., Withdraw cash, Reserve flight
• Identify actor(s) who initiate use case.
  Identify other actors who may be involved too.
• Describe any important pre-conditions that must
  be true and what will happen if not.
• Makes hidden assumptions visible
• Dont get bogged down in details
• Describe informally
• Termination criteria (how do you know when youre
  done)
• Post condition (how shared phenomena and SUD
  internal state will be changed by UC)

68
A simple use case process

• Describe the normal success scenario (i.e., no
  errors) of the use case as a sequence of steps.
• An example UC1 Withdraw cash
• User inserts ATM card
• User enters PIN
• User selects account
• User selects amount to withdraw
• System performs accounting
• System dispenses cash and receipt ejects card
• User takes cash, receipt, bank card.
• If there are several normal success scenarios,
  consider making all but one into extensions and
  specify them separately.

69
A simple use case process

• Now look at each step
• For each step, identify possible variations and
  error conditions. For example
• iA) User inserts ATM card incorrectly
• iB) User enters non-ATM card
• iiA) User enters invalid PIN
• Might want to elaborate a step into a
  sub-use-case (includes) if its complex.
• Use cases and scenarios nest recursively.
• Open problem How best to organize a collections
  of use-cases/scenarios.
• Packages/nesting/includes/extends/param/inheri
  tance can help somewhat, but becomes messy
  quickly.
• Naïve clients wont want to learn OO just for
  this.

70
A simple use case process

• Detailed version Elaborate possible scenarios
  running from trigger event until goal completion
  or non-recoverable failure.

• UC1 Scenarios
• SC1 All OK ? accept
• SC2 Book is out-of-print
• ? decline
• SC3 Credit bad, normal client ? decline
• SC4 Credit bad, preferred client ? accept
• SC5 inventory low, customer declines
• SC6 inventory low, customer reduces order ?
  accept

• UC1 Order textbooks
• Client requests book order
• Check book in catalog
• Check customer credit
• Check inventory
• Process payment
• Ship books.

71
A brief format example Larman

• Rent Videos
• A Customer arrives with videos to rent. The Clerk
  enters their ID, and each video ID. The System
  outputs information on each. The Clerk requests
  the rental report. The System outputs it, which
  is given to the Customer with their videos

72
Larman / Cockburn / Fowler say

• Keep the first pass simple and lightweight
• Dont get bogged down in details
• Dont bother with extends / includes much if
  at all
• Remember that use cases are fundamentally textual
  
• Stories of the system
• Larman / Cockburn say Keep the UI out
• e.g., Client identifies him/herself vs.
• Client provides identity card or phone number
  plus photo ID. Clerk swipes identify card if
  provided if swipe fails, ...
• You can add detail later on
• Larman distinguishes between Essential (first
  pass) and Concrete (detailed) UC models

73
Other common UC mistakes

• These are all bad things! List adapted from
  Iconix
• Write function requirements instead of usage
  scenario text
• Reqs state what the SUD shall do whereas
  scenarios describe actions that the user takes
  and expected responses of the SUD
• i.e., dont model the SUD per se, model the
  interactions instead.
• Describe attributes and methods rather than usage
• This is inappropriate attention to details
  youll get bogged down quickly.
• Concentrate on the basic tasks and the abstract
  details.

74
Other common UC mistakes

• Write from a non-users perspective or using
  passive voice
• Use cases are all about what users expect from
  the system these are the real requirements.
• Use of the passive is to be avoided ?
• Present tense active voice verb phrases are much
  more effective.
• Describe only user interactions ignore system
  responses.
• Need to detail what the system is doing
  (abstractly) under the hood. This is what you
  are trying to discover to be able to build the
  systems eventually,
• e.g., validate ID, prepare invoice, generate
  error message

75
Other common UC mistakes

• Omit text for alternative courses of actions.
• Dont punt on alternatives too long these
  details are just as important.
• Spend a month debating whether to use includes
  or extends
• Make a decision and live with it its good to
  review and rethink but dont fall victim to
  analysis paralysis.
• Focus on something other than whats inside a
  use case (e.g., what happens before or after)
• Effectively, they recommend not spending much
  time modelling pre or post-conditions.

76
CS445 / CS645 / ECE451Software Requirements
Specification and Analysis

• Lecture 07
• The Unified Process and use cases