Module Info

Tutorials start in week 3.

Assessment: 2 Courseworks 50% each.

Pre-recorded lectures available on QM+. Live lecture (repeat
of same material) also will be recorded

All info needed will be in lecture slides (available under

slides/documents tab in QM+)

Please post questions on module forum. Will not be able to

answer individual emails.
Specifying requirements: Modelling systems with UML diagrams

Lecturer: Anne Hsu

School of Electronic Engineering and Computer Science
 Building a House

Architect Pro Descriptions Dream

ble
ch ms Ideas House
an a n
ge
s d

House
Building
Plan to Plan
 Building a House
• Family
– describes what they want: requirements
• Architect
– prepares a plan
• Builder
– builds according to the plan
• The plan is critical
– family know what they will get
– builder knows what to build
 THE SAME IN COMPUTING, BUT ...

System Description
Analyst / Dream System
Designer Ideas Initial concept

What do these
look this?

Plan/Specification
Coder Actual
System
 Specifications
• Specifications describe exactly what a
system must accomplish
• A specification is often a plan or model
of the required system
 An Abstract View of a System
behaviour System input
Boundary

System

System output
Environment
purpose, or business goal
Key part of software engineering
is Information Systems Analysis
-Purpose
-Behaviour
-Code architecture
 What is involved in software
engineering?
Integrating Three Perspectives
• Users
• Business (owner/client/sponsor)
• Software Developers
Software requirements serve as a model
of the system

10
 What is a Model?
• Like a map, a model represents something
else
• A useful model has the right level of detail
and represents only what is important for
the task in hand

11
 What is a Diagram?
• Diagram is a visual representation of a part of a model
• Diagram to model is like paragraph to a story.
• Abstract shapes are used to represent things or actions
from the real world 40°
• Diagrams follow rules or standards
• The standards promote communication and make sure
that different people will interpret the diagram in the
same way
• Diagrams help information analysts to communicate
ideas and to understand structures and relationships in
the system

12
 Author Reviewer Typesetter Printer

An Example
of a Diagram Write Chapter

Review Chapter

• An activity Revise Chapter

diagram of the [book not

complete]

tasks involved [book complete]

in producing a
Typeset Book

book. Correct Proofs

Reset Book

Print Book

13
 Author Reviewer Typesetter Printer

Hiding Write Chapter

Plan Chapter

Detail Write Chapter

Produce
First Draft

Review Chapter

Revise Draft
Revise Chapter

[book
[not not
satisfied]
complete]
[satisfied]

[book complete]
Add Exercises
Typeset Book

Add References
to Bibliography
Correct Proofs

Reset Book

Print Book

14
 UML is a language for making
systems models using diagrams
An analogy
• To Write an Essay • To model a system
• Use English grammar to • Use UML to draw diagrams,
use cases, class diagrams,
write sentences collaboration diagrams etc.
• Sentences made up of • Diagrams made up of 2D
words, punctuation, phrases symbols, icons, arrows, paths
• Use Microsoft Word to form (lines)
sentences that are • Use Computer Aided Software
consistent with English Engineering (CASE) tools to
grammar draw diagrams that are
consistent with UML

16
 Diagrams in UML
• UML diagrams consist of:
• icons
Plan Chapter
• two-dimensional symbols
Produce
• paths First Draft

• Strings (text)
Revise Draft

[not satisfied]

• UML diagrams are defined in [satisfied]

Add Exercises

the UML specification.

Add References
to Bibliography

17
The different types of UML diagrams

18
 In this module we will cover:

Class and Use Case Diagrams are part of

Requirements Modelling
19
 What does systems analysis
documentation look like?

-Use Case Diagram

-Class Diagram
-Drawn using Unified
Modelling Language
(UML): A standardized
general-purpose modelling
language for creating visual
models of software systems

20
 Computer Aided Software
Engineering tools
• CASE (computer-aided software
engineering) tools Computer Aided
Software Engineering (CASE) tools
allow you to model Information
Systems by drawing diagrams
• typically provide a range of features
including:
• checks for syntactic correctness (e.g.
UML);
• repository support;
• checks for consistency and
completeness;
• navigation to linked diagrams;

21
 Developing Models of systems
