CBD Requirements Workflow

1
CBD - Requirements Workflow

• CSCI3007 Component Based Development
• downloadable .pdf file

2
The CBD Development Process
Use case models
Business Requirements
Requirements
Existing assets
Technical constraints
Components
Business Concept Models
Specification
Provisioning
Assembly
Applications
Component specifications and architectures
Test
Use case models
Tested Applications
Deployment
3
Workflow Artifacts
Requirements
4
The Requirements Definition Workflow

• The Requirements Definition workflow must deliver
  the following to the Specification Workflow
• A business concept model
• Lists the important concepts in the business
  domain
• Shows the relationships between them
• A set of use cases
• Clarifies the system boundary
• Identifies actors who interact with the system
• Describes the interactions betweens the actors
  and the system

5
Modelling Business Processes

• Business processes can be modelled with Activity
  Diagrams in UML

customer arrives/
Take up reservation
Wait for an event
enquiry/
else
Check availability
cancel request/
amendment request/
suitable room
Cancel reservation
Amend reservation
Make reservation
no-show/
Confirm Reservation
Notify billing system
Process no-show
6
Business Concept Model
7
Use Cases in CBD

• Use cases are UMLs formalism for modelling
  user-system interaction
• UML does not specify the content of these
  descriptions
• Only the diagrams are specified
• (We will use Cockburns templates)
• Size and scope are not specified
• We broadly define a use case to be the
  description of an interaction that follows from a
  single event

8
Use Cases and OO Models

• Most of the confusion stems from unclarity about
  which models are built with Use Cases
• waters muddied further by the Rational Unified
  Process which builds a distinct Use Case Model
• Are they system-level descriptions of
  interactions between Actors and systems (or
  subsystems)?
• as in original definition
• Or can they describe business processes that
  the system serves?
• As Jacobson suggests in The Object Advantage?

9
Class Discussion Use Cases
MakesSaleOf_StockItem
Customer
CheckOutOperator
Which is right and why?
MakesSaleOf_StockItem
CheckOutOperator
10
Approaches to the Scoping of Use Cases (1)

• Rational Unified Process
• distinguishes between abstract Use Cases and
  concrete Use Cases and uses generalisation,
  ltltextendsgtgt and ltltincludegtgt relationships between
  use cases
• Larry Constantine
• distinguishes between essential (business) Use
  Cases and conventional or concrete Use Cases
• Alistair Cockburn
• builds (business) goal-driven Use Cases

11
Approaches to the Scoping of Use Cases (2)

• The RSI approach of the Ratio Group
• builds ltltRequirementsgtgt Use Cases for business
  models and separate ltltServicegtgt and ltltInterfacegtgt
  for component-based Management Information
  Systems
• Craig Larman
• influenced by Constantine distinguishes between
  High-Level Use Cases and Real Use Cases, and also
  between Initiating Actors and Participating Actors

12
Usage-Centred Design

• Constantine considers that typical use case
  documentation is tied to specific interfaces
• E.g., A use case Customer_MakesWithdrawalFromATM
  will typically discuss bank cards, pin numbers
  etc.,
• Usage-centred design focuses on abstract business
  requirement in an essential use case
• Relegates interface-specific details to a
  concrete or conventional use case
• Different interfaces can be referred to by
  different concrete use cases
• E.g.,A retina scan can replace PIN-number-based
  identification
• The essential use case concentrates on the users
  goal
• To access their account on a 24x7 basis to make
  withdrawals

13
RSI

• The RSI approach of the Ratio group in London
  builds three separate stereotyped use cases for
  each conventional use case
• ltltrequirementgtgt use case is similar to
  Constantines essential use case
• Specifies the abstract user requirement
• This is realized by a ltltservicegtgt use case
• A system-level use case at the granularity of a
  business function
• Each ltltservicegtgt use case may have its interface
  specified separately in an ltltinterfacegtgt use case
• E.g., screen sketch for GUI, protocols for
  system-system interaction
• The approach is optimized for service-based CBD
• Uses Cockburn templates (below) for documentation

14
Use Case Descriptions in CBD

• CBD broadly follows Cockburns approach
• Use Case description contains (at least)
• An identifying name/number
• The name of the initiating actor
• A short description of the the goal of the use
  case
• A single numbered sequence of steps that define
  the happy case (main sequence)
• Each step (excepting inclusion steps) takes the
  form A (actor) does X. The first step indicates
  the stimulus to the system.
• The combination of actor and stimulus must be
  unique across all use cases.

15
Cockburns Use Case Writing Process (1)

• Name the system scope and boundaries
• Brainstorm and list the actors
• Brainstorm and exhaustively list user goals for
  the system
• Capture the outmost summary use cases to see who
  really cares
• Check for an outmost use case for each primary
  actor
• Reconsider and revise summary use cases. Add,
  subtract or merge goals
• Select one use case to expand

16
Cockburns Use Case Writing Process (2)

• Capture stakeholder interests and interests,
  preconditions and guarantees
• Write the main success scenario (happy case)
• Brainstorm and exhaustively list the extension
  conditions
• Write the extension-handling steps
• Extract complex flows to sub use cases merge
  trivial sub use cases
• Iterate and adjust

17
Simple Use Case (1)
18
Simple Use Case (2)

• Main Success Scenario
• 1. ReservationMaker requests to make a
  reservation
• 2. ReservationMaker selects hotel, dates and room
  type
• 3. System provides availability and price
• 4. ReservationMaker agrees to proceed
• 5. ReservationMaker provides identification and
  contact details
• 6. ReservationMaker provides payment details
• 7. System makes reservation and gives it a tag
  (unique ID)
• 8. System reveals tag to ReservationMaker
• Extensions
• 3. Room Not Available
• a) System offers alternative dates and room
  types
• b) ReservationMaker selects from alternatives
• 3b. ReservationMaker rejects alternatives
• a) Fail
• 4. ReservationMaker declines offer
• a) Fail
• 6. Customer already on file

19
Use Case Model
20
Iterating over Workproducts

• The Business Concept model is revisited in the
  light of the processes
• These questions are asked and answered
• Do the abstractions in the boxes (Object Types)
  get created and destroyed?
• Does the software need to know about this?
• If so, how does it find out?
• Does this abstractions attributes change?
• Do the associations change over time?
• Does the software need to know about this?
• If so, how does it find out?

21
Summary

• The CBD development includes the following
  workflows
• Requirements Definition
• Specification
• Provisioning
• Assembly
• Test
• The Requirements Definition workflow delivers
• A Business Concept Model
• A Use Case Model