Receptionist Patient: Patient Doctor: Doctor - The vertical solid line represents the life of an object. - It runs from top to bottom.  Messages:- - The arrow represents the message passing between objects. - The arrow head points to the receiver. - The message name is written near arrow. - Synchronous and asynchronous message Receptionist Patient Doctor makeAppointment() checkAvailability() scheduleAppointment() confirmAppointment() treatPatient() billPatient() - Sequence diagram shows the time sequence of messages between objects. - It emphasizes on

1. Requirements Analysis
and UML Modeling
Slide 1

2. Contents
• Requirement Elicitation,
• Software requirement specification (SRS),
• Developing Use Cases (UML)
• Requirement Model –
–Scenario-based model
–Class-based model,
–Behavioral model

3. Key Ideas
• The goal of the analysis phase is to truly
understand the requirements of the new
system and develop a system that addresses
them.
• The first challenge is collecting and integrating
the information
• The second challenge is finding the right
people to participate.
Slide 3

4. Elicitation & Analysis
• The requirements process consists of two
activities:
– Requirements Elicitation:
• Definition of the system in terms understood
by the customer (“Problem Description”)
– Requirements Analysis:
• Technical specification of the system in terms
understood by the developer (“Problem
Specification”)
Slide 4

5. Analysis Phase
• This phase takes the general ideas in the system
request and
– refines them into a detailed requirements definition
– functional models,
– structural models and
– behavioral models
• Final deliverable: system proposal
– Includes revised project management deliverables,
• feasibility analysis and
• work plan
Slide 5

6. Requirement Specification
• a statement of what
– the system must do or
– characteristics it must have
– Written from businessperson perspective (what
the system does?)
– Later requirements become more technical (how
the system will be implemented?)
Slide 6

7. Functional vs. Nonfunctional
• A functional requirement relates directly to a
process the system has to perform or
information it needs to contain (functions the
system needs to have).
• Nonfunctional requirements refer to
behavioral properties that the system must
have, such as performance and usability.
Slide 7

8. Functional Requirements
Slide 8
Interface requirements
• Field 1 accepts numeric data entry.
• Field 2 only accepts dates before the
current date.
Business Requirements
• Data must be entered before a request
can be approved.
• Clicking the Approve button moves the
request to the Approval Workflow.

9. Nonfunctional Requirements
Slide 9

10. Nonfunctional Requirements
• Performance – for example Response Time,
Throughput, Utilization, Static Volumetric
• Scalability ,Capacity, Availability, Reliability,
Recoverability, Maintainability, Serviceability
• Security ,Regulatory, Manageability,
Environmental, Data Integrity, Usability
,Interoperability

11. Slide 11

12. Purpose Of requirement analysis
Slide 12
Scope of project
Establish the user’s expectations for system
Resource of clarification

13. Requirements Gathering
Slide 13

14. • Ensure that all stakeholder will considered
• Identifies all users and stakeholders who will influence
system
Stakeholder
Analysis
• It is used in identifying all possible solutions
• It will give good number of ideas from groupBrain Storming
• Sit with clients and ask questions
• In depth ideas from stakeholdersOne to One Interview
• Interview with more persons
• Can get hidden requirementsGroup Interview
• Prepare documentation
• Can help in As Is process design analysisDocument Analysis
• Modern technique for gathering requirements
• Build the prototype ,its more practical and reduce riskPrototyping
• Arrange workshops for gathering requirements
• Contain two analyst facilitator and Scriber
Joint Application
Devlopment Slide 14

15. Joint Application Design (JAD)
Important Roles
• Facilitator
– sets the meeting agenda and guides the
discussion
• Scribe
– assist the facilitator by recording notes, making
copies, etc.
• Project team, users, and management
Slide 35

16. JAD Meeting Room
Slide 37
JPEG Figure 5-5 Goes Here

17. The JAD Session
• Tend to last 5 to 10 days over a three week period
• Prepare questions as with interviews
• Formal agenda and ground rules
• Facilitator activities
– Keep session on track
– Help with technical terms
– Record group input
– Help resolve issues
• Post-session follow-up
Slide 38

18. Slide 39

19. Slide 43

20. Summary
• First Step is to determine requirements
• Systems analysts use these techniques
– Interviews,
– JAD,
– Questionnaires,
– Document Analysis, and
– Observation.
Slide 51