• During the life of a project using an
iterative life cycle, models change along
the dimensions of:
• abstraction—they become more concrete
• formality—they become more formally
specified
• level of detail—additional detail is added as
understanding improves

22
 Types of Requirements
• Functional
• Non-functional
• Usability
 Functional Requirements
• Describe what a system must do
• Include:
– processes system will carry out
– Types of inputs and outputs with users and other
systems
– what types of data system will be holding

What we focus on in this module, Use Case

Diagrams and Class Diagrams. are part of
specifying Functional Requirements
 Non-functional
Requirements
• Concerned with how well the system performs
• Include:
– response times for system processes or updating
the system
– volumes of data handled by the system
– security considerations
– system availability (amount of downtime)
• Documented in Requirements List or
attachment to Use Case Model (for
requirements that can be linked to specific use
cases)
 Usability Requirements
• Concerned with matching the system to
the way that people work
• Sets measurable objectives
• Include:
– characteristics of users
– tasks users undertake
– account for different situations that occur
when system is being used
– acceptance criteria (how users will judge the
working system)
• Documented in Requirements List. May
be tested by Prototypes
Use Cases and Use Case Diagrams
• documents the functionality of the system from
the users’ perspective

• document the interaction between the users and

the system (supplemented with detailed use
case descriptions)

• provides overview of scope of the system

27
Notation of Use Case Diagrams

Communication Use case

association

Check email

User

Actor System or subsystem boundary

(Subject)

28
Notation of Use Case Diagrams
An actor is
user of the system
Campaign
initiates the interaction Manager

Drawn with a stick figure

Not all actors are people

can be a connected system
(e.g. actor can be Facebook or
Payment processor) Invoicing
system

29
 Good Use Cases
Identifying use cases
• do not distinguish too many, especially at first
• verb and noun combination
• use language that reflects user’s perspective (not
computer-speak)
• a ‘complete task’ from user’s perspective

NOT ‘link users’, ‘input criteria’, ‘click dropdown menu’

e.g., ‘add friend’, ‘search movies’, ‘buy groceries’
30
 Use Diagram:
Email System
Create Account

Use Cases: Login

Create Email Account

Login Check Email
Read Email
Create Email User
Send Email Create Email

Send Email
 Use Case Diagram
use case
actor
Upload assignment

Post assignment

Student
Post to Forum
Lecturer

communication
association
32
Use Case Diagram: book a car
Car rental system

cancel booking

register rental
agreement
Customer

register return of car

Car rental
employee

Send bill

Payment
Processing Process Payment
System
 Use Cases
Number of use cases
up to 80 for complex systems
20 to 50 for most systems
Diagram
very simple and abstract
standardised in UML
Description
‘structured text’, not standardised

34
Use Case Practice: Agate
Advertising Agency
Organisation’s roles may inform choice
of actors

The roles in organization give you an idea for possible actors in your use case
scenario. Whom you choose to be an actor may be a specific job title,
‘Accountant’, or can be general ‘Creative staff’.
37
Remember, external systems can be actors too.
 Existing and Proposed
Systems
Existing system:
client management
• record names
• assign client contact
• campaign
staff management
• names, grades, bonuses
Redevelop existing system in Java,
more functions
38
 Notes from the meeting
A record is kept of each client company and each client company has one person who is the
contact person. Contact person’s name and contact details are kept in the client record.
Agate nominates a member of staff to be the contact for each client.Clients have
advertising campaigns and a record is kept of every campaign.
One member of Agate’s staff manages each campaign. Staff may be working on more than
one project at a time. For each project they work on, they are answerable to the manager
of that project. When a campaign starts:
When a campaign starts, the manager estimates the likely cost agreed with by client.
Campaign’s finish date may be set at any time,and may be changed.
When the client pays, the payment date is recorded.
Each campaign includes one or more adverts. There are several types of adverts: Newspaper
adverts, Magazine adverts, Internet adverts, TV adverts, Radio Adverts
Puchasing assistants are responsible for buying space in newspapers and magazines and so
on.
The actual cost of a campaign is calculated from a range of information such as the costs of
staff time, studio time and actors, copyright material, space in newspapers

© 2010 Bennett, McRobb

