1. The Traditional Approach to Requirements

2. Overview
What the system does what an event occurs: activities and interactions
Traditional structured approach to representing activities and interactions
Diagrams and other models of the traditional approach
RMO customer support system example shows how each model is related
How traditional and IE approaches and models can be used together to describe system

3. Traditional and Object-Oriented Views of Activities

4. Requirements Models for the Traditional and OO Approaches

5. Data Flow Diagrams
Graphical system model that shows all main requirements for an IS in one diagram
External entity
Data flow
Processes
Data storage
Easy to read and understand with minimal training

6. Data Flow Diagram Symbols

7. DFD Fragment from the RMO Case

8. DFD Integrates Event Table and ERD

9. DFD and Levels of Abstraction
Data flow diagrams (DFDs) are decomposed into additional diagrams to provide multiple levels of detail
Higher level diagrams provide general views of system
Lower level diagrams provide detailed views of system
Differing views are called levels of abstraction

10. Layers of DFD Abstraction

11. Context Diagrams DFD that summarizes all processing activity
Highest level (most abstract) view of system
Shows system boundaries
System scope is represented by a single process, external agents, and all data flows into and out of the system
Doesn’t show data stores because they are considered to be within the system scope

12. DFD Fragments Created for each event in the event table
Represents system response to one event within a single process symbol
Self contained model
Focuses attention on single part of system
Shows only data stores required to respond to events

13. DFD Fragments for Course Registration System

14. Event-Partitioned System Model
DFD to model system requirements using single process for each event in system or subsystem
Decomposition of the context level diagram
Sometimes called diagram 0
Used primarily as a presentation tool
Decomposed into more detailed DFD fragments

15. Combining DFD Fragments

16. Context Diagram for RMO Customer Support System

17. RMO Subsystems and Events

18. Context Diagram for RMO Order-Entry Subsystem

19. DFD Fragments for RMO Order-Entry System

20. Decomposing DFD Fragments
Sometimes DFD fragments need to be explored in more detail
Broken into subprocesses with additional detail
DFD numbering scheme:
Does not equate to subprocess execution sequence
It is just a way for analyst to divide up work

21. Order-Entry Subsystem

22. Physical and Logical DFDs
Logical model
Does not tell how system is implemented
Physical model
Describes assumptions about implementation technology
Developed in last stages of analysis or in early design

23. Detailed Diagram for Create New Order

24. Physical DFD for scheduling courses

25. List of Activities

26. Stock Log

27. Current Logical System and New Logical System

28. Evaluating DFD Quality
Readable
Internally consistent
Accurately represents system requirements
Reduces information overload: Rule of 7 +/- 2
Single DFD should have not more than 7 +/-2 processes
No more than 7 +/- 2 data flows should enter or leave a process or data store on a single DFD
Minimizes required number of interfaces

29. Data Flow Consistency Problems
Differences in data flow content between a process and its process decomposition
Data outflows without corresponding inflows
Data inflows without corresponding outflows
Results in unbalanced DFDs

30. Consistency Rules All data that flows into a process must:
Flow out of the process or
Be used to generate data that flow out of the process
All data that flows out of a process must:
Have flowed into the process or
Have been generated from data that flowed into the process

31. Unnecessary Data Input: Black Hole

32. Process with Impossible Data Output: Miracle

33. Process with Unnecessary Data Input

34. Process with Impossible Data Output

35. Incorrect and Correct Ways to Draw DFD

36. Incorrect and Correct Ways to Draw DFD

37. Incorrect and Correct Ways to Draw DFD

38. Balancing DFDs
When decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decomposition
This is called balancing

39. Unbalanced Set Of Data Flow Diagrams

40. Balancing DFDs
We can split a data flow into separate data flows on a lower level diagram

41. Documentation of DFD Components
Lowest level processes need to be described in detail
Data flow contents need to be described
Data stores need to be described in terms of data elements
Each data element needs to be described
Various options for process definition exist

42. Data Flow Definitions
Textual description of data flow’s content and internal structure
Often coincide with attributes of data entities included in ERD

43. Data Flow Definition- Example
New-Order = Customer-Name + Customer-Address + Credit-Card-Information + {Item-Number + Quantity) N 1

44. Data Store Definitions
A data store on the DFD represents a data entity on the ERD

45. Data Element Definitions
Data type description
e.g. string, integer, floating point, Boolean
Sometimes very specific
Length of element
Maximum and minimum values
Data dictionary – repository for definitions of data flows, data stores, and data elements