21. EXECERCISE
amazon.com
Develop the requirements definition for the site.
Create a list of functional business requirements
that the system meets. What are different
nonfunctional business requirements does the
system meet? Provide example for each kind.
Slide 52

27. Use Case Diagrams

29. Use Cases
• What is a Use Case
A formal way of representing how a business
system interacts with its environment
Illustrates the activities that are performed by
the users of the system
A scenario-based technique in the UML
Scenario is A sequence of actions a system
performs that yields a valuable result for a
particular actor.

30. Use Case Analysis
• What is an Actor?
– A user or outside system that interacts with
the system being designed in order to obtain
some value from that interaction
• Use Cases describe scenarios that describe the
interaction between users of the system (the
actor) and the system itself.

31. Use Cases
• Use case diagrams describe what a system
does from the standpoint of an external
observer. The emphasis is on what a
system does rather than how.
• Use case diagrams are closely connected to
scenarios. A scenario is an example of what
happens when someone interacts with the
system.

32. Use Cases
• Here is a scenario for a medical clinic.
• A patient calls the clinic to make an appointment
for a yearly checkup. The receptionist finds the
nearest empty time slot in the appointment book
and schedules the appointment for that time slot. "
• We want to write a use case for this scenario.
• Remember: A use case is a summary of scenarios
for a single task or goal.

33. Use Cases
• Step 1 Identify the actors
• As we read the scenario, define those people
or systems that are going to interact with the
scenario.
• A patient calls the clinic to make an appointment for a yearly checkup. The
receptionist finds the nearest empty time slot in the appointment book and
schedules the appointment for that time slot. "

34. Actors
• An Actor is outside or external the system.
• It can be a:
– Human
– Peripheral device (hardware)
– External system or subsystem
– Time or time-based event
• Represented by stick figure

35. Use Cases
• A use case is a summary of scenarios for a
single task or goal.
• An actor is who or what initiates the events
involved in the task of the use case. Actors
are simply roles that people or objects play.
• So as we read our scenario, what or who is
the actor????

36. Use Cases
• So as we read our scenario, what or who is
the actor????
• A patient calls the clinic to make an appointment for a
yearly checkup. The receptionist finds the nearest empty
time slot in the appointment book and schedules the
appointment for that time slot. "
• The actor is a Patient.

37. Use Cases
• The use case is a summary of scenarios for
a single task or goal.
• So What is the Use Case????
• The Use Case is Make Appointment.
• It is a use case for the medical clinic.

38. Use Cases
• The picture below is a Make Appointment use case for the medical clinic.
• The actor is a Patient. The connection between actor and use case is a
communication association (or communication for short).
Actors are stick figures. Use cases are ovals.
Communications are lines that link actors to use cases.

39. Use Case Componentss
• The use case has three components.
• The use case task referred to as the use case that
represents a feature needed in a software system.
• The actor(s) who trigger the use case to activate.
• The communication line to show how the actors
communicate with the use case.

40. Use-Case Diagram
A use case diagram is a collection of actors, use cases, and their communications.

41. 1
Withdraw
Money
2
Deposit
Money
3
Transfer
Money
4
Check
Balance
ATM System
Bank
Customer
Customer
Accounts
Database
primary actor
role
system name
system boundary
secondary actor
use case
<<Customer
Accounts
Database>>
alternative
actor notation
stereotype
association

42. 7
73

43. 7
74

44. Use Case Diagram
• Other Types of Relationships for Use Cases
– Generalization
– Include
– Extend

45. Components of Use Case Diagram
• Generalization Relationship
– Represented by a line and a hollow arrow
• From child to parent
Child use case Parent use case

47. Use Case Diagram
• Include Relationship
– Represents the inclusion of the functionality of one
use case within another
– Arrow is drawn from the base use case to the used
use case
– Write << include >> above arrowhead line
– the original use case is not complete without the
included one.

48. Use Case Diagram
• Extend relationship
– Represents the extension of the use case to
include optional functionality
– Arrow is drawn from the extension use case to the
base use case
– Write << extend >> above arrowhead line

49. Example :Include , Extend
Withdraw
money
Customer
Verify Pin
Insufficient
balance
Charge fee
<<Extend>>
<<Include>>
<<Extend>>
Base Use case

50. Example of Relationships

56. Use Case Relationships
• Pro:
– Reduces redundancy in use cases
– Reduces complexity within a use case
• Con
– May introduce complexity to use case diagram