Summary of Functional Requirements
To record names, address and contact details for
each client.
To record the details of each client including the title
of the campaign, planned start and finish start
dates...
To record payments for campaign
To record which staff is assigned to which client
To record which staff are working on which
campaigns, including managers.
To schedule the dates when adverts will be run.
To calculate the annual bonus for all staff.
© 2010 Bennett, McRobb
Summary of Functional Requirements?

© 2010 Bennett, McRobb

 Non-functional requirments
To enable data about clients, campaigns,
adverts and staff to be shared between
offices.
To allow the system to be modified to work
in different languages.

© 2010 Bennett, McRobb

 Notation of Use Case Diagrams
Use cases
Add a new
client

drawn as ellipses with a name inside

describe sequence of actions that the system
performs to achieve an observable result of value to
an actor
the name is usually an active verb and a noun phrase
‘user’ language, not computer-speak (not ‘input-box’,
‘click’ etc., use ‘add’ instead)
43
 Existing and Proposed
Systems
Existing system: Add a new
client
client management
• record names ?
• assign client contact
• campaign
?
staff management
• names, grades, bonuses
Redevelop existing system in Java,
more functions
44
 Existing and Proposed
Systems
Existing system: Add a new
client
client management
• record names Assign staff to work
• assign client contact on campaign

• campaign
staff management
• names, grades, bonuses
Redevelop existing system in Java,
more functions
45
 Existing and Proposed
Systems
Existing system: Add a new
client
client management
• record names Assign staff to work
• assign client contact on campaign

• campaign
Add a new
staff management campaign
• names, grades, bonuses
Redevelop existing system in Java,
more functions
46
 Notation of Use Case Diagrams
Communication associations

Add a new
client
Add a new
campaign
Campaign Assign staff to work
Manager on campaign

line drawn between an actor and a use case

represent communication link between an instance of the
use case and an instance of the actor

47
Notation of Use Case Diagrams
Subsystems (also called subjects)
drawn as a rectangle around a group of use cases
that belong to the same subject
in a CASE tool, use cases for different subjects are
usually placed in separate use case diagrams

Add a new
client
Add a new
campaign
Campaign Assign staff to work
Manager on campaign

48
Use case diagrams
for Agate Add a new
client
Add a new
campaign
Assign staff to work
Campaign on campaign
Manager Add a new advert
to a campaign
Record completion
of a campaign

Assign a staff
contact
Change a
client contact

Staff Contact Record completion

of an advert

49
Additional descriptions/notations
Each use case (ellipse) and actor (stick figure) is
usually accompanied by a textual actor and use
case description. This can be brief description, or
can be a step-by-step breakdown of the interaction
between the actor and system

These descriptions are added using the program

you are using to draw UML diagrams

50
Use Case Diagrams will often be accompanied
by more detailed descriptions of actor and use
case
Add new
advert to
campaign
Campaign
Manager

So for above Use Case, additional screens in CASE tool will

show the following descriptions:

Campaign Manager Add new advert to campaign

Detailed description… Detailed description…

……………… ………………

51
Actor Description Add new
advert to
campaign
Campaign
Manager

Campaign Manager
A Campaign manager is either a Director or an
Account Manager. They are responsible for
estimating the campaign cost and agreeing it with
the client. They are responsible for assigning staff
to the team and supervising their work, managing
the progress of the campaign, conducting any
further budget negotiations, and authorizing the
final invoice.
52
Agate Use Cases and Descriptions
Add a new A campaign can consist of many adverts. Details of
advert to a each advert are entered into the system, including
campaign advert cost
Record When a campaign is completed, the actual
completion of completion date and cost are entered. A record of
a campaign completion form is printed out for the Accountant as
the basis for invoicing the client
Assign a Clients have a member of staff assigned to them
staff contact as their particular contact person.
Change a Records when the client’ s contact person with
client Agate is changed.
contact

53
 Agate Use Cases
Record When an advert is completed, the actual date is
completion entered.
of an advert
Add a new When Agate obtains a new client, the full details of
client the client are entered. Typically this will be because
of a new campaign, and therefore the new
campaign will be added straight away.
Add a new When Agate gets the business for a new campaign,
campaign details of the campaign are entered, including the
intended finish date and the estimated cost. The
manager for that campaign is the person who
enters it.
Assign staff to When a new campaign starts, members of staff are
work on a assigned to work on it.
campaign
54
 Add a new
