Requirements

Engineering

Semi-Formal Specification:
Structural Functional Requirements – Structured Analysis
Data Flow Diagrams
SADT
IDEF0

1
Types of Requirements along different views

 Functional Requirements (FRs)

 Structural Functional Requirements

 Functional, i.e., Function-oriented
 Informational. i.e., Information-oriented

 Behavioral Functional Requirements

 Non-Functional Requirements (NFRs)

2
Function Oriented Problem Analysis

 Creates a hierarchy of functions

 Also called (process, activity, work-step, transactions, transforms,
bubbles)
 Root is most abstract
 Leaf nodes the most detailed
 Most methods use data flow diagrams and dictionaries
 Examples
 SRD structured requirements definition
 SADT
 Information Engineering
 Modern structured Analysis
 Problem statement Language

3
Process Modeling

A data flow diagram (DFD) is a tool (and type of process

model) that depicts the flow of data through a system
and the work or processing performed by that
system.

DFDs have become a popular tool for business process

redesign.

4
Data Flow Diagrams
 Existed long before computers
 Show the flow of data through a system
 System
 Organization
 Company
 A computer hardware system
 A software system
 Icons
 Data on the move – named arrows
 Transformations of data – named bubbles
 Sources and destinations of data – named rectangles (terminators)
 Data in static storage – two parallel lines

5
 Data Flow Diagram Notations
Dataflow
Data Store Dataflows are pipelines
through which packets of
Data stores are repositories of information flow. Label the
Process data in the system. They are arrows with the name of the
data that moves through it.
A process transforms incoming sometimes also referred to as
data flow into outgoing data flow. files.

Yourdon and Coad

Process Notations

Yourdon and Coad

Datastore Notation
Gane and Sarson
External Entity
Process Notation External entities are objects outside the
system, with which the system
communicates. External entities are
Gane and Sarson sources and destinations of the system's
inputs and outputs.
Datastore Notations

6
DataFlow Diagrams

7
 Data Flow Diagram Layers
 Data flow diagrams are drawn in several nested layers
 A single process node on a high level diagram can be expanded to
show a more detailed data flow diagram.
 Draw the context diagram first, followed by various layers of data flow
diagrams.

8
Context Diagrams
 A context diagram is a top level (also known as Level 0) data flow diagram. It only contains one process
node (process 0) that generalizes the function of the entire system in relationship to external entities.

9
 DFD levels
The first level DFD shows the main processes within the
system. Each of these processes can be broken into
further processes until you reach pseudocode.

10
Context Diagram- Registration

11
Level 0 Data Flow Diagram

12
Explosion of Process 4

13
Data Flow Diagrams

 Rules
 All names must be unique
 Not a flow chart – no order implied
 No logical decisions
 Don’t get bogged down in detail
 Leveling
 Preserve the number of inputs and outputs between the levels

I1 O1
O1
A A1
I2 I1 A3

A2 data
I2
14
Difference between DFD and Flowcharts

 Processes on DFDs can operate in parallel (at-the-same-time)

 Processes on flowcharts execute one at a time

 DFDs show the flow of data through a system

 Flowcharts show the flow of control (sequence and transfer
of control)

 Processes on one DFD can have dramatically different timing

 Processes on flowcharts are part of a single program with
consistent timing

15
Homework -
 Draw a DFD for an ATM

16
Illegal Data Flows

17

Copyright © 2000 The McGraw-Hill Companies. All Rights reserved

Structured English context

18
Copyright © 2000 The McGraw-Hill Companies. All Rights reserved
Structured English Rules

Condition stubs

Action Stubs
19
Copyright © 2000 The McGraw-Hill Companies. All Rights reserved
 Decision Table Example
Condition Stub Condition Entry

If Customer is bookstore Y Y N N N N

Order size > 6 copies Y N N N N N

Customer is     Y Y Y Y
librarian/individual
Order size 50 copies or     Y N N N
more
Order size 20 to 49       Y N N
copies
Order size 6 – 19 copies         Y N

Then Allow a 25% discount X          

Allow a 15% discount     X      

Allow 10% discount       X    

Allow a 5 % discount         X  

Allow 0% discount   X       X
20
Action Stub Action Entries
Structured English constructs

21
Copyright © 2000 The McGraw-Hill Companies. All Rights reserved
 Structured English