57. Benefits of Use Cases
• Use cases are the primary vehicle for requirements capture in
RUP(rational unified process)
• Use cases are described using the language of the customer (language
of the domain which is defined in the glossary)
• Use cases provide a contractual delivery process (RUP is Use Case
Driven)
• Use cases provide an easily-understood communication mechanism
• When requirements are traced, they make it difficult for requirements
to fall through the cracks
• Use cases provide a concise summary of what the system should do at
an abstract (low modification cost) level.

58. Use Case Model Survey
• The Use Case Model Survey is to illustrate, in graphical form,
the universe of Use Cases that the system is contracted to
deliver.
• Each Use Case in the system appears in the Survey with a
short description of its main function.
– Participants:
• Domain Expert
• Architect
• Analyst/Designer (Use Case author)
• Testing Engineer

59. Use Case Diagram
• We will build use case diagram for a video
rental system in the examples.
• Look and identify potential actors and use
case tasks.
•
• Nouns and verbs may be helpful.

61. Example

63. Example

65. Class Diagram

66. Class Diagram
• Classes: Entities with common features, i.e.
attributes and operations.
• Represented as solid outline rectangle with
compartments.
• Compartments for name, attributes, and
operations.
• Attribute and operation compartments are
optional depending on the purpose of a
diagram.

67. UML Class Representation
• A class represents a set of objects having
similar attributes, operations, relationships
and behavior.

69. What are the Different Types of
Relationships Among Classes?
–Association
–Inheritance(Generalization ,Specialization)
–Aggregation/Composition

74. Domain model class diagram
106

75. Multiplicity of association
107

80. 112
A Generalization/Specialization
Hierarchy for Motor Vehicles

81. 113
A Generalization/Specialization
Hierarchy for Orders

82. Aggregation Relationship
• Represents whole-part relationship
• Represented by a diamond symbol at the composite end.
• Usually creates the components : Also, aggregate usually
invokes the same operations of all its components.
• This is in contrast to plain association
• Usually owner of the components : But can share with
other classes

83. Aggregation & Composition
• Aggregation implies a relationship where the
child can exist independently of the parent.
Example: Class (parent) and Student (child).
Delete the Class and the Students still exist.
• Composition implies a relationship where the
child cannot exist independent of the parent.
Example: House (parent) and Room (child).
Rooms don't exist separate to a House.

85. Composition
• A stronger form of aggregation The whole is
the sole owner of its part. A component can
belong to only one whole
• The life time of the part is dependent upon
the whole. The composite must manage the
creation and destruction of its parts.
HouseHouse
RoomRoom

88. 122

89. 123
Bank Account System Class Diagram

90. Systems Analysis and
Design in a Changing World,
3rd Edition
124

92. Class Diagram Inference Based on Text
Analysis(based on Dennis, 2002)
• A common noun implies a class e.g. Book
• A proper noun implies an object (instance of a class):
CSE Dept, OOSD, etc.
• An adjective implies an attribute e.g. price of book
• A “doing” verb implies an operation. Can also imply a
relationship e.g. student issues Book
• A “having” verb implies an aggregation relationship
• A predicate or descriptive verb phrase elaborates an
operation e.g.ISBN numbers are integers
• An adverb implies an attribute of an operation e.g. fast
loading of image…

94. u Draw a UML Class Diagram representing the following
elements from the problem domain for a hockey league. A
hockey league is made up of at least four hockey teams. Each
hockey team is composed of six to twelve players, and one
player captains the team. A team has a name and a record.
Players have a number and a position. Hockey teams play
games against each other. Each game has a score and a
location. Teams are sometimes lead by a coach. A coach has a
level of accreditation and a number of years of experience,
and can coach multiple teams. Coaches and players are
people, and people have names and addresses. Draw a class
diagram for this information, and be sure to label all
associations with appropriate multiplicities.

96. Systems Analysis and
Design in a Changing World,
3rd Edition
131

98. Scenario Based Model :
Activity , Sequence and Collaboration

99. 135
Activity Diagrams
• Used to document workflow of business process
activities for each use case or scenario
• Standard UML 2.0 diagram
• Can support any level of use case description; a
supplement to use case descriptions
• Helpful in developing system sequence diagrams

100. Activity Diagrams Symbols

101. 137
Activity Diagram Symbols