member of staff

Add a new staff

grade

Change the rate for

a staff grade
Accountant

Change the grade

for a member of staff

Record client
payment

55
Accountant Use Case descriptions
Add a new member of staff
When a new member of staff joins Agate, his or her details are
recorded. He or she is assigned a staff number, and the start date is
entered. Start date defaults to today’ s date. The starting grade is
entered.

56
Accountant Use Case descriptions
Add a new staff grade

Change the rate for a staff grade

Change the grade for member of staff

Record client payment

57
Accountant Use Case descriptions
Add a new staff grade
Occasionally a new grade for a member of staff must be added. The
name of the grade is entered. At the same time, the rate for that
grade and the rate start date are entered; the date defaults to today’
s date.

Change the rate for a staff grade

Annually the rates for grades are changed. The new rate for each
grade is entered, and the rate start date set (no default). The old
grade is retrieved and the rate finish date for that grade rate set to
the day before the start of the new rate.

58
 Accountant Use Cases

Change the grade for a member of staff

When a member of staff is promoted, the new grade and the
date on which they start on that grade are entered. The old
staff grade is retrieved and the finish date set to the day before
the start of the new one.

Record client payment.

When a client pays for a campaign, the payment amount is
checked against the actual cost and the date paid is entered.

59
 Good Use Cases
Identifying use cases
do not distinguish too many, especially at
first
Title
verb and noun combination
Language
‘user’ language, not computer-speak
avoid ‘click’, ‘input’, ‘menu box’
60
Detailed Description of a
Use Case
• add more detail
• … structured description
• … following a template

© 2010 Bennett, McRobb and Farmer 61

 Normal Flow
Normal flow (or path)
steps of the interaction
distinguish between the user’s request
and the system’s response

request
actor response system

62
In comparison: A more general Add new
Use Case description. Use cases advert to
campaign
get more detailed as analysis Campaign
progresses Manager

Use case description: Add a New Advert to a Campaign

A campaign can consist of many adverts.

Details of each advert are entered into the
system, including advert cost

63
 Additional descriptions for use
cases: Alternative Flow
Variation to some steps of the normal flow
Alternative flow allows several related
scenarios to be combined
• Admin. enters the • Admin updates the
student details student details

Single use case: admin enters/updates

student details
64
 Add new
Detailed Use Case Description for Agate advert to
Use Case campaign
Campaign
Name: Add a New Advert to a Campaign Manager

Description: Details of each advert are entered into the system, including advert cost
and cost relative to budget
Precondition: Advert is not already part of campaign
Normal Flow
1. Campaign manager indicates they want to add advert
2. System displays campaign budget, total cost of adverts paid for and total
estimated cost of adverts not paid for.
3. Campaign manager enters details of advert including estimated cost.
4. System checks campaign is within budget. If so, it creates new advert
and adds to list of adverts for that campaign
Postcondition: Advert is now part of campaign
Alternate Flow
Step 4. The advert will exceed the budget and a budget extension request is
generated. 65
 Additional descriptions for use
cases: Exceptions

Errors, and what happens when they occurs

Exceptions v. Alternatives
exception is abnormal
alternative is just different to the normal interaction
an alternative path could be a separate Use Case
•Caution
some versions of Use Cases don’t have exceptions
•don’t have too many exceptions
66
 Additional descriptions for use
cases: Pre- and Postconditions
Precondition
must be true,
… otherwise the interaction is not possible
Postcondition
how the system is changed by the interaction
applies to all alternatives
e.g. ‘customer order is recorded’

67
 Suggested Detailed Use Case
Description Template
Use case name
Description
Precondition: required starting state of system
(optional)
Normal flow of events (actions and system
responses)
Alternative flows (optional)
Postcondition: ending state of system (optional)
Exceptions (optional)
68
 Suggested Detailed Use Case
Description Template
Use case name
Description
Precondition: required starting state of system
(optional)
Normal flow of events (actions and system
responses)
Alternative flows (optional)
Postcondition: ending state of system (optional)
Exceptions (optional)
Difference between exceptions and alternative flows is subtle, you will not be required to
distinguish these in exams 69