Structured English is a language and syntax, based on the relative strengths of structured
programming and natural English, for specifying the underlying logic of elementary processes
on DFDs .
1. For each CUSTOMER NUMBER in the data store CUSTOMERS:
a. For each LOAN in the data store LOANS that matches the above
CUSTOMER NUMBER:
1) Keep a running total of NUMBER OF LOANS for the
CUSTOMER NUMBER.
2) Keep a running total of the ORIGINAL LOAN PRINCIPAL for the
CUSTOMER NUMBER.
3) Keep a running total of CURRENT LOAN BALANCE for the
CUSTOMER NUMBER.
4) Keep a running total of AMOUNTS PAST DUE for the
CUSTOMER NUMBER.
b. If the TOTAL AMOUNTS PAST DUE for the CUSTOMER NUMBER
is greater than $100.00 then:
1) Write the CUSTOMER NUMBER and all their data attributes
as described in the data flow LOANS AT RISK.
Else
1) Exclude the CUSTOMER NUMBER and data from the data
flow LOANS AT RISK.
Copyright © 2000 The McGraw-Hill Companies. All Rights reserved
22
Data Dictionaries

 Used to augment the Data Flow Diagrams

 Repository
 Layout
 Name of the item
 Alias
 Description/Purpose
 Related data items
 Range of values
 Data flows
 Data structure definition/form

23
Data Structures
 Are specific arrangements of data attributes that define a single instance of a data flow
 A sequence that occur one after another
 A selection of one or more attributes from a set
 A repetition of one or more attributes
 Most common data structure notation is Boolean algebraic notation

“Consists of” or “is composed of”

=
+ Means and and designates sequence

Only one of the attributes may be present – selection -

[…] Attributes separated by commas
Either/or

Attributes may occur many times – repetition -

{…} Attributes separated by commas

Attributes in side are optional no value for some of the

(…) data flows

24
Example Data Structure

DATA STRUCTURE ENGLISH ENTERPRETATION

ORDER= An instance of ORDER consists of:

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

25
A Simple Process Model

26
Traditional Approaches to Enterprise Modeling
SADT (Structured Analysis and Design Technique)

•Background
•in use since the mid-seventies
•inspiration for many commercial tools
•(DFD?)trademark of Softech, Inc.
•View
•"System" refers to any enterprise/organization, physical, manufacturing,and SW
system
•Context Analysis should involve
• technical assessment: feasibility of system architecture
•Are the components and inter-relationships technically realizable?

• operational assessment: system performance in a working environment

•Can the system perform task X in less than a week of time?

• economic assessment: costs & impacts of system implementation & use

•Can the system be built with $20M, 1000 SE’s, in 2 yrs?

27
SADT (Structured Analysis and Design
Technique)

