CBD Requirements Workflow - PowerPoint PPT Presentation

1 / 21
About This Presentation
Title:

CBD Requirements Workflow

Description:

The Requirements Definition workflow must deliver the following to the ... Identifies actors who interact ... Alistair Cockburn. builds '(business) goal ... – PowerPoint PPT presentation

Number of Views:74
Avg rating:3.0/5.0
Slides: 22
Provided by: alanoca
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com