CA228 Software Specification 1
Three Main Viewpoints of the Structured Systems Analysis Approach
• Process/functional view:Data flow diagrams
• Data structures:Entity-relationship diagrams
• Time-dependent behavior:State-transition diagrams
CA228 Software Specification 2
Data Flow Diagrams (DFDs)• A DFD is a graphical representation of
– the processes of a system,– the data being transformed and stored
• A DFD gives a very good overview of what is happening in the system
• A DFD represents– the process view of a system (processes are
actions or sets of actions)– the functional view (processes as functions)– (workflow model)
CA228 Software Specification 3
Components of a DFD
• DFD is very easy to read since it is a graphical model and
• there are only four symbols to learn:– Processes– Data Flows– Data Stores– External Agents
CA228 Software Specification 4
Process
• Processes transform a data flow by changing its structure or by generating new information from it
• A process must have at least one data flow into it and one data flow out of it
• A process cannot exist independently
Validate Customer
Order
<processtitle>
CA228 Software Specification 5
Data Flows• A data flow is represented
by an arrow and depicts the fact that some data is flowing from one process to another
• Data moved is sometimes called a packet of data
• The name of data flows should be different if the data is changed on entering the process
verified_order
<flow name>
customer_address
zip_code
phone_#
street_address
CA228 Software Specification 6
Data Stores• When a process needs other
data other than what it receives from another process, to perform its function, this ‘other’ data can be retrieved from data stores
• A data store is a collection of related information for example, a telephone book, student records held in a filing cabinet
Orders
<store name>
CA228 Software Specification 7
Sources and Sinks
• External agents exist in the system’s environment and can:
– provide data to the system (i.e. a source or input) or
– receive data from the system (i.e. a sink or output)
• External entities include people like customers, managers, and include places like departments and suppliers
• The boundaries of a system determine what entities are external
• External agents are also referred to as terminators
Customer
<externalagent
name>
CA228 Software Specification 8
Components of a DFD Put Together
Orders
order
part_numbernew_order
Customer
Validate Order
Stock
CA228 Software Specification 9
Please note...• A DFD does not represent any control flow aspect in
your system• Therefore, no sequencing information can be read
from a DFD• However, this lack of control flow is not a drawback of
DFD, because what we are modeling using DFDs are requirements and not how those are implemented
• Note: In general, a DFD is not a dependency diagram (where a process produces output whenever all inputs are available)
CA228 Software Specification 10
Direct data flow vs. data store• The analyst may
decide if intermediate data needs to be stored persistently– implied by the
user’s needs– implicates
development cost
CA228 Software Specification 11
An alternative notation...
Customer
CustomersD1
ID
Sales Clerk
Validate Customer Order
2
Location
validate_order
Process(rectangle instead a circle!)
Data flow
Data store
External agent(an oval instead of a rectangle)
CA228 Software Specification 12
A few comments about notation...
• The modeling notation being used should be appropriate and efficient for the task at hand
• Beyond that it’s a matter of taste– Circle, rectangle, a cloud...
• Use a standard whenever a standard available
• In any case, be consistent• Underlying concepts matter
– Surface syntax can be learned quickly...
CA228 Software Specification 13
DFD Leveling
• DFDs allow the analyst to look at the system at different levels of detail
• Even quite small systems can be made up of many processes– To include all processes in a single diagram can:– make it look cluttered,– make it difficult to see in detail what a process does
• To overcome this, we can ‘break down’ a single diagram, into a number of diagrams
• This process is known as leveling
CA228 Software Specification 14
Context Diagrams (Overview or Level 0)
• Represents the system at the highest level of detail.
• Comprised of– A single process representing the entire system
modeled– External entities– The data flows that pass between the external
entities and the system
• Purpose is– to identify and examine the interfaces between the
external entities and the system
CA228 Software Specification 15
Example of a context diagram
CA228 Software Specification 16
Context diagram for a telephone system
CA228 Software Specification 17
Guidelines for drawing a Context Diagram
• List potential external entities (people, places). Look for entities that– give data to the system without explaining the
process that creates that data– take data from the system without explaining what
it does with that data
• Establish what flows are sent to and from the system from the external entities
• Draw the context diagram
CA228 Software Specification 18
Level 1 Diagram• Show
– the system in more detail– how data enters the system– how these data items are transformed by the processes– how they leave the system
• A level 1 diagram must have the same number of inputs and outputs as its context diagram
• The flows are connected to and from the actual processes which create, receive or change them
• Processes represent a breakdown of the activities which make up the system
CA228 Software Specification 19
Refinement of “Telephone System” processing element in the context
diagram
CA228 Software Specification 20
Guidelines for drawing a Level 1 Diagram
• Take one sentence at a time and try to identify potential processes (look for verbs)
• Group potential processes so you end up with (minimum) 3 to (maximum) 10
• Identify and list the data flows (generally documents but could also be physical items). A data flow is really anything that moves around the system
• Identify and list the data stores• Draw the level one diagram
CA228 Software Specification 21
Refinement of “PBX” processing element
CA228 Software Specification 22
DFD Fragments
• A DFD fragment is created for each event in the event list
• A DFD fragment is a self-contained model showing how the system responds to a single event
• As an analyst, you create DFD fragments one at a time
CA228 Software Specification 23
DFD fragment corresponding to the “off hook”
CA228 Software Specification 24
Bottom Level
• Continue decomposing a DFD into lower levels until the processes get so simple that you can describe them using:– Process specifications in pseudocode– Decision tables
CA228 Software Specification 25
Example of a process specification using pseudocode
1. IF the dollar amount of the invoice times the number of weeks overdue is greater than $10,000 THEN:
a. Give a photocopy of the invoice to the appropriate salesperson who is to call the customer.
b. Log on the back of the invoice that a copy has been given to the salesperson, with the date on which it was done.
c. Refile the invoice in the file for examination two weeks from today.
2: OTHERWISE IF more than four overdue notices have been sent THEN:a. Give a photocopy of the invoice to the appropriate salesperson to call the
customer.
b. Log on the back of the invoice that a copy has been given to the salesperson, with the date on which it was done.
c. Refile the invoice in the file to be examined one week from today.
3: OTHERWISE (the situation has not yet reached serious proportions):
...
CA228 Software Specification 26
Example of a decision table
CA228 Software Specification 27
Data in data flow diagrams
• Data and data stores defined using Entity Relationship Diagrams and data dictionaries
CA228 Software Specification 28
Entity Relationship Diagrams (ERD)
• ER diagrams describe things and relationships between them
• They were first proposed by Chen in 1976– Unify different approaches to database design
(hierarchical, network and relational)– Original reference: Peter Pin-Shan Chen. The entity-relationship model—
toward a unified view of data . ACM Transaction on Database Systems. Vol. 1, No 1, 1976, pp 9-36
• Different ERD notations in use, but basically the same underlying concepts
CA228 Software Specification 29
Components of ERDs• Entities: Things about which we want or need
to maintain information– E.g., students, courses, suppliers, parts
• Attributes: Properties of entities– E.g. student ID, Course #, course name
• Relationships: – Associations between two or more entities– Students take courses
• ERDs can represent real world (or even imaginary worlds) in a diagram
CA228 Software Specification 30
Example
Student
FName
LName
Address
Course
C#CName
CDescription
takes
Entity(or more precisely: entity set or type)
Entity attribute
Relationship
CA228 Software Specification 31
Relationships• How two or more entities are related (if at
all…)• Cardinality
– 1:1(wife-husband)– 1:N (mother-children)– N:M (grandparents-grandchildren)
• Participation– Total participation
• Every child has a mother
– Partial participation• Not every person has a child
CA228 Software Specification 32
Meaning of ER diagrams
wife husband
Entitiesrepresentobject types
Associationsbetweenindividualobjects
1 1
CA228 Software Specification 33
One-To-Many Relationship
mother children1 n
CA228 Software Specification 34
Many-To-Many Relationship
grandparents
grandchildren
4 m
CA228 Software Specification 35
Partial participation
1
CA228 Software Specification 36
Attributes• Atomic: e.g. SSN• Compound: e.g. address (contain other atomic
attributes: street, zip, state. Can expand it to several attributes )
• Multi-valued: e.g. hobbies ( can have more than one hobby. Can expand to a relationship)
• Derived: e.g. age (can be derived from date of birth. You can decide whether you want to store the derived attributes in the database or not)
• Key: An attribute that uniquely identifies a thing
CA228 Software Specification 37
ERD Notation
• Different notations– No single standard notation
• Some variations– Using diamond to denote relationships or
not– Providing cardinality or not– Way of specifying cardinality
CA228 Software Specification 38
Summary of Diagrams in the Traditional Approach
• Three main viewpoints:– Data flow diagrams - process/functional viewpoint– Entity-relationship diagrams - viewpopint of data structures– State-transition diagrams - viewpoint of time-dependent
behavior
• Two additional detailed viewpoints:– Data dictionary - detailed structure of data– Process specification - detailed structure of processes
CA228 Software Specification 39
Data Dictionary & Process Specs
Example Data Dictionary
Mailing Label = customer_name + customer_address
customer_name = customer_last_name + customer_first_name + customer_middle_initial
customer_address = local_address + community_address + zip_code
local_address = house_number + street_name + (apt_number)
community address = city_name + [state_name | province_name]
Example Data Dictionary
Mailing Label = customer_name + customer_address
customer_name = customer_last_name + customer_first_name + customer_middle_initial
customer_address = local_address + community_address + zip_code
local_address = house_number + street_name + (apt_number)
community address = city_name + [state_name | province_name]
Source: Adapted from Svoboda, 1990, p262-4
Example Mini-Spec
FOR EACH Shipped-order-detail
GET customer-name + customer-address
FOR EACH part-shipped
GET retail-price
MULTIPLY retail-price by quantity-shipped
TO OBTAIN total-this-order
CALCULATE shipping-and-handling
ADD shipping-and-handling TO total-this-order
TO OBTAIN total-this-invoice
PRINT invoice
Example Mini-Spec
FOR EACH Shipped-order-detail
GET customer-name + customer-address
FOR EACH part-shipped
GET retail-price
MULTIPLY retail-price by quantity-shipped
TO OBTAIN total-this-order
CALCULATE shipping-and-handling
ADD shipping-and-handling TO total-this-order
TO OBTAIN total-this-invoice
PRINT invoice
CA228 Software Specification 40
Structured
Systems
Analysis and
Design
Method
CA228 Software Specification 41
What is SSADM?
• Structured Systems Analysis and Design Method
• SSADM is sometimes thought of as a ‘cookbook’ approach to the analysis and design stages of the systems development lifecycle
CA228 Software Specification 42
What is SSADM?
• Developed to standardise many UK governmental IT projects
• Data driven – concentration on the data rather than processes.
• Highly structured with rules, guidelines and standards
• Documentation is crucial to all aspects of the system project development
CA228 Software Specification 43
Background Idea
Smaller stages lead to:
– Improved planning– Better scheduling– Early identification of problems– Better quality– Flexibility and ease of change
CA228 Software Specification 44
5. Physical Design5. Physical Design
4. Logical System Specification4. Logical System Specification
2. Requirements Analysis2. Requirements Analysis
1. Feasibility Study1. Feasibility Study
How is SSADM Structured?
Each step follows on from the previous complete step
Stage 0: Feasibility
Stage 1: Investigation of Current Environment
Stage 2: Business Systems Options
3. Requirements Specification3. Requirements SpecificationStage 3: Definitions of
Requirements
Stage 4: Technical System Options
Stage 5: Logical Design
Stage 6: Physical Design
CA228 Software Specification 45
Feasibility Study
• Examine whether project is technically, financially and socially feasible
• In other words – whether it is in concordance with the current business model
• Determine whether the project is cost-effective (benefits vs. costs)
1. Feasibility Study1. Feasibility Study Stage 0: Feasibility
CA228 Software Specification 46
Requirements Analysis
• Stage 1: Investigation of current Environment – Learn the terminology and function of the users’ environment– The current system forms the basis– Understand the data required– Set the system boundary clearly– Model the current system in terms of processes (DFD) and data
structures (LDS)– Analyse the business operations for problems etc.– Users are involved in walk-through at the end of this stage
• Stage 2: Business System Options – A decision is made by users as which option best meet their needs
2. Requirements Analysis2. Requirements AnalysisStage 1: Investigation of Current Environment
Stage 2: Business Systems Options
CA228 Software Specification 47
Requirements Specification
• A detailed specification of the required system is built up and checked extensively.
• Requirements are defined for processes and data structures modelled in the previous step.
• Both functional and non-functional requirements are defined
• The selected way to go is developed and refined, ELHs introduced
3. Requirements Specification3. Requirements SpecificationStage 3: Definitions of
Requirements
CA228 Software Specification 48
Logical System Specification
• Stage 4: Selection of technical optionsCost/benefit analysis is performed for each of the system’s hardware
and software options
• Stage 5: Logical designThe specification developed in stage 3 is expanded to a high level of
detail:– Define the logic of databases, user dialogues etc– Define update and operations processes– Define how enquiries are processed– Define the sequence of logical processes
4. Logical System Specification4. Logical System Specification Stage 4: Technical System Options
Stage 5: Logical Design
CA228 Software Specification 49
Physical Design
• The complete logical design - both data and processing is converted into a design that will run on the target environment.
• Logical and Technical Specifications are used to produce a physical database design and a set of program specifications, i.e. how the programs should work
• Create function component implementation map (FCIM) to document the logical to physical mapping
• Optimise physical data design• Complete function specification• Consolidate process data interface• Assemble physical design
5. Physical Design5. Physical Design Stage 6: Physical Design
CA228 Software Specification 50
Major SSADM Viewpoints
Modelling of:1 Underlying structure of the data in the
system: entities and their relationships (LDS s)
2 Data flows in / out of the system and any data transformation (DFD s)
3 The way in which data in the system changes over time by events acting on entities (ELH s)
These 3 models are used to cross check for consistency & completeness
CA228 Software Specification 51
Viewpoint 1: Logical Data Modelling
CA228 Software Specification 52
Order_LineOrder_Line
PartPartOrderOrder
CustomerCustomer
Logical Data Modelling
• Modelling and documenting the data requirements
• These requirements are then separated into entities (objects) and relationships (between entities).
CA228 Software Specification 53
Entities
• Entity - A thing that is of interest to an organisation about which information is stored
• The items of interest are called ATTRIBUTES
Example• System = University• Entity = Student• Example = Fred Smith• Attributes ?????
CA228 Software Specification 54
Logical Data Structure
• A diagram to show RELATIONSHIPS between entities
• e.g. A TUTOR teaches many STUDENTS
Tutor Studentsteaches
• Alternative names– Data Model
– Entity-Relationship Model
– Bachman Diagram
CA228 Software Specification 55
Building an LDS
• Identify the entities• Find the
RELATIONSHIPS between them
• Decide the CARDINALITY University Student
University Student
University Student
1 Many
CA228 Software Specification 56
Optionality
• Must, Must
• May, Must
• Must, May
• May, May
Doctor Patient
Doctor Patient
Doctor Patient
Doctor Patient
CA228 Software Specification 57
Relationship Link Phrases
• Each…[must be/may be]….[one or more/one and only one]
• e.g. Each DOCTOR may be responsible for one or more PATIENTS
CA228 Software Specification 58
To Make a Good LDS
• Do not create ENTITIES from Attributes e.g. A Human has 2 ARMS (These are attributes)
• Do not put in unnecessary links• Avoid Many-to-Many relationships
These cause problems as it is difficult to trace which example of entity A refers to which of entity B. Put an extra entity in between.
Flight Ticket Passenger
CA228 Software Specification 59
Example
• CUSTOMERS make sales ORDERS• A single order has several PRODUCTS• Each customer is in one of 621 AREAS• Each customer is serviced by one of 20
DEPOTS• Each customer is allocated a depot depending
on their customer location• All products are stocked in depots
Depot
Customer
Area
Order Product
CA228 Software Specification 60
Example
• CUSTOMERS make sales ORDERS• A single order has several PRODUCTS• Each customer is in one of 621 AREAS• Each customer is serviced by one of 20
DEPOTS• Each customer is allocated a depot depending
on their customer location• All products are stocked in depots
Depot
Customer
Area
Order ProductOrder Line
CA228 Software Specification 61
Example
• CUSTOMERS make sales ORDERS• A single order has several PRODUCTS• Each customer is in one of 621 AREAS• Each customer is serviced by one of 20
DEPOTS• Each customer is allocated a depot depending
on their customer location• All products are stocked in depots
Depot
Customer
Area
Order ProductOrder Line
Stock Item
CA228 Software Specification 62
More Advanced Notations
Account
Bank Building Society
School
PublicSchool
PrivateSchool
Exclusivity
Sub Types
CA228 Software Specification 63
SSADM LDM
A Logical Data Model consists of:
• Logical Data Structure
• Entity description
• Relationship description
• Attribute descriptions
CA228 Software Specification 64
Viewpoint 2: Data Flow Modelling
CA228 Software Specification 65
D1 OrdersD1 Orders
1 Accounts
Check Customer Details and Create Order
1 Accounts
Check Customer Details and Create Order
CustomerCustomer
Data Flow Modeling
Customer andOrder Details
Valid Order Details
• Modelling the way that data flows within a system
• Looks at data in terms of– Processes (which transfer
data from one form to another)
– Data Stores (which are places where data is held)
– External Entities (objects from which data comes, or objects which receive data)
– Data Flows (routes by which the data can flow)
CA228 Software Specification 66
Data Flow Diagram (DFD)
• Maps the route of data around a system
Data Source and Sink
Data Store
Flow Line
Process
• is easy to understand and communicate
• does not show procedures and control as a flowchart does
CA228 Software Specification 67
Representing the Process
Process customerorder
2.3.4 Sales
Person or entityresponsible for process
Process descriptor
Processnumber
CA228 Software Specification 68
Customer Payment Process
Process Payment1Bank
Credit manager
CustomerPayment
Remittance data
Deposit
Receivablesinformation
Customer
1
Update receivables2Accounts
receivable2
CA228 Software Specification 69
Basic Rules for a DFD
• Data does not flow directly between processes
• Data does not flow directly between data stores
• Data cannot be transferred directly from store to sink or source to store
CA228 Software Specification 70
Method by Tom De Marco1. Identify all net input and output data flows of the system
2. Work your way from inputs to outputs, backward from outputs to inputs, or from the middle out
3. Label all the interface data flows4. Label all the functions/processes
How to Construct a DFD
From, input to output
From output to input
What are the inputs?
What are the outputs?
From middle out
CA228 Software Specification 71
Method by Geoff Cutts1. Create a physical document flow diagram
Use ‘Ellipse’ to represent a person or department/section
How to Construct a DFD
Dispatch note
WarehouseCustomer
Invoice
Cheque
Order form
AccountsDept.
Sales Dept. Picking notes
CA228 Software Specification 72
2. Identify the boundary of the system. Draw dotted line to indicate the boundary. Anything outside the boundary will be the external entities (source and receipt of data).
How to Construct a DFD
Dispatch note
WarehouseCustomer
Invoice
Cheque
Order form
AccountsDept.
Sales Dept. Picking notes
CA228 Software Specification 73
3. Create the current physical DFD. Make processes of the ‘Ellipses’ inside the boundary
How to Construct a DFD
Dispatch note
WarehouseCustomer
Invoice
Cheque
Order form Picking notesProcess Order
1 Sales Dept.
Prepare Invoice2 Accounts Dept.
CA228 Software Specification 74
4. Create the context diagram (Level 0), which shows the external interfaces with the outside world, i.e. the global view of a system.
How to Construct a DFD
Dispatch note
WarehouseCustomer Invoice
Cheque
Order form Picking notes
Sales & Accountancy
System
0
CA228 Software Specification 75
5. Create lower level diagrams. Each process can be expanded (decomposed) into lower levels and lower
level DFDs show more details
How to Construct a DFD
Level 1 12
After further investigations, process 1 may become
Level 2 – Reference ID is 1.1, 1.2 ….
1.1
1.3
1.2 Ensure inputs & outputs match
CA228 Software Specification 76
• A system may have a set of DFDs with levels 0 to level N (3 to 4 is common).
• Each level should have at the most 7 processes (easy to digest & to remember)
• Those processes (functions) at the bottom level, which cannot be decomposed further, are called Primitive functions.
How to Construct a DFD
CA228 Software Specification 77
6 Ensure all data flows are given a name
“A DFD cannot be considered to be completed unless all data flows and functions have been given a meaningful name”
7. Add Data Stores where needed
How to Construct a DFD
CA228 Software Specification 78
• Information sink – No output form a process
• Write-only-files – File becomes larger
• Overly complex interfaces - Octopus
• Unnamable data flows• Unnamable processes
Signs of problems
CA228 Software Specification 79
• A physical DFD represents HOW things are happening. It contains the problems of the current system, and is people or machine dependent. It tends to contain redundant data stores/ processing.It tends to mention names of departments, people, forms, devices used and where data is stored
• A logical DFD is extracted from a physical DFD. It is a logical representation of the system, which indicates WHAT the system accomplishes. It is implementation-independent: it focuses on the flow of data between processes without regard to the specific devices, storage location or people in the system.
Types of DFDs
CA228 Software Specification 80
LogicalPhysical
Clerk
Receive order and write out an
order file
Receive order
Typist
Type invoice Produce invoice
Order form
Order form Order Order
Dispatch note
Price fileInvoice
Invoice
Price information
Dispatch details
Examples
CA228 Software Specification 81
Sequence of Building DFDs
How the current system worksCurrent Physical DFD
What the current system accomplishes
Required Logical DFD
Requirements for
New System
Current System
Problems
Current Logical DFD
What the new system is required to accomplish
CA228 Software Specification 82
Required Logical DFDWhat the new system is required to accomplish
Technical System
Option chosen
New Physical DFDHow the new system will work
Sequence of Building DFDs
CA228 Software Specification 83
• Logicalise the data flowWhat data contents are required, remove physical descriptions e.g form/card
• Remove time dependencies due to implementatione.g. The orders are not to be processed until the number is bigger than 20
• Logicalise the functionsRemove unnecessary processes, remove control information, functions which perform only physical tasks
• Logicalise the data storesFor the data flows from or to a data store (physical), replace the data flow with the entity or entities referenced, and replace the physical data store with a logical data store
From Physical to Logical DFD