28
SADT (Structured Analysis and Design Technique

29
SADT (Structured Analysis and Design Technique

Semantics of Arrows
In an actigram
• Inputs are data that are consumed by the activity
•Outputs are produced by the activity
•Controls influence the execution of an activity but are not consumed
•Mechanism is a processor (machine, computer, person) which makes the activity happen 30
SADT (Structured Analysis and Design Technique

31
SADT (Structured Analysis and Design Technique

32
SADT (Structured Analysis and Design Technique

33
 SADT (Structured Analysis and Design Technique

Semantics of Arrows
In an actigram
• Inputs are data that are consumed by the activity
•Outputs are produced by the activity
•Controls influence the execution of an activity but are not consumed
•Mechanism is a processor (machine, computer, person) which makes the activity happen

• in a datagram
•Inputs are activities that produce the data
•Outputs consume the data
•Controls influence the internal state of the data
•Mechanism is a device for storage, representation, impl., etc. 34
A Simple Data Model

35
 FUNCTION MODELING USING
IDEF-0
A Function Model is a Representation of the Activities and
Relationships Between Activities in an Existing or Planned System.

36
IDEF0 (Integration Definition for Function
Modeling)
Background
• released in Dec., 1993
• the "reference model" for system/enterprise function modeling
• also in use for software process modeling
• Federal Information Processing Standard maintained by Dept. of Commerce,NIST (National Institute of
Standards and Technology) & Computer Systems Laboratory
• based on ICAM (Integrated Computer-Aided Manufacturing) from the US Air Force Wright Aeronautical
Laboratories
• Information Modeling (IDEF1X) uses ERD + generalization/specialization
• closely resembles "actigrams" of SADT

Stringent Rules
E.g., Boxes shall be sufficient to insert box names
rectangular in shape with square corners
drawn with solid lines
Arrows that bend shall be curved using only 90 degree arcs
shall be drawn in solid line segments
vertically or horizontally, not diagonally

37
38
Terminology of IDEFØ
 Functions and activities
 Diagrams, Boxes, and Arrows
 ICOMs: Inputs, Controls, Outputs, and Mechanisms
 Arrows, links, relationships, and concepts
 Splits, Joins, Unbundling, Bundling, and Branching
 Decompositions
 Viewpoint, Purpose, and Context
 NIST (FIPS ) standard

39
 What is IDEFØ?

 An IDEF method for modeling functions

 Graphics (diagrams)
 Text (glossary & narrative)

 Provides both a process and a language for

constructing a model of the decisions, actions, and
activities in an organization

40
 What is an IDEFØ Model?
 A definition of activities and information
 Within a particular Context
 Having a consistent Viewpoint
 For a particular Purpose

 Series of diagrams (that decompose a subject into manageable

chunks)

 A foundation for requirements specification, design, and

programming

 A useful record throughout the life-cycle of an enterprise

41
Example IDEFØ Diagram
Customer
Expectations

Needs Establish Understanding of Customer Requirements

Reqmnts.
A1

Alternative Technologies Contract for Tradeoff Decisions

Design
Knowledge of Previous Design System Design
A2

Raw Material Build Product

System
A3
Analysis Methods Design Methods Fabrication Methods

42
Diagram Construction (1)
 Boxes represent functions

 Arrows represent real objects or data

CONTROL

INPUT OUTPUT
FUNCTION

MECHANISM
43
 Diagram Construction (2)
CONTROL

INPUT OUTPUT
Label

MECHANISM
 Labels are words that name functions and data/real objects

 Function labels are verbs or verb phrases and are put in the center of the
function box

 Data labels are nouns or noun phrases

 Data labels name the input, control, output, and mechanism arrows
44
 IDEFØ Function
 An Activity, Action, Process, or Operation
 A Description of “What Happens” in a Particular
Environment
 Accomplished by People, Machines, Computers
 Labeled with an Active Verb or Verb Phrase

Function Label

45
 IDEFØ Functions (Activities)
Represented as a box in an IDEF0 Model.

First diagram has one Function which

bounds the context of the Model. (A - 0
diagram)
A0
A0
Diagram has a maximum of 6 functions & a minimum of 3

A1

A2 A1

A3

A4 A2

A5

A3
A6

46
IDEFØ Relationships (Between
Functions)

 Represented as arrows
 AKA concepts
 Real objects, data, people, machines,
and computers

47
ICOMs
 Inputs

 Controls

 Outputs

 Mechanisms
48
Inputs
 Real Objects or Data Needed to Perform a
Function
 Objects or Data Transformed by a Function
 Labeled with a Noun or Noun Phrase

INPUTS FUNCTION

49
 Output

 Objects or Data Produced as a Result of the Function

 Labeled with a Noun or Noun Phrase

INPUTS FUNCTION OUTPUTS

50
Control
 That which Governs the Accomplishment of the Function
 Things that Influence or Determine the Outputs
 Labeled with a Noun or Noun Phrase
CONTROLS

INPUTS OUTPUTS
FUNCTION

51
 Mechanism

 Person, Device, or Data which Carries out the Function

 The Means by which the Function is Performed

 Labeled with a Noun or Noun Phrase

CONTROLS

INPUTS FUNCTIO OUTPUTS

N

MECHANISMS 52
Box and Arrow Relations in a Diagram
(Join) FEED BACK OUTPUT
TO CONTROL

OUTPUT TO INPUTS
INPUT
1
OUTPUT
TO CONTROL

ARROWS 2
BRANCHING
(Split)

3 OUTPUT

OUTPUT TO
MECHANISM

53
Arrows: "Branching"

Output can branch and be used by two functions

simultaneously or sequentially

OUTPUT
DATA

ONCE THIS DATA

IS SUPPLIED, 2
FUNCTIONS 2 & 3
CAN OPERATE
SIMULTANEOUSLY
OR SEQUENTIALLY
3
Without labels we cannot tell how the branching occurs

54
Arrows: "Joining"

PROCURED ITEMS PRODUCTION ITEMS

CONTROL
PRODUCTION
ITEMS &
TOOLS

FINISHED SUB-PARTS
55
 Arrows: "Feedback"
COMMENTS

SYSTEM
REQUIREMENTS

DRAFT
SPECIFICATIONS
DESIGN

REVIEW

DRAFT SPECIFICATION
WITH DESIGN CHANGES APPROVED
DESIGN

56
 Bundling and Unbundling

Bundle: Concepts B and C are bundled to form concept

A.
C

B
A

Unbundle: Concept A is unbundled into concepts B and

C.
A
B
C

57
 Bundles and Unbundles
Unbundle
Management
Directives
Bundle
Files
Keep
Records Customer
A1
Records Account
Transaction
Orders Entries Entries
Deliver
Products Prices
&Tax
A
2 Tables Billing
Transactions Entries
Perform
Billing Invoices
A3

Files = Customer Records + Price & Tax Tables

Account Entries = Transaction Entries + Billing Entries 58
 Bundles and Un-bundles: PCB ASSEMBLY
Management Unbundle
Process plan
Directives
Bundle
Solder paste
Load board method
onto m/c Bare boards Placement
A1 soldering method
completed
data Assembly
Records
Apply
solder
paste A placement
2 completed
Paste data
applied
Place chip
board Chip
on board
A3 positioned board
Process Plan = loading details + solder paste details + chip placement method
Assembly Records = soldering completed data + placement completed data

59
 Function Decomposition

More General A0 Parent Diagram

A-0

More Detailed

A1

A2 Child Diagram
A3

A4

A0

“Parent” Activities Represent a Higher Level of Abstraction than

that of Their “Children”
60
Further Decomposition
Parent Diagram
A1

A2
Parent Activity
A3

A4

A0

A31

A32 Child Diagram

A33

A34

A3
61
 Decomposition

 Establishes model hierarchy

 Functions are comprised of other functions

 Decompositions is a process of breaking down of the functions

(level-by-level)

 Data consistency is required throughout the level-by-level

decomposition breakdown

62
 Complexity Simplification Technique Tunneled
Arrows

Tunneled Arrows at Connected Tunneled Arrows at Unconnected

Ends Ends
(Concept Does Not Appear on the (Concept Does Not Appear on the
Next Lower Level.) Next Higher Level.)

63
 Tunneling Example
This control will not appear
on child diagram.

A0 This control will still be

designated as C3 on child
diagram.
A-0 Parent Diagram

C1 C3 This output will not be shown

on parent diagram.
I1
A1

A2

O1
A3

A0 Child Diagram
64
Steps in Building a Model
 1. Define Viewpoint, Purpose, and Context

 2. Develop the Context Diagram (Putting the situation in context)

 3. Decompose activities to fit scope of modeling task (complete modeling per rules, etc)

 4. Develop glossary

65
Model Orientation!!!!
 Context (Subject)
The Boundaries of the Subject Matter

 Viewpoint (Bias)
The Perspective from which a Subject is Analyzed

 Purpose (Objective)
The Reason(s) a Model is Created

66
Example - Context Diagram
Inventory Policy

Purchase policy

Stock Levels Acquire Payments

Materials Rejected Materials
A0

Vendor
ABC Co.

A-0 Diagram 67
 Example - Decomposition of the
Context Diagram
Purchase Policy
Inventory Policy
Inspection Policy
Stock Reorder
Levels Check Stock Qty PO Prep.
Levels & Det
Reorder Qty Policy
A1
Prepare Purchase Order
Authorize &
Mail P O A2
Invoice
Receive PO
Produce & Rejected
Ship A3 Materia
Receive l OK Material
Material Shipment &
Inspect A4
Restock Payments
& Make
Payment A5

ABC Co. Vendor

A0 Diagram 68
Function Model for Planning and Implementing a
Feature Extraction module
 Purpose: To obtain a better understanding of
the various tasks involved in planning and
implementation of a feature extraction module
 Context: We will assume CAD model formats,
process planning requirements and resources
available (people and computers) are known.
The FE module will be built using available
existing resources (no new tools or software
will be purchased).
 Viewpoint: that of an industrial / mfg engineer
who has a background in designing / building
software systems
69