102. Basic Components in an Activity
Diagram
• Initial node
– The filled circle is the starting
point of the diagram
• Final node
– The filled circle with a
boarder is the ending point.
An activity diagram can have
zero or more activity final
state.
• Activity
– The rounded circle represents
activities that occur. An
activity is not necessarily a
program, it may be a manual
thing also
• Flow/ edge
– The arrows in the diagram. No
label is necessary

103. Basic Components in an Activity
Diagram
• Fork
– A black bar ( horizontal/vertical )
with one flow going into it and
several leaving it. This denotes the
beginning of parallel activities
• Join
– A block bar with several flows
entering it and one leaving it. this
denotes the end of parallel
activities
• Merge
A diamond with several flows entering and
one leaving. It is not used to
synchronize concurrent flows but to
accept one among several alternate
flows.
Received form
Payment fees
Hostel
allotment
Issue identity
card
Medical check
Issue library
card

104. Basic Components in an Activity
Diagram
• Difference between Join and Merge
– A join is different from a merge in that the join
synchronizes two inflows and produces a single outflow.
The outflow from a join cannot execute until all inflows
have been received
– A merge passes any control flows straight through it. If
two or more inflows are received by a merge symbol,
the action pointed to by its outflow is executed two or
more times

105. Basic Components in an Activity
Diagram
• Decision
– A diamond with one flow
entering and several leaving. The
flow leaving includes conditions
as yes/ no state
• Swim lane
– A partition in activity diagram by
means of dashed line, called
swim lane. This swim lane may
be horizontal or vertical
Received form
Payment fees
Hostel
allotment
Issue identity
card
Medical check
Issue library
card

109. 145
Simple Activity Diagram
to Demonstrate a Workflow

111. 148
Activity
Diagram—
Web Order
Scenario

112. 151

113. 152

114. 153
Activity
Diagram—
Telephone Order
Scenario

115. Introduction to Sequence diagram
Sequence diagram is interaction diagram that
shows the set of objects and messages send
and receive by those object.
It mainly emphases on time ordering and
messages.
It is used to illustrate the dynamic view of
system.
These are also called as “Isomorphic diagram”.

116. Terms and Concepts
 Objects or Participants :-
 The sequence diagram is made up of
collection of participants or objects.
Participants are system parts that interact
each other during sequence diagram.
 The participants interact with each other by
sending and receiving message
 The object is represented by as below
Object:Class_Name
 Lifeline:-
 Lifeline represents the existence of an object
over a period of time.
 It is represented by vertical dashed line.
 Most objects that appeared in ‘Interaction
diagram’ will be in existence for the duration of
an interaction. So, these objects are aligned at
top of diagram with their lifeline from top to
bottom of diagram.

117. Terms and Concepts
 Activation bar:-
 It is also called as focus of control. It shows the period of time during which an
object is performing an action.
 The top of rectangle is aligned with start of the action. The bottom is aligned with its
completion and can be marked by a written message
 It is represented by tall thin rectangle:
Activation
Nesting

118. Terms and Concepts
 Messages:-
 The interaction in a sequence diagram between the objects can be shown by using
messages.
 The messages on sequence diagram are specifies using an arrow from participant
that wants to pass the messages to the participant that receive the messages .
 Messages can be flow in whatever direction required for interaction from left to
right and right to left.

119. • Synchronous messages – A
synchronous message waits for a reply
before the interaction can move
forward. The sender waits until the
receiver has completed the processing
of the message. The caller continues
only when it knows that the receiver
has processed the previous message
i.e. it receives a reply message.
• Asynchronous Messages – An
asynchronous message does not wait
for a reply from the receiver. The
interaction moves forward irrespective
of the receiver processing the previous
message or not. We use a lined arrow
head to represent an asynchronous
message.
Terms and Concepts

120. Terms and Concepts
Messages:-
 It has following kinds of messages:
3)Reflexive messages:-
* If the object sends the message to itself then it is called as ‘Reflexive message.
* It is represented by solid line with loops the lifeline of object.
4)Return messages:-
* It can be used at the end of activation bar to show that control flow of activation
returns to the participant that pass the original message.
* It is represent by dashed line from sender to receiver.

121.  5)Create messages:-
* It is used to create object during interaction.
* The object can be created by using <<create>> to indicate the timing of creation.
* Creating message can be shown as below:
6)Destroy messages:-
* It is used to destroy the objects during interaction.
* The objects can be terminated using <<destroy>> which points to an “x”.
* It indicates that object named message is terminated.

