1. Requirements Modeling
CIS 375
Bruce R. Maxim
UM-Dearborn

2. H.I.P.O. Chart

3. H.I.P.O Chart Hierarchical Input-Process-Output Strength Weaknesses
Shows functional relationships
Weaknesses
Does not show non-functional requirements
No checking mechanism, except for customer review

4. Hierarchical Data Structures

5. 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.

6. 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.

7. 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.

8. 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

9. 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

10. 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

11. 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

12. Data Dictionary Entries - 2
Content description
notation for representing content
Supplementary information
other data type information, preset values, restrictions, limitations, etc.

13. Entity-Relationship Diagrams

14. 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

15. Cardinality and Modality (ERD)
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

16. 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

17. 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

18. 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.

19. Dataflow Diagram Rectangle = information producer or consumer
Oval = software element that transforms info
Arrow = data item
information repository (not shown)

20. 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

21. 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

22. 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

23. 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

24. DFD Refinement

25. 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
PART NUMBER ANALYSIS (PNA) Tool
File
Table1 Delimited Text Information
Report Results
Table2 Delimited Text Information
Table2.CSV
Report Results
Printer
- Command
- PN data
User

26. DFD/CFD Level 1 - Part Number Analysis (PNA) Tool
WKConnectors Delimited Text
information
Report Results
Validation Results
Validate Data
Table1 Delimited Text
information
Process Report
Report Results
Print / Save
Data
Report Results
Table2 Delimited Text
information
- Command
- PN data

27. Analyze/Classify Data
DFD/CFD Level 2 - Validate Data
Make
tbl_createdWKConn
tbl_Classification
WKConnectors Delimited Text
information
Relevant WKConnector
Records
Category
Reference ID
Validation Results
- Command
- PN data
Make WKConn
tbl_createdWKConn
WKConn field data
Component Remarks
Category ID
tbl_createdT1
Analyze/Classify Data
T1 Field data
Relevant T1 Record(s)
Criteria:
- dbs
- strCriteria
- strOrigPN
Print / Save
Data
Criteria:
- dbs
- strOrigPN
Make tbl_createdT1
Table1 Delimited Text
information
T2 Field data
Make tbl_createdT2
tbl_createdT2
Table2 Delimited Text
information
Relevant T2 Record(s)

28. DFD/CFD Level 3 - Make tbl_createdT1
Criteria:
- dbs
- strCriteria
- strOrigPN
qry_Table1UniquePN
Recreate tbl_createdT1
Table1 Delimited Text
information
Relevant T1 Record(s)
Table1 Query Results
DFD/CFD Level 3 - Make tbl_createdT2
Criteria:
- dbs
- strOrigPN
qry_Table2PrelimUnique
Recreate tbl_createdT2
Table2 Delimited Text
information
Table2 Query Results
Relevant
T2Record(s)

29. 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

30. State Transition Diagram

31. 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

32. 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

33. Decision Table
Rules
Condition 1 2
Actions

34. Condition
N not numeric T F
N <= 1 -
N legal
N prime
Action
Print “N prime” X
Print “N not prime”
Print error message
Print “Good bye”
Input new value for N
Stop

35. Presentation Graphics
Event Table
Mode
Event1
Event2
Event3
Event4
Presentation Graphics
Action1
Action8 O X
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

36. Petri Nets Sequential Process
F(StateA, Event1, Event2, Event3)  StateS
F(StateA, Event1, Event2, Event3)  (StateS1,StateS2)

37. SADT Structured Analysis and Design Technique Phases: SA DT
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

38. SA – Activity Diagram
Control 
Inputs 
 Outputs 
Mechanism

39. SA – Data Diagram Control  Generating  Activity Resulting Activity 
Storage Device