Requirements Modeling
CIS 375
Bruce R. Maxim
UM-Dearborn
1
H.I.P.O. Chart
2
H.I.P.O Chart
• Hierarchical Input-Process-Output
• Strength
– Shows functional relationships
• Weaknesses
– Does not show non-functional
requirements
– No checking mechanism, except for
customer review
3
Hierarchical Data Structures
4
Hierarchical Data Structures
• How does it different from object
hierarchy?
– Looks at data, not methods.
– No inputs/outputs.
– Only shows declaration of records, could
work for database model, but not for
implementation.
5
Analysis Model Objectives
• Describe what the customer requires.
• Establish a basis for the creation of a
software design.
• Devise a set of requirements that can
be validated once the software is built.
6
Structured Analysis - 1
• Analysis products must be highly
maintainable, especially the software
requirements specification.
• Problems of size must be dealt with using an
effective method of partitioning.
• Graphics should be used whenever possible.
• Differentiate between the logical (essential)
and physical (implementation) considerations.
7
Structured Analysis - 2
• Find something to help with
requirements partitioning and document
the partitioning before specification.
• Devise a way to track and evaluate user
interfaces.
• Devise tools that describe logic and
policy better than narrative text
8
Analysis Model Elements - 1
• Data dictionary
– contains the descriptions of all data objects
consumed or produced by the software
• Entity relationship diagram (ERD)
– depicts relationships between data objects
• Data flow diagram (DFD)
– provides an indication of how data are transformed
as they move through the system; also depicts
functions that transform the data flow
– a function is represented in a DFD using a process
specification or PSPEC
9
Analysis Model Elements - 2
• State transition diagram (STD)
– indicates how the system behaves as a
consequence of external events
– states are used to represent behavior
modes
– arcs are labeled with the events triggering
the transitions from one state to another
– control information is contained in control
specification or CSPEC
10
Data Dictionary Entries - 1
• Name
– primary name for each data or control item, data
store, or external entity
• Alias
– alternate names for each data object
• Where-used/how-used
– listing of processes that use the data or control
item and how it is used
•
•
•
•
input to process
output from process
as a store
as an external entity
11
Data Dictionary Entries - 2
• Content description
– notation for representing content
• Supplementary information
– other data type information, preset values,
restrictions, limitations, etc.
12
Entity-Relationship Diagrams
13
Data Modeling Elements
(ERD)
• Data object
– any person, organization, device, or software
product that produces or consumes information
• Attributes
– name a data object instance, describe its
characteristics, or make reference to another data
object
• Relationships
– indicate the manner in which data objects are
connected to one another
14
Cardinality and Modality
(ERD)
• Cardinality
– in data modeling, cardinality specifies how
the number of occurrences of one object
are related to the number of occurrences of
another object (1:1, 1:N, M:N)
• Modality
– zero (0) for an optional object relationship
– one (1) for a mandatory relationship
15
Creating Entity-Relationship
Diagrams - 1
• Customer asked to list "things" that
application addresses
• These things evolve into input objects,
output objects, and external entities
• Analyst and customer define
connections between the objects
• One or more object-relationship pairs is
created for each connection
16
Creating Entity-Relationship
Diagrams - 2
• Cardinality and modality are determined
for an object-relationship pair
• Attributes of each entity are defined
• ERD is reviewed and refined
17
Normalization Rules
• Given instance of an object has one value for
an attribute.
• Attributes represent elementary items.
• When more than one attribute is used to
identify an object, make sure they describe
the same "key".
• All non-ID attributes represent the same
characteristics of instance named by key.
18
Dataflow Diagram
Rectangle = information producer or consumer
Oval = software element that transforms info
Arrow = data item
information repository (not shown)
19
Functional Modeling DFD - 1
• Shows the relationships among
–
–
–
–
external entities
process or transforms
data items
data stores
• DFD's cannot show procedural detail like
conditionals or loops
• DFD’s only show the flow of data through the
software system
20
Functional Modeling DFD - 2
• Refinement from one DFD level to the next
should follow approximately a 1:5 ratio
• This ratio will reduce as the refinement
proceeds
• To model real-time systems, structured
analysis notation must be available for time
continuous data and event processing
21
Creating DFD - 1
• Level 0 data flow diagram should depict the system
as a single bubble
• Primary input and output should be carefully noted
• Refinement should begin by consolidating (for
representation at the next level):
– candidate processes
– data objects
– data stores to be represented at the next level
• Label all arrows with meaningful names
22
Creating DFD - 2
• Information flow must be maintained from one
level to level
• Refine one bubble at a time
• Write PSPEC for each bubble in the final DFD
– "mini-spec" written using English or another
natural language or a program design language
23
DFD Refinement
24
 DFD/CFD Level 0 - Part Number Analysis (PNA) System
