1. Systems Analysis and Design I
Session 4
Use case models and requirement analysis

2. Recap Models and diagrams Activity Diagrams Requirements Capture
Section 5.2 (pp. 114 – 122), Section 7.2 (pp. 181 – 184)
Activity Diagrams
Section 5.3 (pp. 122 – 128)
Requirements Capture
Section 6.2 (pp. 138 – 142) Section (pp. 360) Section (p. 622 – 623) , Section 6.3 (pp. 142 – 150)
Information technology is the machinery that makes an IS work

3. Today Use Case Models Requirements Analysis
Use Case Modelling: Section 6.6 – (pp. 154 – 159);
Prototyping: Section (pp. 73 – 76), Section (pp. 159 – 161)
Requirements Analysis
Class Diagrams: Section 7.3 (pp. 184 – 194), Section – (pp – 215), Section (pp. 198 – 201)

4. Use Case Models Use Case Modelling Prototyping
Section 6.6 – (pp. 154 – 159)
Prototyping
Section (pp. 73 – 76)
Section (pp. 159 – 161)

5. Use Cases
Use Cases – descriptions of the functionality of the system from the users’ perspective.
Use Case diagrams
show which users will communicate with the system
define the scope of the system
Use Case descriptions
specify the interaction between the users (actors) and the system for each use case as the users see it
could be further elaborated by communication/sequence diagrams.
Shortcoming: focus on the functionality of the system, not good for non-functional requirements
What are the key activities that make this business work? 5 5

6. System or subsystem boundary
Use Case Diagrams
Four aspects:
actors
use cases
Communication association
system/subsystem boundary
System or subsystem boundary
Actor
Use case
Communication
association
Staff Contact
Change
a client contact 6 6

7. Use Case Diagrams: Actor
Describe the role that people, other systems or devices take when communicating with a particular use case
not the same as job title or a specific person
one job title may play the roles of several actors
one actor may represent several job titles
Drawn as a stick figure with a name
Note: they are not necessarily human users of the system (may be other systems: computer, automated machinery/equipment)
Staff Contact
Lecturer Taolue Chen
Role: Admission Tutor
Professor Mark Levene
Role: Research Tutor 7 7

8. Use Case Diagrams: Use Case
Describe a sequence of actions that the system performs to achieve an observable result of value to an actor
Drawn as a bubble (ellipse) with a name in or below
the name is usually an active verb and a noun phrase
Change
a client contact 8 8

9. Use Case Diagrams: Communication Association
Describes the communication link between an instance of the use case and an instance of the actor
Drawn as a line between the actor and the use case
Change
a client contact
Staff Contact 9 9

10. Use Case Diagrams: Sub-system
drawn as a rectangle around a group of use cases that belong to the same sub-system
Change
a client contact
When use cases for different sub-system are placed in separate use case diagrams, such rectangles are redundant 10 10

11. Extend and Include relationships
Use Case Diagrams:
Extend and Include relationships
The extend and include relationships between Use Cases
shown as stereotyped dependencies
[a stereotype is a special use of a model element that is
constrained to behave in a particular way]
Stereotype are shown by using a keywork in match guillemets
«extend» and «include» (text strings in guillemets)
Warning: easy to confuse extend and include!
Dependencies
Extend and Include relationships between use cases
shown as stereotyped dependencies
stereotypes are written as text strings in guillemets: «extend» and «include» 11 11

12. Use Case Diagrams: «extend»
Extend means: One use case provides additional functionality that may be required in another use case
“does something over and above what is done”
There may be multiple ways of extending a use case
represent variations in the way that actors interact with the use case
Rather than capturing all variations in one use case, document the core functionality in one and then extend it with other
The extension points show when the extension occurs
A condition can be placed in a note joined to the dependency arrow 12 12

13. Use Case Diagrams: «extend»
Campaign Manager
Check campaign
budget
summary
«extend»
Print campaign
Summary print
extension points
Condition {print option selected}
extension point: Summary print
Note: is not put in square brackets, unlike conditions in other diagrams.)
Fig. 6.7 13 13

14. Use Case Diagrams: «include»
When there is a sequence of behaviour that is used frequently in a number of use cases
Want to avoid copying the same description everywhere
separate out the sequence of behaviour that is used in many use cases
One use case includes the functionality of another use case
A use case may include more than one other
Do not overuse: Should not be used to create a hierarchical functional decomposition of the system 14 14

15. Assign staff to work on a campaign
Use Case Diagrams: «include»
Campaign Manager
«include»
Find campaign
Assign staff to work on a campaign
Fig 6.8 15 15

16. Note: you do not need to show all the details of the extension points

17. Use Case Diagrams: Generalisation
Between use cases:
there may be similar use cases with common functionality
best represented by generalising out that functionality in to a “super-use-case”
shows that one use case provides all the functionality of the more generalised use case and some additional functionality
Between actors:
shows that one actor can participate in all the associations with use cases
the more specific actor can plus some additional use cases 17 17

