Transcript Chapter 2

The Traditional Approach
to Requirements
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
2
Traditional and Object-Oriented Views
of Activities
3
Requirements Models for the
Traditional and OO Approaches
4
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
5
Data Flow Diagram Symbols
6
DFD Fragment from the RMO Case
7
DFD Integrates Event Table and ERD
8
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
9
Layers of DFD Abstraction
10
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
11
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
12
DFD Fragments for Course
Registration System
13
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
14
Combining DFD Fragments
15
Context Diagram for RMO
Customer Support System
16
RMO Subsystems and Events
17
Context Diagram for RMO
Order-Entry Subsystem
18
DFD Fragments for RMO
Order-Entry System
19
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
20
Order-Entry Subsystem
change confirmation
Order comfirmation
Order change request
Customer
New order
Item inquiry
Order details
Item availability details
Shipping
1
Look up item
availability
Order change details
Valid new order
2
Oder item
Catalog
Product item
Customer
Inventory item
Order
Order transaction
Item availability
Create new
order
Customer info
Catalog
Order item
Transaction
5
Produce
order
summary
reports
Produce
transaction
summary
reports
Bank
Management
Transaction
Order
transaction
4
Order
summary
reports
Item availability
details
Transaction
summary
reports
3
Update
order
Credit
info
Credit bureau
Accounting
Credit info
21
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
22
Detailed Diagram for Create New
Order
23
Physical DFD for scheduling courses
24
List of Activities
25
Stock Log
26
Current Logical System and New
Logical System
Current
Logical
System
New
Logical
System
27
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
28
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
29
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
30
Unnecessary Data Input: Black Hole
31
Process with Impossible Data Output:
Miracle
32
Process with Unnecessary Data Input
33
Process with Impossible Data Output
34
Incorrect and Correct Ways to Draw DFD
35
Incorrect and Correct Ways to Draw DFD
36
Incorrect and Correct Ways to Draw DFD
37
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
38
Unbalanced Set Of Data Flow Diagrams
39
Balancing DFDs
• We can split a data flow
into separate data flows
on a lower level diagram
40
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
41
Data Flow Definitions
• Textual description of data flow’s content and
internal structure
• Often coincide with attributes of data entities
included in ERD
42
Data Flow Definition- Example
New-Order = Customer-Name + Customer-Address +
Credit-Card-Information + N1 {Item-Number + Quantity)
43
Data Store Definitions
• A data store on the DFD represents a data entity
on the ERD
44
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
45
A Data Structure for a Data Flow
DATA STRUCTURE
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
46
and POSTAL CODE
Data Flow Diagram and
Process Specifications
47
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.
48
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.
49
Process Specification Form
50
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
51
Structured English Example
52
Process 2.1 and Structured
English Process Description
53
Decision Tables
• Can summarize complex decision logic better
than structured English
• Incorporates logic into the table or tree
structure to make descriptions more readable
54
Decision Table Format
55
A Simple Decision Table
56
A Simple Decision Table
57
Constructing a Decision Table
1. Identify each decision variable and its allowable value
(or value range)
2. Compute the number of decision variable combinations
as the product of the number of values of each decision
variable.
3. 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.
4. 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
58
Constructing a Decision Table (con’t)
5. 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.
6. Continue inserting rows as instructed step 5 until all
decision variables have been included in the table.
7. 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.
59
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
60
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
61
Reduced Decision Table
62
Decision Tables
• Four main problems that can occur in developing
decision tables:
–
–
–
–
Incompleteness.
Impossible situations.
Contradictions.
Redundancy.
63
Impossible Situation
64
Redundancy and Contradictions
65
Eliminating Repetitious Rules Requiring
the Same Action
66
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
67
Generic Decision Tree
68
Decision Tree for Calculating
Shipping Charges
69
Components of a Traditional Analysis
Model
70
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
71
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
72