Requirements Analysis -Conceptual Modeling
Class Notes
Requirements Engineering Activity
Model
Requirements Management
Requirements
Elicitation
Existing System Information
Stakeholder Needs
Organizational Standards
Technical Standards
Regulations
Domain Information
Goals
Requirements
Analysis
Requirements
Specification
Requirements
Validation
Validated
Requirements
Specification
Requirements Analysis

The process of analyzing requirements to:
•
•
•
•
•

Includes the following main activities:
•
•
•

Detect and resolve requirements problems
Decompose (elaborate) requirements
Discover system boundary and how system must interact with its
environment
Discover interactions and overlaps between requirements
Gain a better understanding of the problem
Requirements classification
Conceptual modeling
Requirements negotiation
Quality of analysis directly affects product quality
•
More rigorous analysis leads to better software quality
Typical Requirements Problems









Ambiguous requirements
Conflicting requirements
Design dependent requirements
Infeasible requirements (technical, operational, economic)
Incomplete requirements
Inconsistent requirements
Non-singularized requirements
Non-testable requirements
Unnecessary requirements
Background on Modeling

Modeling is a proven and well-accepted
engineering technique
•
•
Architectural models (blueprints) in civil engineering
Mathematical models for analysis of physical properties
• Effects of wind on buildings
• Bandwidth analysis
•

Economic models
“A model is a simplification of reality created in
order to better understand the system being
created” [Grady Booch]
Conceptual Modeling

Development of models to aid understanding of
requirements
•
•
•

A model is an abstract representation of system whose requirements
are being analyzed
Model can be used to answer questions about system
Not concerned with initiating design of the solution
In nearly all cases, useful to start by building model
of system boundary
•
•
Crucial to understanding system’s context in its operational
environment
Crucial to identify system’s interfaces to external environment
Booch’s Four Principles of Modeling

Choice of models has profound influence on how
problem is attacked and how solution is shaped
•



Choose your models well
Every model may be expressed at different levels
of precision
Best models are connected to reality
No single model is sufficient
•
Every nontrivial system is best approached through a small set
of nearly independent models
Advantages of Conceptual Modeling (1
of 2)




Facilitates reasoning about system in an organized and
precise manner
Allows reviewer’s to validate that modeler’s
understanding is correct
Enhances communication between stakeholders and
developers
Provides basis for predicting important system
characteristics
•
•
•
Development schedule
Performance
Processing sequence
Advantages of Conceptual Modeling (2
of 2)

Reduces amount of complexity that must be
understood at one time
•
•
•
•

Consider system from different viewpoints
Consider different parts of system
Understand interactions and relationships between different
parts of system
Create a composite model by relating viewpoints
Reduces risk by exposing requirements problems
early in life-cycle
Requirements Specification
•
Goal
• To provide a representation of the software for the customer’s
review and approval
•
•
•
Developed as a joint effort between the developer and the
customer
Serve as basis for review for both customer and developer
Culmination of requirements analysis
Specification Principles
•
•
•
•
Separate functionality from implementation
Process-oriented systems specification language is required
Specification must encompass the system of which the software
is a component
Specification must include the environment in which the system
operates
Specification Principles (continued)
•
•
•
•
System specification must be a cognitive model
Specification must be operational
System specification must be tolerant of incompleteness and
augmentable
Specification must be localized and loosely coupled
Software Requirements Specification (SRS)


Includes Requirements Definition & Specification
Principles: [Heninger 80]
•
•
•
•
•
•
Should specify external system behavior
Should specify implementation constraints
Should by easy to change
Should serve as reference tool for maintenance
Should record forethought about system lifecycle
Should characterize acceptable responses to undesired events
Software Requirements Specification (SRS)
• Introduction
• System Models



•
•
•
•
•
•
Information Model
Functional Model
Behavioral Model
Functional Requirements Definition
Non-functional Requirements Definition
System Evolution
Requirement Specification
Validation Criteria
Bibliography
• Appendix & Glossary
Requirements Analysis
•
Many types of analysis methods
• Structured Analysis
• Object-Oriented Analysis
•
Each method has techniques for representing
• Data
• Processing/Function
• Control/Behavior
•
Each technique/notation is used to model one or more types for
information
Analysis Methods

Viewpoint Oriented Analysis
•
•

Stakeholders perspectives
Conflict resolution
Method Based Analysis
•
•
Data-flow based analysis methods
Object-Oriented analysis methods
Analysis Models

Data processing model
• Data Flow Diagrams

Composition model
• Entity-Relationship Diagrams

Stimulus-response model
• State Transition Diagrams

Classification model
• Object Model

A reference point during product maintenance.
Classification of Specification Styles


Formal, informal and Semiformal Specifications
Operational and descriptive specifications
•
•
Operational specifications: desired behavior
Descriptive specifications: desired properties
Verification of Specifications



Dynamic analysis
Static analysis
Formalism and verification
• Simulation
• Prototype