18. Use Case Diagrams: Generalisation
Record completion
of an advert
Staff Contact
Change
a client contact
Fig. 6.10
Super use case
Assign individual staff to work on a campaign
Assign staff to work on a campaign
Assign team of staff to work on a campaign
Campaign
Manager 18 18

19. Use Case Diagrams: Exercise
Vending machine 19

20. Assign staff to work on a campaign
Use Case Descriptions
Using a simple paragraph (very brief)
Assign staff to work on a campaign
The campaign manager wishes to record which staff are working on a particular campaign. This information is used to validate timesheets and to calculate staff year- end bonuses.
Assign staff to work on a campaign
Campaign Manager 20 20

21. Use Case Descriptions
Using a step-by-step breakdown of interaction between actor and system
Assign staff to work on a campaign
Actor Action System Response
1. The actor enters the client name. 2. Lists all campaigns for that client.
3. Selects the relevant campaign Displays a list of all staff members not already allocated to this campaign.
5. Highlights the staff members 6.Presents a message confirming
to be assigned to this campaign. that staff have been allocated.
Alternative Courses
Steps 1–3. The actor knows the campaign name and enters it directly.
scenario
Referred to
as scenario 21 21

22. Use Case Descriptions Using a template (a blank form to be filled in)
name of use case
pre-conditions
post-conditions
purpose
description
alternative courses (routes)
errors 22 22

23. Use Case Descriptions Use Case Description Examples
Record employee leaving the line
Normally employees are recorded as leaving the line when they clock off at the end of a working shift. Although there are breaks in the operation of the line during a shift (e.g., lunch breaks and downtime due to faults), when this happens employees are not normally recorded as leaving the line.
In all circumstances, date, time and location are recorded.
Stop line
When the production line stops for a routine reason, e.g., for a break, to restock or to reload equipment, the line supervisor records the time the run stopped and the reason. 23 23

24. Supporting Use cases: Prototyping
Why? Users find difficult to imagine how requirements will be translated into a working system
Overcome many of the potential misunderstandings and ambiguities that may exist in the requirements
A prototype is a system or a partially complete system
that is built quickly to explore some aspects of the system requirements and that is not intended as the final working system.
Prototyping can be used to support use case modelling
Help elicit functional requirements
Test out system architectures based on the use cases in order to meet the non- functional requirements 24 24

25. Prototyping Focus on HCI
What data should be presented to/captured from users
Investigate the most suitable form of interface
Determine whether a particular implementation platform can support certain processing req
Determine the efficacy of a particular language/DBMS
Perform an initial analysis. All software development activity utilizes valuable re­sources. Embarking upon a prototyping exercise without some initial analysis is likely to result in an ill-focused and unstructured activity producing poorly designed software.
Define prototype objectives. Prototyping should have clearly stated objectives. A proto­typing exercise may involve many iterations, each iteration resulting in some improv­ement to the prototype. This may make it difficult for the participants in a prototyping exercise to determine if there is sufficient value to continue the prototyping. However, with clearly defined objectives it should be possible to decide if they have been achieved.
Specify prototype. Although the prototype is not intended for extended operation it is important that it embodies the requisite behaviour. It is almost certainly the case that the proto­type will be subject to modification and this will be easier if the software is built according to sound design principles.
Construct prototype. Since it is important that prototype development is rapid, the use of a rapid development environment is appropriate. For example, if an interactive system is being prototyped, environments such as DelphiTM or Visual Basic® can be most effective.
Evaluate prototype and recommend changes. The purpose of the prototype is to test or explore some aspect of the proposed system. The prototype should be evaluated with respect to the objectives identified at the beginning of the exercise. If the objectives have not been met then the evaluation should specify modifications to the prototype so that it may achieve its objectives. The last three stages are repeated until the objectives of the prototyping exercise are achieved. 25 25

26. Prototyping: pros and cons
Early demonstrations of system functionality help identify any misunderstandings between developer and client
Missed client requirements can be identified
Difficulties in the interface can be identified
The feasibility and usefulness of the system can be tested, even though, by its very nature, the prototype is incomplete
The client may perceive the prototype as part of the final system
The prototype may divert attention from functional to solely interface issues
Prototyping requires significant user involvement
Managing the prototyping life cycle requires careful decision making 26 26

27. User selects Client Campaigns listed.
User Interface prototypes
For user interface prototypes, storyboarding can be used with hand-drawn designs
User interface prototypes can be implemented using languages other than the one that the system will be developed in.
Dialogue initialised.
User selects Client Campaigns listed.
User selects Campaign. 27 27

28. Take Home Messages Use Case Modelling Prototyping Use Case Diagrams
Use Case Descriptions
Prototyping
In this lecture you have learned about … 28 28

29. Requirements Analysis
Class Diagrams
Section 7.3 (pp. 184 – 194)
Section – (pp. 208 – 215)
Section (pp. 198 – 201)

