ISP550

INFORMATION
SYSTEMS
ENGINEERING
Topic 6: Requirements Analysis &
Modelling (I)

MARCH2024 – AUGUST2024
Learning Objectives
• Explain why identifying use cases is the key to defining
functional requirements
• Describe the two techniques for identifying use cases
• Apply the user goal technique to identify use cases
• Apply the CRUD technique to validate and refine the list of use
cases
• Describe the notation and purpose for the use case diagram
• Draw use case diagrams by actor and by subsystem
• Write fully developed use case descriptions
• Develop activity diagrams to model flow of activities
Overview

• Students have been exposed to two types of

requirements, i.e. Functional & Non-functional
requirements (refer to previous lecture)
• This topic focuses on identifying and modelling the
key aspect of functional requirements– use cases
Overview
• A use case might have different flow of activities, depending
on the actor invoking the use case
• These flow of activities are called scenarios or use case
instances
• A use case description is a textual model that list and
describes the processing details for a use case
• Brief description
• Fully developed description

4
Use Cases
• Use case — an activity that the system performs,
usually in response to a request by a user
• It shows how a user uses the system
• Use cases define functional requirements
• Analysts decompose the system into a set of use
cases (functional decomposition)
• Two techniques for Identifying use cases
• User goal technique
• Event decomposition technique (not emphasised in this
class)
• Name each use case using Verb-Noun
User Goal Technique
• This technique is the most common in industry
• Simple and effective
• Identify all the potential categories of users of the
system
• Interview and ask them to describe the tasks the
computer can help them with
• Probe further to refine the tasks into specific user
goals, “I need to Ship items, Track a shipment, Create
a return”
 User Goal Technique:
Specific Steps
1. Identify all the potential users for the new system
2. Classify the potential users in terms of their
functional role (e.g., shipping, marketing, sales)
3. Further classify potential users by organizational level
(e.g., operational, management, executive)
4. For each type of user, interview them to find a list of
specific goals they will have when using the new
system (current goals and innovative functions to add
value)
 User Goal Technique
Specific Steps
(continued)
5. Create a list of preliminary use cases organized by
type of user
6. Look for duplicates with similar use case names and
resolve inconsistencies
7. Identify where different types of users need the
same use cases
8. Review the completed list with each type of user
and then with interested stakeholders
 Use Cases and CRUD
Technique
• CRUD is Create, Read/Report, Update, and Delete
(archive)
• Often introduced in database context
• Technique to validate, refine or cross-check use
cases
• NOT for primarily identifying use cases
Use Cases and CRUD Technique
• For Customer domain class, verify that there are use
cases that create, read/report, update, and delete
(archive) the domain class
 CRUD Technique
Steps
1. Identify all the data entities or domain classes involved in
the new system.
2. For each type of data (data entity or domain class), verify
that a use case has been identified that creates a new
instance, updates existing instances, reads or reports
values of instances, and deletes (archives) an instance.
3. If a needed use case has been overlooked, add a new
use case and then identify the stakeholders.
4. With integrated applications, make sure it is clear which
application is responsible for adding and maintaining the
data and which system merely uses the data.

11
Use Cases and
Brief Use Case Descriptions
 Brief use case description is often a one sentence
description showing the main steps in a use case
 Actor (who) + Verb + Noun
Use Case Diagrams
 Use case diagram— a Unified Modeling Language
(UML) model used to graphically show uses cases and
their relationships to actors
 Recall UML is Unified Modeling Language, the
standard for diagrams and terminology for developing
information systems
 Actor is the UML name for a end user
 Automation boundary— the boundary between the
computerized portion of the application and the users
who operate the application
Use Case Diagrams
Symbols
Use
Case
Diagram
s
Draw for
each
subsystem
Use
Case
Diagram
s
Draw for
actor, such
as customer
Use Case Diagrams
Use Case Diagrams
The <<Includes>> relationship
 A relationship between use cases where one use case is
stereotypically included within the other use case— like a called
subroutine. Arrow points to subroutine

18
Use Case Diagrams:
Steps
1. Identify all the stakeholders and users who would benefit
by seeing a use case diagram
2. Determine what each stakeholder or user needs to
review in a use case diagram: each subsystem, for each
type of user, for use cases that are of interest
3. For each potential communication need, select the use
cases and actors to show and draw the use case
diagram. There are many software packages that can be
used to draw use case diagrams
4. Carefully name each use case diagram and then note
how and when the diagram should be used to review use
cases with stakeholders and users
The Software
Requirements Document
The software requirements document is the official
statement of what is required of the system developers.
Should include both a definition of user requirements and a
specification of the system requirements.
It is NOT a design document. As far as possible, it should set
of WHAT the system should do rather than HOW it should do
it.
Information in requirements document depends on type of
system and the approach to development used.
Systems developed incrementally will, typically, have less
detail in the requirements document.
Requirements documents standards have been designed e.g.
IEEE standard. These are mostly applicable to the
requirements for large systems engineering projects.
Requirements Specifications
• A Software Requirements Specification (SRS) – a
requirements specification for a software system –
is a complete description of the behavior of a
system to be developed.
• It includes a set of use cases that describe all the
interactions the users will have with the software.
• In addition to use cases, the SRS also contains non-
functional requirements (such as performance
requirements, quality standards, or design
constraints)
 Requirements
Specifications
A Software Requirements Specification (SRS)
The software requirement specification document enlists all
necessary requirements for project development. To derive the
requirements, we need to have clear and thorough understanding
of the products to be developed.
A general organization of an SRS is as follows:
Introduction
Purpose, Scope, Definitions, System Overview, References
Overall Description
Product Perspective, Product functions, User characteristics, constraints,
assumptions and dependencies.
Specific Requirements
External Interface requirements, functional requirements, performance
requirements, design constraints, logical database requirement, software system
attributes.
Users of a Requirements
Document
 Use Case Descriptions
• Provide information about each use case, including actors,
stakeholders, preconditions, post conditions, the flow of activities
and exceptions conditions
• Activity diagrams can also be used to show the flow of activities for a
use case
• Brief description of use cases are shown below:

24
Use Case Descriptions
• Typical use case description templates include:
• Use case name
• Scenario (if needed)
• Triggering event
• Brief description
• Actors
• Related use cases (<<includes>>)
• Stakeholders
• Preconditions
• Post conditions
• Flow of activities
• Exception conditions

25
Fully
Developed
Use Case
Description

Use case:
Create customer
account

26
Fully Developed Use Case
Description: Precondition
• Preconditions
• What must be true before the use case begins
• What objects must exist, information must be available, condition of actor

27
Fully Developed Use Case
Description: Post-condition
• Post conditions
• What must be true after the use case
is completed
• What objects are created, updated;
how objects are associated
• Purpose:
• Use for planning test case expected
results
• Indicated what objects are important
during design

28
Fully Developed Use
Case Description: Flow
of Activities

Sequence of steps and the response

29
Fully Developed Use Case
Description
Exception/Alternative Conditions

30
Use Case UML Activity Diagram
Create
Customer
Account

Note: this
shows flow of
activities only
Another way to
document a
use case
description 31
Use Case UML Activity Diagram

Fill shopping cart

Note: this shows use
case with
<<includes>>
relationship

32
Summary
√ Explain why identifying use cases is the key to
defining functional requirements
√ Describe the two techniques for identifying use cases
√ Apply the user goal technique to identify use cases
√ Apply the CRUD technique to validate and refine the
list of use cases
√ Describe the notation and purpose for the use case
diagram
√ Draw use case diagrams by actor and by subsystem
√ Write fully developed use case descriptions
√ Develop activity diagrams to model flow of activities