WKConnectors.XLS
Spreadsheet
Information
CSV File Creation
(WKConnectors.CSV)
Display Monitor
WKConnectors
Delimited Text
Information
Report Results
Table1.CSV
Table1 Delimited
Text Information
Table2 Delimited
Text Information
PART NUMBER
ANALYSIS (PNA) Tool
Report Results
File
Report Results
Table2.CSV
- Command
- PN data
Printer
User
25
 DFD/CFD Level 1 - Part Number Analysis (PNA) Tool
WKConnectors
Delimited Text
information
Report Results
Validation Results
Table1
Delimited Text
information
Report Results
Validate Data
Process Report
Print / Save
Data
Report Results
Table2
Delimited Text
information
- Command
- PN data
26
 DFD/CFD Level 2 - Validate Data
tbl_Classification
WKConnectors
Delimited Text
information
Make
tbl_createdWKConn
- Command
- PN data
Relevant WKConnector
Records
Make WKConn
Category
Reference ID
Validation
Results
tbl_createdWKConn
WKConn field
data
- Component
Remarks
- Category ID
tbl_createdT1
T1 Field data
Relevant T1
Record(s)
Table1 Delimited Text
information
Analyze/Classify Data
Criteria:
- dbs
- strCriteria
- strOrigPN
Print / Save
Data
Criteria:
- dbs
- strOrigPN
T2 Field data
Make tbl_createdT1
tbl_createdT2
Table2 Delimited Text
information
Make tbl_createdT2
Relevant T2 Record(s)
27
 DFD/CFD Level 3 - Make tbl_createdT1
Table1
Delimited Text
information
Criteria:
- dbs
- strCriteria
- strOrigPN
qry_Table1UniquePN
Recreate tbl_createdT1
Table1
Query
Results
Relevant T1
Record(s)
 DFD/CFD Level 3 - Make tbl_createdT2
Criteria:
- dbs
- strOrigPN
Table2
Delimited Text
information
Recreate tbl_createdT2
qry_Table2PrelimUnique
Table2
Query
Results
Relevant
T2Record(s)
28
Creating Control Flow Diagrams
• Begin by stripping all the data flow arrows
form the DFD
• Events (solid arrows) and control items
(dashed arrows) are added to the diagram
• Create CSPEC for each bubble in final CFD
– contains an STD (state transition diagram) that
serves as a sequential specification of the
bubble’s behavior
29
State Transition Diagram
30
STD Elements
•
•
•
•
•
Set of machine states S
S0  start state
F  S set of final state(s)
I
set of input symbols
Transition function
 (Sj , Ij)  Si
31
Behavioral Modeling (STD)
• State transition diagrams represent the
system states and events that trigger state
transitions
• STD's indicate actions (e.g. process
activation) taken as a consequence of a
particular event
• A state is any observable mode of behavior
• Control flow diagrams (CFD) can also be
used for behavioral modeling
32
Decision Table
Rules
Condition
1
2
Actions
1
2
33
Condition
N not numeric
T
F
F
F
N <= 1
-
T
F
F
N legal
-
-
T
F
N prime
-
-
T
F
Action
Print “N prime”
X
Print “N not prime”
Print error message
X
X
X
Print “Good bye”
Input new value for N
Stop
X
X
X
X
X
X
34
Event Table
Mode
Event1
Event2
Event3
Event4
Presentation
Graphics
Action
1
Action8
O
X
Architecture
Drawing
X
A2 then
A3
A5 & A6
O
Programming
O
A4
A1, A2 & A3
A7
X = no action defined for event
O = no state change and no action
35
Petri Nets
• Sequential Process
• F(StateA, Event1,
Event2, Event3) 
StateS
• F(StateA, Event1,
Event2, Event3) 
(StateS1,StateS2)
36
SADT
• Structured Analysis and Design Technique
• Phases:
– SA
• Activity diagrams combined to for activity network
• Data diagrams combined to form data network
– DT
•
•
•
•
Uses dataflow diagrams
Data dictionary
Pseudo algorithm representations for control information
Relational tables to indicate data element relations
37
SA – Activity Diagram
Control

 Outputs
Inputs 

Mechanism
38
SA – Data Diagram
Control

Generating 
Resulting
Activity
Activity

Storage Device
39