Verify all three aspects:
• Functional
• Consistency
• completeness
Data Flow Diagram: Specifying
Functions of Information Systems

Features
• Describe systems as collections of functions that manipulate data
• Can be expressed by means of graphical notation
• Elements:
Input device symbol
Output device symbol
Function symbol
Data flow
Data store symbol
DFD Example
d
b
(a + b) * ( c + a * d)
+
a
*
*
c
+
DFD limitations


The semantics of the symbol is specified only by
the identifiers chosen by the user.
Control aspects are not defined by the model
A
B
E
D
F
C
DFD Limitations


The semantics of the symbol is specified only by
the identifiers chosen by the user.
Control aspects are not defined by the model
A
B
E
D
F
C
DFD Limitations


The semantics of the symbol is specified only by
the identifiers chosen by the user.
Control aspects are not defined by the model
A
B
E
D
F
C
Operational Specifications


Data Flow diagrams
UML Diagram for Specifying Behaviors
• Features
• Example
• Limitations


Finite State Machine: Describing Control Flow
Pretri Nets: Specifying Asynchronous Systems
Operational Specifications



Data Flow diagrams
UML Diagram for Specifying Behaviors
Finite State Machine: Describing Control Flow
•
•
•
•

Definiation
Features
Example
Limitations
Pretri Nets: Specifying Asynchronous Systems
Finite State Machines: Describing Control Flow

Definition
A finite automata is a 5-tuple (Q, , , q0, F), where
1. Q is a finite set called the states,
2.  is a finite set called the alphabet (inputs),
3.  : Q    Q is the transition function,
4.
q0  Q is the start state, and
5. F  Q is the set of accept states (final states).
Finite State Machines: Describing Control Flow
Features

•
•
•
Formal notation
Suitable for describing systems that can be in a finite set of
states and that can go from one state into another as a
consequence of some event, modeled by an input symbol.
Widely used: specification of control systems, compilation,
pattern matching, etc.
Finite State Machines: Describing Control Flow

Example
Push switch
Off
On
Push switch
Finite State Machines: Describing Control Flow

Example: Chemical plant
High-pressure alarm
High-temperature alarm
Off
On
Restart
Finite State Machines: Describing Control Flow

Example: Chemical plant
Pressure signal
Normal
Temperature signal
Temperature signal
Pressure
Recovery
Successful
Unsuccessful
recovery
recovery
Off
Successful
Unsuccessful
recovery
recovery
Temperature
Recovery
Pressure signal
Finite State Machines: Describing Control Flow
Limitations

•
Finite states: need assistance such as natural language or
accompanied by action descriptions, like:
Cooling_effort := k * (present_temperature – standard temperature)
•
Can’t describe concurrent, asynchronous systems.
consume
write
P2
P1
C2
C1
read
produce
write
write
empty
1
0
read
2
read
full
FSM: Describing Control Flow

Example continued: the Cartesian Product of the component state sets:
write
write
<0,p1,c1>
<2,p1,c1>
<1,p1,c1>
consume
consume
consume
Produce
Produce
Produce
<0,p2,c1>
<0,p1,c2>
<2,p1,c2>
<1,p1,c2>
read
read
Produce
<0,p2,c1>
<1,p2,c1>
read
Produce
Produce
read
write
consume
consume
consume
<0,p2,c2>
<1,p2,c2>
<2,p2,c2>
Finite State Machines: Describing Control Flow
Limitations:

•
•
The cardinality of the state space grows dramatically: if we have
n subsystems, each with ki states, the resulting system has a
cardinality of k1*k2*…Kn
FSM are essentially a synchronous model: at any time, a global
state of the system must be defined and a single transition must
occur.
Operational Specifications




Data Flow diagrams
UML Diagram for Specifying Behaviors
Finite State Machine: Describing Control Flow
Pretri Nets: Specifying Asynchronous Systems
•
•
•
•
Definition
Example
Features
Limitations
Petri Nets: Specifying Asynchronous
System

Definition
A Petri Net is a quadruple (P, T, F, W), where
1. P is the finite set of places;
2. T is a finite set of transitions;
3. P  T  ;
4. F  { P  T}  { T  P} is the flow relation; and
5. W: F N – {0} is the weight function, which associates a
nonzero natural value to each element of F. If no weight value is
explicitly associated with a flow element, the default value 1 is
assumed for the function
Petri Nets: Specifying Asynchronous
System

Example:
p2 is the input place of transition write
Transition
p1 is the output place of transition write
write
Produce is the enabled, so transition
produce may fire
Place
p2
p1
Token
produce
Petri Nets: Specifying Asynchronous
System

Example:
p2 is the input place of transition write
Transition
p1 is the output place of transition write
write
Produce is the enabled, so transition
produce may fire
Place
p2
p1
Token
2
produce
Petri Nets: Specifying Asynchronous
System

Example: After produce fired
p2 is the input place of transition write
Transition
p1 is the output place of transition write
write
Now, write is the enabled, so transition
write may fire
Place
p2
p1
2
produce
Token
PN: Specifying Asynchronous System

