COMMONWEALTH OF AUSTRALIA

FIT2005 Software Analysis, Design and Architecture

Copyright Regulations 1969 WARNING

Module 2: Requirements and Use Case Modelling

www.monash.edu.au

This material has been reproduced and communicated to you by or on behalf of Monash University pursuant to Part VB of the Copyright Act 1968 (the Act). The material in this communication may be subject to copyright under the Act. Any further reproduction or communication of this material by you may be the subject of copyright protection under the Act. Do not remove this notice.
2

Module 2 Objectives
On completion of this session you should have a basic conceptual understanding of: actors, use cases, and the system boundary; the difference between functional and non-functional requirements the purpose and activities of the requirements workflow of the UP; the process by which a detailed use case description is developed

Module 2 Objectives (continued)

On completion of this module you should be able to: identify requirements for a proposed system; classify a requirement as being functional or non-functional; identify actors that participate in use cases and describe their personality; identify use cases that are required to be supported by the system; interpret a use case diagram to reason about a system; produce use case diagrams to summarise a system; develop detailed use case descriptions; interpret use case descriptions; utilise advanced constructs in specifying use case descriptions, including use of alternative flows, selective flows, repeated flows, inclusion and extension of other use cases
3 4

Software Requirements Specification

A set of documents which specifies what the system is required to do/be Requirements do not state how the system will do things. Functional Requirements what behavior the system should offer Non-Functional Requirements specific properties or constraints on the system or its behaviour
E.g. usability, reliability, performance, security and supportability

Software Requirements Specification (2)

Requirements can be expressed as a list of imperative statements, e.g.:
The <system> shall <function> The Library Borrowing System shall allow a patron to borrow up to 10 items concurrently (functional) The Library Borrowing System shall allow 400 concurrent users of the catalogue searching function at all times (non-functional)

Uniquely number each requirement (for referencing) Use Cases should also be used to describe sequences of actions typically intended to support business processes
Use Cases complement the imperative statements
5 6

The Requirements Workflow

Purpose/Goals [Kruchten, ch 9]: To discover and reach agreement with customers and other stakeholders on what the system should do
Eliciting and prioritizing requirements from stakeholders Process of negotiation: balancing conflicting interests/desires

Activities of the Requirements Workflow (1)

To provide system developers with better understanding of the system requirements To define the boundaries of the system To provide a basis for planning the technical content of iterations To provide a basis for estimating cost/time to develop
7 8

Source: Arlow

Activities of the Requirements Workflow (2)

The Requirements Workflow Use Case Modeling

Use Case Modeling is a form of requirements engineering Focused on finding Actors and Use Cases Complements the list of functional and non-functional requirements
Focus is on interactions between the actors and the system

Use cases will form the base (reference) for later modeling tasks

10

Finding Requirements
Interviews Questionnaires Workshop/Brainstorm session

Prioritizing Requirements - MoSCoW

Must have - Mandatory Should have important but not mandatory (could omit) Could have truly optional (include if time permits) Want to have can wait for future software versions

The study guide lists a range of questions to guide the process of thinking about issues when determining requirements. (pp. 26 29 )

11

12

The Subject
Also called System Boundary
FIT2005 Software Analysis, Design and Architecture

Defines what is part of the system (inside) and what is external to the system (outside the boundary) Defined by who or what uses the system
Called Actors

and the benefits the system offers to the actors

Called Use Cases

Use Case Concepts

www.monash.edu.au
14

Actors
An abstraction of a role that some external entity adopts when interacting with the system In the real world, one person may fulfill multiple roles at different times, and one role may be fulfilled by different people Actors need a name which clearly describes the role
Example roles: Customer, OrderClerk, Administrator,

Actor vs Internal representation

Often there is data about particular actors kept in the system. The Actor in use case modelling is always external to system: an actual person, or actual other system
Actors interact directly with the system

Particular actors may be represented by some data object inside the system
e.g. a Customer object which is a representation of information about a particular Customer actor

