Why requirement analysis is important ?

▪ If requirement analysis phase is not completed properly then there might be

inconsistencies in the final product.
▪ During requirement gathering, client is not able to provide more details or not
sure exactly what is required.
▪ Basic reason is, client comes from a non-technical background and not familiar
with technical jargons so they find it difficult to share the exact expectations.
▪ If requirements are not proper or not completely covered then there is no point
of SRS Doc. This will cause a loop of rework in case of development team.
▪ Timelines are not achievable. Client is always in a hurry to see the final product
so they directly or indirectly plan unrealistic timelines and finally receive a half-
baked product.
▪ When the clients receive their final product, by then, expectations changes and
they want to introduce more new features which were not part of earlier
documents.
▪ This behaviour can be expected during the project also which pushes the team
back on their schedule.
▪ Improper Documentation is another culprit which enhances the possibility of
unachievable tasks.
 How can it be improved?
▪ Provide visual examples to clients, if client is feeling difficulty in explaining the exact
requirement.
▪ Clearly state the drawbacks of limited timelines, if not achievable.
▪ Buffer time should be documented for each activity in case any variation in requirements
are expected.
▪ Have a clearly defined process for receiving, analysing and incorporating change requests,
and make your customer aware of his/her entry point into this process.
▪ Spend sufficient time to understand the objectives, deliverables and scope of the project.
▪ Document all the assumptions and let client be aware of each assumption.
▪ Clearly state all the functional requirement and non-functional requirement.
▪ Requirements Analysis is a phase which should not be underestimated as it will lay the
foundation of the project.
Analysis Objectives

 Identify customer’s needs.

 Evaluate system for feasibility.
 Technical
 Economical
 Perform economic and technical analysis.
 Allocate functions to system elements.
 Establish schedule and constraints.
 Create system definitions.
 Provides the first technical representation of a system

3
 Analysis
 Developers formalize the requirements produced during
requirements elicitation.
Examine in more detail boundary conditions and
exceptional cases.
 Analysis examines requirements from the perspective of
the classes and objects found in the vocabulary of the
problem domain.
 we will discuss the analysis activities like identification of
objects, their behavior, their relationships, their
classification and their organization.
 Analysis results in a model of the system that aims to be
correct, complete, consistent and unambiguous.
 Out put of the analysis is Software Requirements
Specifications document (SRS document)
 Analysis Model
 It consists of 3 individual models
 Functional model
 Analysis model
 Dynamic model
 Functional Model: Represents use cases and scenarios
 Analysis Model: Represents class and object diagrams
 Dynamic Model: Represents state starts and sequence
diagrams
 In the previous lectures, we described how to elicit
requirements from the users and describe them as use cases and
scenarios.
 Present lecture, describes how to refine the functional model
and derive the object and dynamic model
 This leads a more precise and complete specifications that are
added to the analysis model.
 How do you find classes?
 we have already established the following sources:
 Application domain analysis: Talk to client to identify abstractions
 Application of general world knowledge and intuition
 Scenarios
 Natural language formulation of a concrete usage of the system
 Use Cases
 Natural language formulation of the functions of the system

 Today, we show how to identify classes from dynamic models

 Actions and activities in state chart diagrams are candidates for public
operations in classes
 Activity lines in sequence diagrams are also candidates for objects
 Dynamic Modeling with UML

 Diagrams for dynamic modeling

 Interaction diagrams describe the dynamic behavior between objects
 Statecharts describe the dynamic behavior of a single object
 Interaction diagrams
 Sequence Diagram:
 Dynamic behavior of a set of objects arranged in time sequence.
 Good for real-time specifications and complex scenarios
 Collaboration Diagram :
 Shows the relationship among objects. Does not show time
 State Chart Diagram:
 A state machine that describes the response of an object of a given class
to the receipt of outside stimuli (Events).
 Activity Diagram: A special type of state chart diagram, where all
states are action states (Moore Automaton)
 Dynamic Modeling

 Definition of dynamic model:

 A collection of multiple state chart diagrams, one state chart diagram
for each class with important dynamic behavior.
 Purpose:
 Detect and supply methods for the object model
 How do we do this?
 Start with use case or scenario
 Model, interaction between objects => sequence diagram
 Model, dynamic behavior of a single object => statechart diagram
 Statechart Diagram

 Graph representing finite state machine

 Network of states and transitions
 Good for modeling reactive systems