30. Class Diagrams Class (and Object/Instance) Stereotypes
Attributes (and State)
Associations (and Links)
Multiplicity
Operations
Symbols of Instances, States, and Links are used in other UML diagram types
(Object Diagrams, Communication Diagrams, etc.) 30 30

31. Notation: Class class name compartment attributes compartment
Client
companyAddress
company
companyFax
companyName
companyTelephone
class name compartment
attributes compartment
operations compartment 31 31

32. companyAddress=Evans Farm, Norfolk
Notation: Object/Instance
:Client
Anonymous instance
object name compartment
FoodCo:Client
companyAddress=Evans Farm, Norfolk
attribute values
companyFax=
companyName=FoodCo
companyTelephone=
instances do not have operations 32 32

33. Attributes Attributes are:
part of the essential description of a class
the common structure of what all objects of the class can ‘know’
each object has its own value for each attribute of its class
attribute values characterise state of the object
Campaign
actualCost
campaignFinishDate
campaignStartDate
completionDate
datePaid
estimatedCost
title
checkCampaignBudget ( )
getCampaignContribution ( )
recordPayment ( )
setCompleted ( ) 33 33

34. Links a link is a logical connection between two objects FoodCo:Client
Yellow Partridge:Client
Soong Motor Co:Client
Grace Chia:StaffMember
Carlos Moncada:StaffMember
a link is a logical connection between two objects
Note: A link can also connect instances of the same class 34 34

35. Associations
An association is an abstraction that connects two classes
represents the possibility of links (logical relationship or connection) between objects of one class and objects of another
If two objects can be linked, their classes have an association
Class describes a set of similar objects
Association describes a set of similar links 35 35

36. Notation: Associations
association role
Client
StaffMember
companyAddress
staffContact
staffName
company
staffNo
liaises with
companyFax
staffStartDate
companyName
Only staff members in the role of staff contact can participate in this association
companyTelephone
association name
direction in which name should be read (optional)
Only staff members in the role of staffContact can participate in this association 36 36

37. Association End association role
Professor "playing the role" of author is associated with textbook end typed as Book.
The idea of the role is that the same class can play the same or different roles in other associations. For example, Professor could be an author of some Books or an editor.

38. Multiplicity
The multiplicity of an association is the range of permitted cardinalities of its participating objects (i.e., #objects that can participate in the association)
Decided by business rules.
for example:
any bank customer may have one or more accounts
every individual account is for one, and only one, customer
n: exactly n
*: any number
m..n: any number in the range m to n (inclusive)
0..1: optional (i.e., either none or 1)
1..*: at least one 38 38

39. Notation: Multiplicity
StaffMember
staffName
staffNo
staffStartDate
Client
companyAddress
company
companyFax
companyName
companyTelephone 1
0..*
liaises with
multiplicities
A staff member may liaise with any number of clients (including 0)
Each client is liaised with exactly one staff member 39 39

40. Multiplicity: more examples (p. 191)

41. Operations Operations are:
part of the essential description of a class
the common behaviour that all objects of the class can ‘do’
get or set attribute values (not specified in Analysis Model)
perform calculations
send messages to other objects
create or destroy links (not specified in Analysis Model)
services that objects of a class can provide to other objects
Campaign
actualCost
campaignFinishDate
campaignStartDate
completionDate
datePaid
estimatedCost
title
checkCampaignBudget ( )
getCampaignContribution ( )
recordPayment ( )
setCompleted ( ) 41 41

42. Static Analysis with UML
Requirements Model
→ Analysis Model
→ Design Model
To Draw an Analysis Class Diagram
Identify Classes
Determine Stereotypes (particular classes that will occur again and again)
Find and Locate Attributes
Add Associations
Determine Multiplicity
Find and Locate Operations
Section 7.5 p 197 42 42

43. Looking for Potential Classes
Category
Examples
People
Mr Harmsworth (a campaign manager), Dilip (a copywriter).
Organisations
Jones & Co (a forklift truck distributor), the Soong Motor Company,
Agate’s Creative Department.
Structures
Team, project, campaign, assembly.
Physical things
Fork-lift truck, electric drill, tube of toothpaste.
Abstractions of people
Employee, supervisor, customer, client.
Abstractions of physical
things
Wheeled vehicle, hand tool, retail goods.
Conceptual things
Campaign, employee, rule, team, project, customer, qualification.
Enduring relationships between members of other categories.
Sale, purchase, contract, campaign, agreement, assembly,
employment. 43 43

44. Identifying Classes Should this really be considered as a class?
Is it beyond the scope of the system?
Does it refer to the system as a whole?
Does it duplicate another class?
Is it too vague?
Is it too specific?
Is it too tied up with physical inputs and outputs?
Is it really an attribute?
Is it really an operation?
Is it really an association?
If any answer is ‘Yes’, consider modelling the potential class in some other way (or do not model it at all). 44 44

45. Take Home Messages Class Diagrams Class (and Object/Instance)
Attributes (and State)
Associations (and Links)
Multiplicity
Operations
In this lecture you have learned about … 45 45