This the document of System analysis and design course.

1. 11/21/2023 1
Chapter -4
Requirement Modeling

2. Outline
 Software requirements analysis and specification
 Use case approach to define functional requirements
 How to extend use case to describe non-functional
requirements
 Use case modeling
 Actors and their role in the use case
 How to document use cases
 Use case guidelines
 How to describe use case using activity diagram
11/21/2023 2

3. Use Case Modeling
The Software requirements describe the functionality that
the system must provide for the users.
Requirement Analysis:
What is your role in the current system?
How do you use the current system?
What are the advantage and limitation of the current system?
What features the new should provide for you?
After the analysis the requirements has to be specified.
Requirement specification document need to be agreed by both
the analysts and users. (functional and nonfunctional)
11/21/2023 3

4. Use Case Modeling
In defining the functional requirement, it is necessary to
describe:
What functionality the system needs to provide
What information needs to be input from external
What the system needs to output to the external
What stored information the system reads or update
Consider the following for a well written SRS:
Correct, Complete, Unambiguous, Consistent, Verifiable,
Understandable by non-technical, Modifiable, Traceable.
Several reviews need to be held with users.
11/21/2023 4

5. Use Cases
Use case model describes the functional requirements of
the system in terms of actors and use cases:
What the system do, not the internals of how it does it
A use case always starts with input from an actor
The actor provides input to the system and the system
response to the actor
Use case might involves several interactions b/n the actor and
the system
More complex use cases might involves more than one actors.
11/21/2023 5

6. A Simple Use Case
 The essentials of the use case description consist of the
following:
 The name of the use case, View Alarms.
 The name of the actor, Monitoring Operator.
 A one-sentence use case summary
 The description of the main sequence of events.
 The description of any alternative to the main sequence
11/21/2023 6

7. A Simple Use Case
11/21/2023 7

8. Actors
Actor can be human or external system
Actor can be:
Primary actor: initiates a use case
Secondary actor: can participate in the use case
11/21/2023 8
External system actors
Input device actors

9. Primary and Secondary Actors
In some case, an actor can be an input device actor or an
input/output device actor.
This can happen when there is no human involvement with the
use case.
An actor can also be a timer actor that periodically sends
timer events to the system.
11/21/2023 9
Example of timer actor

10. Identifying Use cases
To determine the use cases, it is useful to start by
considering the actors and the interactions they have with
the system.
Each use case describe interactions b/n the actor and the
system
In this way, the functional requirements of the system are
described in terms of the use cases
To avoid functional decomposition, focuses on a sequence of
events that provide s a useful result to the actor.
11/21/2023 10

11. Identifying Use cases
Each sequence through the use case is called a scenario.
A use case usually describes several scenarios, one main
sequence and a number of alternative sequences.
Note that a scenario is a complete sequence through the
use case:
So a scenario could start out executing the main sequence and
then follow an alternative branch at the decision point.
11/21/2023 11

12. Documenting Use Cases in Use case Model
Each use cases in the use case model is documented in the
use case description:
Use case:
Summary: brief description (1 or 2 sentences)
Dependency: optional (includes / extends)
Actors: primary and secondary
Precondition: one or more conditions
Description of main sequence: the most usual sequence
Description of alternative sequences: alternative branches off the main
Nonfunctional requirements: description of nonfictional requirements
Postcondition: condition that must be true at the end of the use case
Outstanding questions: question to be discussed with the user
11/21/2023 12

13. Use case Descriptions
An example of a use case for Make Order Request, which
is one of the use cases from the Online Shopping System.
11/21/2023 13

14. Use case Descriptions (Scenario)
11/21/2023 14

15. Use case Descriptions (cont.)
11/21/2023 15

16. Use Cases Relationships
When use cases get too complex, dependencies between
use cases can be defined by using the include and extend.
The objective is to maximize extensibility and reuse of use
cases.
 Include use case: common to more than one use case.
 An inclusion use case is executed in conjunction with a base
use case.
11/21/2023 16

17. Use Cases Relationships
11/21/2023 17
Example of an include use case and include relationships

18. Use Cases Relationships
11/21/2023 18

19. Use Cases Relationships
11/21/2023 19

20. Use Cases Relationships
The include relationship can also be used to structure a
lengthy use case.
 The base - high level sequence, the inclusion low-level sequence
11/21/2023 20
Example of multiple include use case and include relationships

21. Use Cases Relationships
The extend relationship is used to model alternative paths
that a use case might take.
The extend relationship can be used as follows:
 To show a conditional part of the base use case that is
executed only under certain circumstances.
 To model complex or alternative paths.
The extension use case, depends on the base use case and
executes only if the condition in the base use case is true.
11/21/2023 21