Actors are always external to the system

Other systems can be Actors for the current system (e.g. Credit Card Agency System can be an Actor of our system)

15

16

Finding Actors
To find actors: Who or what uses the system?
Installs, starts and shuts down, maintains, enters data, produces reports

Actor Personalities
Initiator responsible for starting one or more use cases External server provides information or performs a service required by the system Receiver receives information from the system Facilitator/Proxy an actor who directly interacts with the system on behalf of some other actor

Does anything happen at fixed times or intervals? Who or what uses the outputs of the system? Who or what provides the inputs for the system? What other systems interact with the system?

Time can also be an actor.

Actors are named using a noun

17 18

Use Cases
Something which an actor wants the system to do/allow A specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem or class can perform by interacting with outside actors (Booch) Always started by an actor Written from the Actors point of view
How the actor perceives the systems behavior.

Orientation of Use Cases

Input-oriented use case one which is predominantly for obtaining information from an actor for storing in the system.
For example, entering the customers details into the system.

Output-oriented use case one which is predominantly for producing a report, or giving information to an actor.
Example: printing an invoice

Each use case needs a name

Use a verb-phrase, e.g. Create New Order, Display Exam Results
19

Processing-oriented use case one which is predominantly for manipulating data that is already in the system, usually in response to additional information being received or the passage of time
Example: determine which products are low in stock
20

Identifying Candidate Use Cases

Think about how each actor will use the system
What functions do they want/expect? What information do they want to store and retrieve?

Use Case Specification

Once a use case is identified, need to specify its detail: Name, and maybe a numeric ID for reference Brief description explain purpose/goal of use case Name the actors involved List any preconditions situation required to enable the use case to execute Describe the main flow (next slide) List any postconditions situation which will be true after use case has executed. List possible alternative flows
21 22

What happens when the system changes state

Does an actor need to be notified?

Do external events affect this system?

What notifies this system?

Does this system interact with other systems?

Why, When?

Does the system generate any reports?

What reports? Who for? When/How?

Main Flow of Use Case

Describes the sequence of events to accomplish the goal of the use case Consists of short/atomic steps that are time-ordered Each step is numbered Each step says what is done, and by what (either the Actor, or the System)
<number> The <something> <some action>

Example Use Case

Use Case: Check Unit Results Brief Description: The student checks to see the results for previous semesters Primary Actors: Student Secondary Actors: None Pre-condition: The student has logged in Main Flow: 1. The use case starts when the Student selects to view their past results 2. A list of units which were studied by the student is presented 3. If the Student selects a unit which they have completed
3.1 The system displays the results for that unit

Always begin with the primary actor doing something to trigger the use case

Post condition: None

23 24

Dont be vague
Problems can arise if too imprecise Example: Customer details are entered
Who enters the details? Entered where/ into what? What actually are details?

Branching and Repetition in Use Cases

The IF keyword can be used to indicate a branch (selection) in a flow The things to be done are indented, and given new numbering prefixed by the main-step number Example:
Keyword to indicate selection

Ask the following:

Who specifically ? What specifically ? When ? Where ?

3. If the Student selects a unit which they have completed

3.1 The system displays the results for that unit
Number re-starts at 1, prefixed by parent number and dot.

4. Else

The keyword Else by itself can be used for the alternative situation

4.1 The system display a message stating no result is available

25 26

Branching and Repetition in Use Cases

Repetition sometimes needed when dealing with reporting Can use For, While Body is indented and steps numbered as for the IF Example (Arlow Fig 4.10):
4. The system searches for products which match the customers criteria 5. If the system finds some matching products then 5.1 For each product found 5.1.1 The system displays a thumbnail sketch of the product 5.1.2 The system displays a summary of the product details 5.1.3 The system displays the product price 6. Else 6.1 The system tells the Customer that no matching products could be found
27