Example: producer and consumer
write
consume
p2
p1
c2
c1
produce
read
read
read
2
1
0
write
write
PN: Specifying Asynchronous System


Example continued:
producer and consumer:
consume
c2
c1
read
read
Now the system is at the state <0,
0
p1, c1>
1
write
p1
2
write
p2
produce
PN: Specifying Asynchronous System


Example continued:
producer and consumer:
consume
c2
c1
read
read
Now the system is at the state <0,
0
p2, c1>
1
write
p1
2
write
p2
produce
PN: Specifying Asynchronous System


Example continued:
producer and consumer:
consume
c2
c1
read
read
Now the system is at the state <1,
0
p2, c1>
1
write
p1
2
write
p2
produce
Petri Nets: Specifying Asynchronous
System
Features

Good at describing concurrent and asynchronous system
Limitations

•
•
•
Tokens are anonymous
Can’t specify a selection policy
Can’t resolve deadlock or starving…
Descriptive Specifications




5.6.1 Entity Relationship (ER) Diagrams
A semiformal notation
5.6.2 Logic Specification
5.6.3 Algebraic Specifications
Entity Relationship Diagrams
NAME
Entities:
a collection of items that
share common properties
AGE
STUDENT
SEX
Relations:
ENROLLED_IN
A set of pairs <a, b>, where
a is an element of
STUDENT and b is an
element of CLASS
Attribute:
CLASS
SUBJECT
COURSE_ID
MAX_ENROLLMENT
Entity Relationship Diagrams
Relation Attributes:
A
R
B
A R B is one to one
A
R
B
A R B is one to many
A
R
B
A R B is many to one
A
R
B
A R B is many to many
Unified Modeling Language



A general-purpose visual modeling language that
is used to specify, visualize, construct and
document the artifacts of a software system.
Static Structure (Descriptive)
Dynamic behavior (Operational)
Unified Modeling Language

Static Structure (Descriptive)
• Static view: class diagram
• User Case View
• Physical Views
• Implementation view
• Deployment view

Dynamic behavior (Operational)
• Interaction view
• Sequence diagram
• Collaboration diagram
• State machine view
• Activity view
Unified Modeling Language

Static Structure (Operational)
• Static View: class diagram
• User Case View
• Physical Views
• Implementation view
• Deployment view

Dynamic behavior (Descriptive)
• Interaction view
• Sequence diagram
• Collaboration diagram
• State machine view
• Activity view
Class
Customer
Name: String
Phone: String
Class Diagram:
attributes
Add(name,phone)
class-scope operation
1
association
*
Reservation
Date: Date
Show
generalization
Name: String
Subscription Series
1
Individual
Reservation
Series: integer
multiplicities
0..1
0..1
3..6
Ticket
1..*
1
Performance
Available: Boolean
Sell (c. Customer)
Exchange()
Seat: Sting
*
1
qualifier
Date: Date
Time: TimeOfDay
Use Case Diagram:
system
actor
buy
tickets
<<include>>
relationship
Clerk
buy
subscription
<<include>>
Kiosk
make
charges
Credit card service
Use case
survey
sales
Supervisor
Unified Modeling Language

Static Structure (Operational)
• Static View: class diagram
• User Case View
• Physical Views
• Implementation view
• Deployment view

Dynamic behavior (Descriptive)
• Interaction view
• Sequence diagram
• Collaboration diagram
• State machine view
• Activity view
Sequence Diagram
Active object
credit card service
box office
Kiosk
Request (count, performance)
Show availability (seat-list)
lifeline (active)
Select(seats)
Demand payment(cost)
Insert card(card number)
message
charge(card number,cost))
authorized
Print tickets (performance,
seats)
Eject card
Collaboration
Diagram:
active object
Kiosk
1:request (count, performance)
link
4: offer(seat-list)
5:buy(seats)
8:confirm (seats, cost)
ticketseller
3: seat-list := lock(count) 
6: claim (seats) 
7: unlock(seat-list) 
<<local>>db
passive object
Db: performanceDB
transient link
message
2: db := findDB(performance)
performanceGuide
multi object
Db: performanceDB
State chart Diagram
Assign to subscription
Initial state
Time out
Available
lock
state
Locked
buy
Sold
unlock
transition
exchange
Trigger event
Activity Diagram
Pick show
activity
schedule show
fork
publicize show
Buy scripts
and music
Sell tickets
Hire
artists
Build
sets
Design
lighting
Completion
transition
rehearse
Dress rehearsal
join
perform
Make
costumes
Key Points





No ideal requirements analysis method
System models can be considerably enriched by
combining different techniques
Data-flow model is based on the notion that systems can
be modelled as a set of interacting functions
The object-oriented approach is based on the notion that
systems can be modelled as a set of interacting objects
Formal methods are based on mathematical principles and
are intended to achieve a high degree of confidence that a
system will conform to its specifications