push switch

On Off

Push Switch push switch

 Elements of Statechart

Initial State Final State

Transition

Idle Running

State
 State
 Condition or situation in the life of a system (or object)
during which it:
 Satisfies some condition,
 Performs some activity, or
 Waits for some events.
 Set of values of properties that affect the behavior of the
system (or object).
 Determines response to an event,
 Thus, different states may produce different responses to the same
event
 Transition

 Relationship between two states indicating that a

system (or object) in the first state will:
 Perform certain actions and
 Enter the second state when specified event occurs and
specified condition is satisfied.
 Consists of:
 Source and target states
 Optional event, guard condition, and action

Event [Condition] / Action

Source Target
 Door

state Opened
Door

transition

close door
open door

transition
condition
Closed
Door Just for the sake of fun!
entry action
 What is an Event?
 Something that happens at a point in time
 Relation of events to each other:
 Causally related: Before, after,
 Causally unrelated: concurrent
 An event sends information from one object to another
 Events can be grouped in event classes with a hierarchical
structure.

Substate1 substate2

Before After
substate3 substate4
 Start with Flow of Events from Use Case
Dial a Number

 Flow of events from “Dial a Number” Use case:

 Caller lifts receiver
 Dial tone begins
 Caller dials
 Phone rings at callee premises
 Callee lifts receiver
 Ringing stops
 Callee answers phone
 ....
 Example

dial digit(n)
[incomplete]

connected Ringing ……
Dialing Connecting
dial digit(n)
dial digit(n) [valid] / connect
[invalid]
busy
Busy ……
Invalid
 Sequence Diagram

 From the flow of events in the use case or scenario proceed to

the sequence diagram
 A sequence diagram is a graphical description of objects
participating in a use case or scenario using a DAG (direct
acyclic graph) notation
 Relation to object identification:
 Objects/classes have already been identified during object modeling
 Objects are identified as a result of dynamic modeling
 Heuristic:
 A event always has a sender /caller and a receiver.
 The representation of the event is sometimes called a message
 Find them for each event => These are the objects participating in the
use case
 Sequence Diagram

 Describes a sequence of method calls among objects

 Highlights the time ordering of method calls

Consist of
•Class roles – roles of objects play in the interaction (caller, Phone Net, Receiver, etc)
•Lifelines- represent existence of an object over a period of time
•Activations- time during which an object performs operation
• Messages- represent communication between objects
Sequence Diagram (Dial a Number)
ReportEmergency
 Generalization hierarchy
(UML class diagram)

The root of the hierarchy represents the most general concept, whereas the
leaves nodes represent the most specialized concepts.

Incident

Low Priority Emergency Disaster

Child on Tree Earth Quake Chemical Leak

Traffic Accident Building Fire

 Sequence diagram for the ReportEmergency use case
initiation from the FieldOfficerStation side 1/3

Report Manage
EmergencyButton EmergencyControl
FieldOfficer

press() «create»
ReportEmergency
Control

«create» ReportEmergency
Form

fillContents()

submit()
submitReport()
«create»
Emergency
Report

submitReportToDispatcher()
«destroy»
 Sequence diagram for the ReportEmergency use case
DispatcherStation 2/3

Manage
EmergencyControl Dispatcher
submitReportToDispatcher() «create»
IncidentForm

createIncident()

«create»
Incident

submit()

«create»
Acknowledgment
«destroy»
 Sequence diagram for the ReportEmergency use case
acknowledgment on the FieldOfficerStation 3/3

Manage ReportEmergency
FieldOfficer EmergencyControl Control

acknowledgeReport()
«create» Acknowledgment
Notice
dismiss()

endReportTransaction()
«destroy»
«destroy»
Association between the EmergencyReport and
the FieldOfficer classes

* writes 1
Field Officer Emergency Report

author document
 Eliminating redundant association
The receipt of an EmergencyReport triggers the creation of an
Incident by a Dispatcher.

Given that the EmergencyReport has an association with the

FieldOfficer that wrote it, it is not necessary to keep an
association between FieldOfficer and Incident.

author document
* writes 1
FieldOfficer EmergencyReport
1 1
reports triggers
Incident
1 1
Attributes of the EmergencyReport class

EmergencyReport
emergencyType:{fire,traffic,other}
location:String
description:String