46. A Data Structure for a Data Flow
ORDER=
ORDER NUMBER +
ORDER DATE+
[ PERSONAL CUSTOMER NUMBER,
CORPORATE ACCOUNT NUMBER]+
SHIPPING ADDRESS=ADDRESS+
(BILLING ADDRESS=ADDRESS)+
1 {PRODUCT NUMBER+
PRODUCT DESCRIPTION+
QUANTITY ORDERED+
PRODUCT PRICE+
PRODUCT PRICE SOURCE+
EXTENDED PRICE } N+
SUM OF EXTENDED PRICES+
PREPAID AMOUNT+
(CREDIT CARD NUMBER+EXPIRATION DATE)
(QUOTE NUMBER)
ADDRESS=
(POST OFFICE BOX NUMBER)+
STREET ADDRESS+
CITY+
[STATE, MUNICIPALITY]+
(COUNTRY)+
POSTAL CODE
ENGLISH ENTERPRETATION
An instance of ORDER consists of:
ORDER NUMBER and
ORDER DATE and
Either PERSONAL CUSTOMER NUMBER
or CORPORATE ACCOUNT NUMBER
and SHIPPING ADDRESS (which is equivalent to ADDRESS)
and optionally: BILLING ADDRESS (which is equivalent to ADDRESS)
and one or more instances of:
PRODUCT NUMBER and
PRODUCT DESCRIPTION and
QUANTITY ORDERED and
PRODUCT PRICE and
PRODUCT PRICE SOURCE and
EXTENDED PRICE
and SUM OF EXTENDED PRICES and
PREPAID AMOUNT and
optionally: both CREDIT CARD NUMBER and EXPIRATION DATE
An instance of ADDRESS consists of:
optionally: POST OFFICE BOX NUMBER and
STREET ADDRESS and
CITY and
Either STATE or MUNICIPALITY
and optionally: COUNTRY
and POSTAL CODE

47. Data Flow Diagram and Process Specifications

48. Goal of Creating Process Specifications
Reduce process ambiguity.
Obtain a precise description of what is accomplished.
Validate the system design, including data flow diagrams and the data dictionary.

49. Process Specification Format
Process specifications link the process to the DFD and the data dictionary.
The following information should be entered:
The process number, which must match the process ID on the data flow diagram.
This allows an analyst to work or review any process and easily locate the data flow diagram containing the process.
The process name, the same as displays within the process symbol on the DFD.
A brief description of what the process accomplishes.
A list of input and output data flow, using the names found on the data flow diagram.
Data names used in the formulae or logic should match the data dictionary, for consistency and good communication.
A description of the process logic.

50. Process Specification Form

51. Structured English Method of writing process specifications
Combines structured programming techniques with narrative English
Well suited to lengthy sequential processes or simple control logic (single loop or if-then-else)
Ill-suited for complex decision logic or few (or no) sequential processing steps

52. Structured English Example

53. Process 2.1 and Structured English Process Description

54. Decision Tables
Can summarize complex decision logic better than structured English
Incorporates logic into the table or tree structure to make descriptions more readable

55. Decision Table Format

56. A Simple Decision Table

57. A Simple Decision Table

58. Constructing a Decision Table
Identify each decision variable and its allowable value (or value range)
Compute the number of decision variable combinations as the product of the number of values of each decision variable.
Construct a table with one more columns than the number of decision variable combinations computed in step 2.
The table should have a row for each decision variable and a row for each process action or computation.
Assign the decision variable with the fewest values to the first row of the table.
Put the decision variable name in the 1st column.
Divide the remaining columns into sets of column for each decision variable value

59. Constructing a Decision Table (con’t)
Choose the next decision variable with the fewest values for the 2nd row.
Put the variable’s name in the 1st column.
Compute the number of column groups as the product of the number of values of this variable and all the variables above it in the table.
Divide the remaining columns into the computed number of groups, and insert values in a regular pattern.
Continue inserting rows as instructed step 5 until all decision variables have been included in the table.
Add a row for each calculation or action.
For each calculation cell, insert the appropriate constant value or formula for the combination of decision variable values that appear above the cell in the same column.
For each action cell, place a check mark in the cell if that action is performed when the decision variables have the values shown in the column above the cell.

60. Constructing a Decision Table- Example
Decision variables
year to date (YTD) purchases: 2 ranges (< $250 and >= $250
number of items ordered: 2 ranges (<= 3 and >=4)
delivery day: 3 values (next day, 2nd day, and 7th day)
Combination values: 2x2x3 = 12
YTD purchases and number of items ordered are the fewest value, chose YTD purchases: 2 values
Create 2 groups of 12/2 = 6 columns and label one for each possible value
Next row, number of items => 4 group of 3 columns
Insert the value ranges for number of items into the column groups

61. Constructing a Decision Table- Example
Delivery day, we simply insert the value of delivery date into individual column
Insert the row containing formulas and values for the shipping charges
Each cell contains a value of formula for the combination of decision variable values in the column above

62. Reduced Decision Table

63. Decision Tables
Four main problems that can occur in developing decision tables:
Incompleteness.
Impossible situations.
Contradictions.
Redundancy.

64. Impossible Situation

65. Redundancy and Contradictions

66. Eliminating Repetitious Rules Requiring the Same Action

67. Modeling Logic with Decision Trees
A graphical representation of a decision situation
Decision situation points are connected together by arcs and terminate in ovals
Two main components
Decision points represented by nodes
Actions represented by ovals
Read from left to right
Each node corresponds to a numbered choice on a legend
All possible actions are listed on the far right

68. Generic Decision Tree

69. Decision Tree for Calculating Shipping Charges

70. Components of a Traditional Analysis Model

71. Summary
Data flow diagrams (DFDs) used in combination with event table and entity-relationship diagram (ERD) to model system requirements
DFDs model system as set of processes, data flows, external agents, and data stores
DFDs easy to read - graphically represent key features of system using small set of symbols
Many types of DFDs: context diagrams, DFD fragments, subsystem DFDs, event-partitioned DFDs, and process decomposition DFDs

72. Summary (continued)
Each process, data flow, and data store requires detailed definition
Analyst may define processes as structured English process specification, decision table, decision tree, or process decomposition DFD
Process decomposition DFDs used when internal process complexity is great
Data flows defined by component data elements and their internal structure