22. Use Cases Relationships
11/21/2023 22
Example of an extend relationship and extension use case

23. Use Cases Relationships
11/21/2023 23

24. Use Cases Relationships
11/21/2023 24

25. Specifying Nonfunctional Requirements
The nonfunctional requirements can be specified in a
separate section of the use case.
For the Validate PIN use case, they would be described as
follows:
11/21/2023 25

26. Use Case Packages
A use case package groups together related use cases to
manage the large number of use cases in a large system.
11/21/2023 26

27. Activity Diagram
An activity diagram can be used to represent the sequential
steps of a use case, including the main sequence and all
the alternative sequences.
11/21/2023 27

28. Activity Diagram for ATM Use Cases
11/21/2023 28

29. Static Modeling
11/21/2023 29

30. Static Modeling
A static model describes the static structure of the system.
 The classes in the system
 The attributes of the class
 The relationship b/n the class
 The operations of each class
The multiplicity of an association:
 One-to-one, One-to-many, Numerically specified, Optional,
Many-to-many association.
11/21/2023 30

31. Static Modeling
11/21/2023 31
Example of association on class diagram (bank application)

32. Static Modeling
11/21/2023 32
Example of class attributes

33. Association Class
A class that models an association between two or more
classes.
 The attributes of the association class are the attributes of
the association
11/21/2023 33
Example of association class

34. Composition and Aggregation
Identify a class that is made up of other class (whole/part).
 A composition is a stronger relationship than an aggregation
 An aggregation is a stronger relationship than an
association
11/21/2023 34
Example of composition hierarchy (physical class)

35. Composition and Aggregation
In aggregation parts can be added and removed from the
aggregate whole. (conceptual classes)
11/21/2023 35
Example of aggregation hierarchy

36. Generalization and Specialization
A discriminator is an attribute that indicates which
property of the object is being abstracted by the
generalization relationship.
11/21/2023 36
Generalization / Specialization hierarchy

37. Static Modeling and the UML
The approach used in COMET is to have a conceptual
static model early in the analysis phase that is used to
model and help understand the problem domain.
 Physical class and the data-intensive classes (entity classes)
 Physical: physical devices, sensors, external systems, and
timers. (embedded system)
 Entity: in information systems (banking application)
11/21/2023 37

38. Static Modeling and the UML
11/21/2023 38
Conceptual static model for Banking System

39. Static Modeling of the System Context
To understand the scope of the system.
Context modeling explicitly identifies what is inside the
system and what is outside. It can be done at:
 The total system (HW and SW) level
 The software system (software only) level
System context diagram: shows the border b/n the system
and the external environment.
Software system context diagram: shows the border b/n the
SW system and the external environment.
11/21/2023 39

40. Static Modeling of the System Context
11/21/2023 40
Banking HW/SW system context class diagram

41. Static Modeling of the System Context
11/21/2023 41
Banking software system context class diagram

42. Categorization of classes using UML Stereotypes
In class structuring, the COMET method advocates
categorizing classes in order to group together classes with
similar characteristics.
 Stereotypes are used to distinguish among the various kinds
of classes.
 A class is categorized by the role it plays in the application.
 Such as:
 <<entity>> class or <<boundary>> class
 External class can categorized: <<external system>> <<external
user>>
11/21/2023 42

43. Categorization of classes using UML Stereotypes
11/21/2023 43
Example of UML classes and their stereotypes

44. Modeling External Classes
Classification of external classes from the perspective of
the software system.
11/21/2023 44
Classification of external classes by stereotype

45. Modeling External Classes
The standard association names on software system
context class diagrams are Inputs to, Outputs to,
Communicates with, Interacts with, and Signals.
11/21/2023 45

46. Modeling External Classes
 To develop a SW system context class diagram:
 Determine the external classes from the static model
 Categorized the external classes using stereotype
 An I/O device actor is equivalent to an external I/O
device class.
 An external system actor is equivalent to an external
system class.
 A timer actor interfaces to the system via an external
timer class.
11/21/2023 46

47. Static Modeling of Entity Classes
The COMET approach emphasizes static modeling of
entity classes, in order to take advantage of the strengths of
the static modeling.
 Entity classes are often mapped to a database in the design
phase.
 The COMET emphasis is on determining the entity classes
that are defined in the problem, their attributes, and their
relationships.
11/21/2023 47

48. Static Modeling of Entity Classes
11/21/2023 48
Entity class model for online shopping application

49. Modeling Class Attributes
An entity class is data-intensive, meaning that it has
several attributes.
 Entity classes having only one attribute is questionable.
 Most probably it can be an attribute of another class
11/21/2023 49

50. Modeling Class Attributes
11/21/2023 50
Entity class attributes for online shopping application