Modelling Requirements

Object-Oriented Development

      Object-oriented analysis:

Finding and describing objects or concepts in the problem domain

      Object-oriented design:

Defining software objects and their attributes

Defining relationships between objects

Defining collaborations of objects

Assigning responsibilities to objects

UML Unified Modelling Language

      The Unified Modelling Language is a visual language for specifying, constructing and documenting the artefacts of systems (OMG)

      Release UML 2.0

      Three ways to apply UML

As sketch: Informal diagrams

As blueprint: Detailed design diagrams for forward engineering and reverse engineering

As programming language: Complete executable specification of a software system

UML Unified Modelling Language

      Abstract

Good for presenting important ideas, without so many details

   Like natural language

   Unlike programming language

      Precise

Helps explore gaps and inconsistencies

   Like programming language

   Unlike natural language

      Pictorial

Easy to see the main objects and relationships

      Standard notation for Analysis & Design

Three Perspectives to Apply UML

      Conceptual perspective: Describing things in the domain of interest

      Specification perspective: Describing software abstractions, but no commitment to a particular implementation

      Implementation perspective: Describing implementations in a particular technology

Development Process

      Requirements (analysis)

Description of domain related processes

May be written as Use Cases + Use Case Diagrams

      Analysis

Description of the domain from the perspective of classification of objects

Identification of concepts, attributes, and associations that are considered noteworthy

Domain / Conceptual Model (Class Diagrams)

      Design

Defining software objects and their collaborations

Dynamic View

   Flow of messages and invocation of methods.

   Interaction Diagrams

Static View

   Class definitions with relationships

   Design Class Diagrams

Use Cases

      Narrative description of something in the problem domain

      Describes

A sequence of events

of an actor using a system

to complete a process

      Are requirements, primarily functional or behavioural requirements

At least they illustrate and imply requirements in the stories told by use cases

Use Cases (Cont.)

How can using the system provide observable value to the development process?

      The use cases emphasize the user goals and perspective

      We ask questions like

Who is using the system?

What are their typical scenarios of use?

What are their goals?

more user-centric approach compared to asking for a list of system features

Use Cases (Cont.)

      Actors

Something with a behaviour

Person (role), computer system, organisation

      Scenario ( / use case instance)

Specific sequence of actions and interactions between actors and the system

A sequence of actions a system performs that yields an observable result of value to a particular actor [RUP]

      Use Case

A collection of success and failure scenarios that describe an actor using a system to support a goal

A set of scenarios [RUP]

Use Cases (Cont.)

Three kinds of actors:

      Primary actor

Has user goals fulfilled though using services of the system under discussion

Why Identify?

   To find user goals, which drive the use cases

      Supporting actor

Provides a service to the system under discussion

Why Identify?

   To clarify external interfaces

      Offstage actor

Has an interest in the behaviour of the use case, but is not primary or supporting

Why Identify?

   To ensure that all interests are identified

Use Cases (Cont.)

Use cases can be written in different formats:

      Brief High Level Format

Brief description of a process

To understand the degree of complexity and functionality of the system

Often the main scenario

When?

   Early requirements phase

      Causal

Cover various scenarios

When?

   Early requirements phase

      Fully dressed

More detailed descriptions of the scenarios

They dig deeper

Use Case Example

Use Case: Buy Items

Actors: Customer, Cashier

Description: A customer arrives at a checkout with items to purchase.
The cashier records the purchase items.
The system presents the running total and line-item details.
The cashier collects the money and enters the payment information.
The system updates inventory.
The customer receives the receipt and leaves with the items.

Guidelines Use Cases

     Keep the UI out and focus on actor intent

     Write terse

     Black-box use cases

Describe what the system must do

Do not describe how the system will do this

     Take an actor and actor-goal perspective

     How to find use cases

Choose the system boundary

Find primary actors

Identify their goals

Define use cases

     What tests can help find useful use cases?

The boss test

The EBP (Elementary Business Process) test

The size test

Expanded Use Case Format

Use Case Name of the use case

Primary Actor The principal actor calling upon system services to fulfil a goal

Stakeholders List of actors and their interests

Purpose Intention of the use case

Precondition Condition upon which the UC can start

Success guarantees Guaranteed results

or Postcondition

Overview High level use case or other summary

Basic Flow Main success scenario

Alternative Flows Other scenarios

Special Requirements For example usability

Technology Early design decisions

Open issues

Expanded Use Case Format (Cont.)

      Precondition

States what must be true before beginning the scenario in the use case

Not tested

   rather assumed to be true

      Success guarantee / Postcondition

States what must be true on successful completion of the use case

      Alternative flow

A branch of a main success scenario

Both success or failure

Are noted with respect to the main success scenario

Use Case Example

Use Case Buy Items with Cash

Primary Actor Cashier

Stakeholders Customer, Company, Government, Tax agency

Purpose Capture a sale and its cash payment

Overview A customer arrives at a checkout with items to purchase.
The cashier records the purchase items and collects payment.
On completion, the customer leaves with the items.

Precondition Cashier is identified

Postcondition Sale is safe.

Receipt is generated.

Payment is recorded.

Use Case Example (Cont.)

Special Requirements Touch Screen UI

Language Internationalisation

Technology Item identifier entered by bar code laser scanner

Open Issues Can the customer pay by card?

Use Case Diagrams

     Use case diagrams are used in UML to illustrate the names of use cases and actors and the relationships between them

     Use case diagrams and use case relationships are secondary

     Use cases are text documents

Use Case Diagrams (Cont.)

     Use case diagrams give a picture of the system boundary

     It may serve as a communication tool summarizing the behaviour of the system and its actors

Ranking of Use Cases

      Rule: Implement first use cases that significantly influence the core system architecture

      Rank of a use case is increased if:

It has direct impact on architectural design

   Example: Adds classes to domain layer, require persistent services

Includes risky, time-critical, complex functions

Involves new research or technology

Represents primary business processes

Directly supports revenue or decreased costs

...

      Rank types

Scored: Numerical weights

Fuzzy: Low, medium, high

Sample Process for Creating Use Cases

Identify Actors and Use Cases

Draw a Use Case Diagram

Write Use Cases in the High Level Format

Write some Extended Use Cases

Rank Use Cases

Allocate Use Cases to Development Cycles