Requirements Modeling

CIS 375
Bruce R. Maxim
UM-Dearborn
1

H.I.P.O. Chart

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

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.

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.

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
DFDs 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
Print / Save
Data

Criteria:
- dbs
- strCriteria
- strOrigPN
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
bubbles 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

Actions

33

Condition
N not numeric

N <= 1

N legal

N prime

Action
Print N prime

Print N not prime

Print error message

X
X

Print Good bye

Input new value for N
Stop

34

Event Table
Mode

Event1

Event2

Event3

Event4

Presentation
Graphics

Action
1

Action8

Architecture
Drawing

A2 then A3

A5 & A6

Programming

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

Inputs

Outputs

Mechanism

38

SA Data Diagram
Control

Resulting

Generating
Activity

Activity

Storage Device

39