Alternative Flows
An Alternative Flow is a deviation from the normal flow of a use case
Error situations Long branches which do not easily fit within the normal flow Interruptions of the main flow

Might return to continue the main flow; might not Can be triggered in one of 3 ways:
Instead of the main flow After a particular step in the main flow At any time during the main flow

First step of alternative flow should say when flow is triggered to commence.
28

Example Alternative Flow [Arlow Fig 4.14]

Alternative Flow: CreateNewAccount:InvalidEmailAddress Brief Description: The system informs the customer that he or she has entered an invalid e-mail address Primary Actors: Customer Secondary Actors: None Pre-conditions: 1. The Customer has entered an invalid e-mail address Alternative Flow: 1. The alternative flow begins after step 2.2 of the main flow 2. The system informs the Customer that he or she entered an invalid e-mail address Post conditions: None
29

Example Alternative Flow [Arlow Fig 4.15]

Alternative Flow: CreateNewAccount:Cancel Brief Description: The customer cancels the account creation process. Primary Actors: Customer Secondary Actors: None Pre-conditions: None Alternative Flow: 1. The alternative flow begins at any time. 2. The Customer cancels account creation. Post conditions: 1. A new account has not been created for the Customer.

30

Use Case Diagram

One of the diagrams in UML Graphically presents a summary of the subject, the actors and the use cases of a system
FIT2005 Software Analysis, Design and Architecture

Advanced Concepts in Use Case Development

[Source: Arlow]
31

www.monash.edu.au

Actor Generalization
Some Actors may participate in common use cases Actor Generalization creation of a more abstract Actor that participates in use cases For example, with many of Monashs online systems (WES, AllocatePlus, etc.) some uses are available to both staff and students.
An actor named MonashPerson could be made, and be the Actor for these use cases Specialized actors can be made which inherit from MonashPerson all the relationships it has to use cases

Actor Generalization Example

Staff can:
Select unit View timetable Display class list

Student can:
Select unit View timetable Select class

33

34

include and inclusion use case fragments

When sequences are frequently needed by multiple use cases
Could be repetitive Factor the common part into its own use case

include Example

One use case (called the base use case) can include the behavior of another use case (the inclusion use case) through an include relationship Must explicitly state where in base that the inclusion is to occur, e.g.: . 3. include (SomeCase) 4. continuation of base use case
35 36

Example Use Case including another

Use Case: SelectClass Brief Description: The student selects a class time to attend for a particular unit Primary Actors: Student Secondary Actors: None Pre-condition: None Main Flow: 1. Include (SelectUnit) 2. The system displays the choices of class time for the selected unit 3. The Student selects one of the class times 4. The system records the students preference of class time Post condition: The students preferred class time has been noted in the system
37

Example Inclusion Use Case

Use Case: SelectUnit Brief Description: The user selects a particular unit Primary Actors: MonashPerson Secondary Actors: None Pre-condition: None Main Flow: 1. The system displays a set of units which are offering classes 2. The MonashPerson selects one of the units Post condition: A unit has been selected
38

Note the more general Actor

Extension Points
Extension Points are provisions in a use case for future or conditional insertion of additional behavior.
Contrasting to inclusion, which is mandatory inclusion.

Avoid Functional Decomposition

Common Error is to form high-level use cases and break these down into lower-level use cases
Bad because this leads to an artificial structuring; higher-level ones dont really do anything Does not match the object-oriented paradigm Hard for stakeholders to understand

A base use case can declare multiple extension points Some other use case (the extension use case) can define 1 or more behavior fragments to be inserted at a subset of the defined extension points. If more than one extension use case exists for a base use case, they might all be inserted when the base executes
Order in which the extension use cases are executed is not defined

Example Bad Design Arlow Fig 5.16

Examples: Arlow figures 5.11 and 5.13

39 40

Readings
Ensure that you have read the Study Guide module

Arlow: Chapters 3, 4 and 5 Armour: selected pages as scanned

Read through the case study to prepare for the upcoming tutorial

41