Gerhard Dueck -- CS3013 Capturing Requirements as Use Cases 1

Capturing the Requirements as use Cases

Requirements Description

We need to describe – The artifacts created in the requirements

workflow – The workers participating in the

requirements workflow – The requirements capture workflow

activities.

Fig 7.1 p. 133

Gerhard Dueck -- CS3013 Capturing Requirements as Use Cases 2

Artifact: Use-Case Model

The system's functional requirements The conditions or capabilities to which

the system must conform Agreement between the customer and

the developer Essential input for analysis, design,

and testing

May be broken up into packages

Gerhard Dueck -- CS3013 Capturing Requirements as Use Cases 3

Artifact: Actor

Actors represents parties outside the system that collaborate with the system

Actors correspond to workers and/or business actors in a business

An actor plays one role for each use case which it collaborates

An instance of an actor is a specific user interacting with the system

Gerhard Dueck -- CS3013 Capturing Requirements as Use Cases 4

Artifact: Use Case

A use case represents one way in which the actors use the system

A use case is a chunk of functionality that the system offers to add a result of value to its actors.

A use case specifies a sequence of actions, including alternatives of the sequence, that the system can perform, interacting with actors of the system.

Use-case instance – A use case specifies the behavior of dynamic

use-case instances or a scenario of use of the system

– A use-case instance is the performance or execution of a use case

– A use-case instance interacts with an actor instance

– A use-case instance does not interact with another use-case instances

Gerhard Dueck -- CS3013 Capturing Requirements as Use Cases 5

Artifact: Architecture Description

An architectural view of the use-case model.

It depicts the architecturally significant use cases.

An architecturally significant use case has some important and critical functionality, or involves some important requirement that must be developed early in the software's life cycle.

The architectural view is used as input when use cases are prioritized to be developed within an iteration.

Gerhard Dueck -- CS3013 Capturing Requirements as Use Cases 6

Artifact: Glossary

To define important and common terms used by analysts to describe the system

Useful in reaching a consensus among developers – Regarding the definitions of various

concepts and notions, and – Reducing the risk of misunderstandings

It can be derived from a business or domain model

It is more focused on the system to be built instead of the system's context.

Gerhard Dueck -- CS3013 Capturing Requirements as Use Cases 7

Artifact: User-Interface Prototype

Help understand and specify the interactions between human actors and the system.

One user-interface prototype for each use case.

Gerhard Dueck -- CS3013 Capturing Requirements as Use Cases 8

Workers

A worker is a position in the unified development process to which a real person can be assigned.

With each worker there is a description of the responsibilities and the expected behavior of that worker.

Gerhard Dueck -- CS3013 Capturing Requirements as Use Cases 9

Worker: System Analyst

Responsible for– The whole set of requirements that are

modeled as use cases – Delimiting the system – Finding the actors and use cases – Ensuring that the use-case model is

consistent and complete– The modeling leader and coordinator

Not responsible for– Individual use cases

Gerhard Dueck -- CS3013 Capturing Requirements as Use Cases 10

Worker: Use-Case Specifier– Responsible for the detailed description of

one or more of the use cases. – Work closely with the real users of the use

case that s/he is responsible.

Worker: User-Interface Designer– Responsible for

» visually shaping the user interface developing, for each actor, a user-interface prototype for some use cases

Worker: Architect– Responsible for describing the architectural

view of the use-case model.