122. Terms and Concepts
Time:-
 The sequence diagram describes the order in which interaction takes place.
 So time in an important factor. The time on sequence diagram starts at top of the page just
below the object and then progress down the page.
 Time is all about ordering but not duration.

123. Example

127. Sequence diagram of Railway reservation
system

128. Indicating selection and loops
• frame: box around part of a sequence diagram to indicate selection or loop
– if -> (opt) [condition]
– if/else -> (alt) [condition], separated by horizontal dashed line
– loop -> (loop) [condition or items to loop over]

137. Collaboration Model

138. Collaboration Model

139. Behavioral Model : State Chart Diagram

140. Objectives
• Introduce the terms used with respect to state
diagrams
• Discuss the context in which state diagrams
are used
• Introduce substates
• Discuss concurrent state diagrams

141. Statechart Diagrams
• State diagrams describe the life of an object using
three main elements:
– States of an object
– Transitions between states
– Events that trigger the transitions
• A state diagram or statechart specifies a state
machine
– A state machine is described for a class
– Each object has it’s own state machine

142. State Machine Diagrams
• States - A state is denoted by a round-cornered rectangle with
the name of the state written inside it.
• Initial and Final States - The initial state is denoted by a filled
black circle and may be labeled with a name. The final state is
denoted by a circle with a dot inside and may also be labeled
with a name.

143. States
• Show what the dependencies are between the state of an
object and its reactions to messages or other events
• State
– is a condition or situation during the life of an
object within which it performs some activity, or
waits for some events
– Has a name
– Has actions -- execute the state
– Has internal transitions -- transitions cause no
change in a state
– substates -- the nested structure of a state
involving disjoint or concurrent substates

144. States
• For example:
entry/unlock door
do/prepare materials
telephone rings/answer telephone
include/lecture state
exit/lock door
At Work state name
action performed on entry to state
activity performed while in state
action performed on arrival of named event
name of a sub-state machine
action performed on leaving state

145. Initial and Final States
• An example:
At Work At Homego home
go to work
die die

146. State Machine Diagrams
• Transitions - Transitions is a progression from one state to another are
denoted by lines with arrowheads. A transition may have a trigger, a guard
and an effect.
• Self-Transitions - A state can have a transition that returns to itself, as in
the following diagram. This is most useful when an effect is associated
with the transition.
• "Trigger" is the cause of the transition, which could be a signal, an event, a
change in some condition, or the passage of time. "Guard" is a condition
which must be true in order for the trigger to cause the transition. "Effect"
is an action which will be invoked directly on the object that owns the
state machine as a result of the transition.

147. 195
Simple State Machine Diagram for a
Printer

148. State Machine Diagrams
• Compound States - A state machine diagram may include sub-machine
diagrams, as in the example below.
•The ∞ symbol indicates that details of the Check PIN
sub-machine are shown in a separate diagram.

149. 197
Composite States and Concurrency—
States within a State

150. State Machine Diagrams
• Concurrent Regions - A state may be divided into regions containing sub-
states that exist and execute concurrently. The example below shows that
within the state "Applying Brakes", the front and rear brakes will be
operating simultaneously and independently. Notice the use of fork and
join pseudo-states, rather than choice and merge pseudo-states. These
symbols are used to synchronize the concurrent threads.

151. State Machine Diagrams
• Choice Pseudo-State - A choice pseudo-state is shown as a diamond with
one transition arriving and two or more transitions leaving. The following
diagram shows that whichever state is arrived at, after the choice pseudo-
state, is dependent on the message format selected during execution of
the previous state.

152. State Machine Diagrams
• Junction Pseudo-State - Junction pseudo-states are used to chain together
multiple transitions. A single junction can have one or more incoming, and one
or more outgoing, transitions; a guard can be applied to each transition.
Junctions are semantic-free. A junction which splits an incoming transition into
multiple outgoing transitions realizes a static conditional branch, as opposed
to a choice pseudo-state which realizes a dynamic conditional branch.

153. 202
Rules for Developing State Machine
Diagram
• Review domain class diagram, select important
ones, and list all state and exit conditions
• Begin building state machine diagram fragments
for each class
• Sequence fragments in correct order and review
for independent and concurrent paths
• Expand each transition with message event,
guard-condition, and action-expression
• Review and test each state machine diagram