Download - fit2005-lecture2-fullsize

7/31/2019 fit2005-lecture2-fullsize

1/41

www.monash.edu.au

FIT2005 Software Analysis, Design and Architecture

Module 2:

Requirements andUse Case Modelling


2/41

2

COMMONWEALTH OF AUSTRALIA

Copyright Regulations 1969

WARNING

This material has been reproduced and communicated to

you by or on behalf of Monash University pursuant to PartVB of the Copyright Act 1968(the Act).

The material in this communication may be subject to

copyright under the Act. Any further reproduction orcommunication of this material by you may be the subject ofcopyright protection under the Act.

Do not remove this notice.


3/41

3

Module 2 Objectives

On completion of this session you should have a basicconceptual understanding of:

actors, use cases, and the system boundary;

the difference between functional and non-functionalrequirements

the purpose and activities of the requirements workflow ofthe UP;

the process by which a detailed use case description isdeveloped


4/41

4

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 casedescriptions, including use of alternative flows, selective flows,repeated flows, inclusion and extension of other use cases


5/41

5

Software Requirements Specification

A set of documents which specifies what the system isrequired to do/be

Requirements do notstate howthe system will do things.

Functional Requirements what behavior the systemshould offer

Non-Functional Requirementsspecific properties orconstraints on the system or its behaviour

E.g. usability, reliability, performance, security and supportability


6/41

6

Software Requirements Specification (2)

Requirements can be expressed as a list of imperativestatements, e.g.:

The shall 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 businessprocesses

Use Cases complementthe imperative statements


7/41

7

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

To provide system developers with better understandingof the system requirements

To define the boundaries of the system

To provide a basis for planning the technical content ofiterations

To provide a basis for estimating cost/time to develop


8/41

8

Activities of the Requirements Workflow (1)

Source: Arlow


9/41

9

Activities of the Requirements Workflow (2)


10/41

10

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-functionalrequirements

Focus is on interactions between the actors and the system

Use cases will form the base (reference) for latermodeling tasks


11/41

11

Finding Requirements

Interviews

Questionnaires

Workshop/Brainstorm session

The study guide lists a range of questions to guide theprocess of thinking about issues when determiningrequirements. (pp. 26 29 )


12/41

12

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


13/41

www.monash.edu.au


Use Case Concepts


14/41

14

The Subject

Also called System Boundary

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


15/41

15

Actors

An abstraction of a role that some external entity adoptswhen interacting with the system

In the real world, one person may fulfill multiple roles atdifferent times, and one role may be fulfilled by differentpeople

Actors need a name which clearly describes the role Example roles: Customer, OrderClerk, Administrator,

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)


16/41

16

Actor vs Internal representation

Often there is data about particular actors kept in thesystem.

The Actor in use case modelling is always external tosystem: an actual person, or actual other system

Actors interactdirectly with the system

Particular actors may be represented bysome dataobject inside the system

e.g. a Customer object which is a representationof informationabout a particular Customer actor


17/41

17

Finding Actors

To find actors:

Who or what uses the system?

Installs, starts and shuts down, maintains, enters data, producesreports

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?

Actors are named using a noun


18/41

18

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 withthe system on behalf of some other actor

Time can also be an actor.


19/41

19

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 withoutside actors (Booch)

Always started by an actor

Written from the Actors point of view

How the actor perceives the systems behavior.

Each use case needs a name

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


20/41

20

Orientation of Use Cases

Input-oriented use case one which is predominantlyfor obtaining information from an actor for storing in the

system. For example, entering the customers details into the system.

Output-oriented use caseone which is predominantly

for producing a report, or giving information to an actor. Example: printing an invoice

Processing-oriented use caseone which ispredominantly for manipulating data that is already in thesystem, usually in response to additional informationbeing received or the passage of time

Example: determine which products are low in stock


21/41

21

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?

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?


22/41


23/41


24/41

24

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 pastresults

2. A list of units which were studied by the student is presented3. If the Student selects a unit which they have completed

3.1 The system displays the results for that unit

Post condition: None


25/41

25

Dont be vague

Problems can arise if too impreciseExample: Customer details are entered

Who enters the details? Entered where/ into what?

What actually are details?

Ask the following: Who specifically ?

What specifically ?

When ?

Where ?


26/41

26

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 newnumbering prefixed by the main-step number

Example:

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

3.1 The system displays the results for that unit

4. Else

4.1 The system display a message stating no result is available

Keyword to indicate selection

Number re-starts at 1, prefixed by parent number and dot.

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


27/41

27

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 product5.1.2 The system displays a summary of the product details5.1.3 The system displays the product price

6. Else

6.1 The system tells the Customer that no matching products could be found


28/41

28

Alternative Flows

An Alternative Flow is a deviation from the normal flowof 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.


29/41

29

Example Alternative Flow [Arlow Fig 4.14]

Alternative Flow: CreateNewAccount:InvalidEmailAddress

Brief Description:The system informs the customer that he or she has entered aninvalid e-mail address

Primary Actors: Customer


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 flow2. The system informs the Customer that he or she entered an invalid

e-mail address

Post conditions: None


30/41

30

Example Alternative Flow [Arlow Fig 4.15]

Alternative Flow: CreateNewAccount:Cancel

Brief Description: The customer cancels the account creation process.

Primary Actors: Customer


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 notbeen created for the Customer.


31/41

31

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

[Source: Arlow]


32/41

www.monash.edu.au


Advanced Concepts

in Use Case Development


33/41

33

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


34/41

34

Actor Generalization Example

Staff can:

Select unit

View timetable Display class list

Student can:

Select unit View timetable

Select class


35/41

35

include and inclusion use case fragments

When sequences are frequently needed by multiple usecases Could be repetitive

Factor the common part into its own use case

One use case (called the base use case) can include thebehavior 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


36/41


37/41

37

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


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


38/41

38

Example Inclusion Use Case

Use Case: SelectUnit

Brief Description:

The user selects a particular unitPrimary Actors: MonashPerson Note the more general Actor


Pre-condition: NoneMain Flow:

1. The system displays a set of units which are offering classes

2. The MonashPerson selects one of the unitsPost condition:

A unit has been selected


39/41


40/41

40

Avoid Functional Decomposition

Common Error is to form high-level use cases and breakthese down into lower-level use cases

Bad because this leads to an artificial structuring; higher-levelones dont really do anything

Does not match the object-oriented paradigm

Hard for stakeholders to understand

Example Bad Design Arlow Fig 5.16

R di


41/41

41

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

Download - fit2005-lecture2-fullsize

Top Related