Systems Analysis and

Design
Systems Modelling and Requirements Formalising
Aim…

• System Modelling
• Formalizing requirements
• Use case Diagrams
System modelling

• What do we model?
• In general, we would like to model:
• The business system
• The data structure
• The behaviour of the system

• Why do we model?
• Communicate business problems
• Requirements
• Solutions

3
Requirements engineering activities: Documenting

Requirements Requirements Requirements

elicitation analysis validation

Requirements documentation

Requirements management

• Documenting requirements is concerned with writing up the

requirements in a formal way.
4
Documenting requirements

How do you document

requirements?

Use case diagram

Use case document

5
Use Cases
‘Structured requirements’

• that describe a piece of system functionality – describe

‘What’ not ‘How’

 A description of the external sequence of events between an actor and

the system needed to meet a functional requirement
 Expected to deliver value to an actor to further the aims of a business
process
 The sum of the use cases is ‘The System’
(as seen by its end users)
 Must be named using a verb-noun phrase
Use Cases
• Used in requirements engineering
• Documents the actions the system performs with observable results
• Captures the system at its external interface:
• the systems functional requirements
• the systems interaction with external actors
• Effective means of communicating with stakeholders
Focus of Use Cases
• Always described from the actor’s point of view
• Yield a result of value for the actor
• The scope of a use case is a single business transaction
using the IT system
• Support tasks in business processes
• The processes form the main context of the IT system

• Describe only interactions with the system and not any

events outside of the IT
• Should not be confused with business processes
• The use case is a piece of IT functionality
• The business process is an end-to-end set of business
tasks, some of which may be supported by IT
Use Case Diagram Notation
The main symbols are the:
1. System boundary
2. Actor
3. Use Case and
4. Association Line that says: “This Actor is involved with this Use Case”
Finding Actors
• Human actors
• Identify roles
• Name them
• Non human actors
• Other systems that interact with the system
• I/O devices
• How do you find them?
• Who will use the functionality?
• Who will support/maintain the system?
• What other systems does the system need to interact with?
Finding Use Cases
• Use Cases
• Functionalities the system offers to the user/actor
• How do you find them?
• What does the actor need to do in the system?
• What does the actor require from the system?
 Actor Generalisations
• Instances of the more specific actor may be substituted by instances
of the more general actor.
Use Case Diagram Example

Use Case diagrams show who is involved with which activity

Use case relationship: includes and extends
• <<includes>>: one use case always involves another
• <<extends>>: under certain conditions, a use case follows a
variant
Use case relationship: Example 2
 Use Case Generalisations
• Use case generalisations may refer to inheritance
• More specific use cases inherit actors, behaviours from the more
general use case.
Advantages of Cases
• Easy to create and read
• Easily understood by users
• Allows capturing different actors views of the system
• Allows developers to think from the users view point
• Serves as input to user documentation

• BUT…
• Does not capture non functional requirements of the system
• A separate list of functional and non functional requirements
should be kept to complement use case diagrams
Use case modelling
• Step 1: Identifying Actors and Use Cases
• Step 2: Construct Use Case Model
• System scope and boundary in terms of use cases and actors
• partitioned into sub-systems
• Step 3: Use Case sequence of actions
• Step 4: Identifying use case dependencies, <<includes>>
• Step 5: Use case alternate course of actions, <<extends>>
• Step 6: Finding Potential Objects: Nouns in use case
Documenting a Use Case – Use case description

Name
Borrow Item
Goal
To create a loan record for each item borrowed.
Brief Description
A member brings the item, or items, to be borrowed to the
checkout counter. The member selects the borrow items option
and provides membership identification. The member then
identifies which item(s) are being borrowed. The library system
makes a loan record for each item lent and the member takes the
item(s).

Use Case Description complements each use

case in the diagram.
Use Case Template (House Style)

20
 What we covered …
Formalizing Requirements
• Use Case Diagrams
• Use Case House Style Document
 TO DO…

Exercises