Soongsil University Industrial and Information Systems Engineering

Soongsil University Industrial and Information Systems Engineering
Structured Analysis Soongsil University Industrial and Information Systems Engineering

Functional Analysis Stage 1. Function Decomposition
Stage 2. Data Flow Diagram Stage 3. DD (Data Dictionary) Stage 4. Mini Specification

Process A process is a business activity which when executed produces certain outputs from given inputs The function(s) performed by a process may be complex, with multiple inputs, outputs and users The entire application itself is a process We use successive decomposition into sub processes to reveal greater details of the processing

Function Decomposition
Decomposition splits work of a task into subtasks; subtasks together make-up the parent task; - looks like a module decomposition - not like ‘calling’ a module Balanced decomposition: sub-tasks are roughly equal in complexity

Function Decomposition (FD)
FD Diagrams: Example 1

Function Decomposition (FD)
FD Diagrams: Example 2

Function Decomposition …
Top-down decomposition gives hierarchical structure Decompose into 2 or more; not more than 5 A high cohesion (high independence) and minimum coupling (minimum interdependence) are fundamental criteria Continue decomposition until elementary processes are identified

Function Decomposition
Elementary process is a smallest unit of activity meaningful to end user Process decomposition diagram A tree structure Elementary processes are leaf nodes Data are not shown

Homework Exercise: prepare FDDs for Railway reservation system
Hospital patient management Employee payroll

Function Decomposition …
Use proper naming of processes Business functions named as nouns Eg) marketing, Inventory control, … Process name consists of an active verb and an object Eg) accept order, calculate interest, …)

Naming … Avoid long names
(sentences containing and, if, then, etc. indicate non-cohesive complex tasks) Real world is a good reference for selecting proper names; organizational units are organized functionally and each unit has a well-defined task

Example of Data Flow Diagram
Current grade Final grades Test scores Current score Final score Student Calculate Class Grad Class/ grad file files 1.0 2.0 D1 D2 Register’s office Teacher Save Open Calculate University Grad Process Source / sink Data stores (files) Data flow

Data Flow Diagram (DFD)
A picture of the movement of data between external entities, the processes, and data stores within a system DFDs depict logical data flow independent of technology

Data Flow Diagram (DFD)
FDD may be done before DFD or we may prepare DFDs directly Have more contents than FDDs Flow of data is shown, not flow of control

Data Flow Diagrams (DFD) …
DFDs are unambiguous and concise They can describe processing at physical as well as logical levels DFDs facilitate top-down development They permit outlining of preferences and scope

Data flows They are groups of data that move through a system from one place to another. Include names of all individual elements of data moving Data flow is represented by “arrow” E.g. results of grading mark Current score Final score Final grades

Data stores They refer to data at rest that may represent one or many physical locations. Each data store has a label and number (number of files location) Data store is represented by a rectangle Eg) data about students (paper-based or floppy disk) D1 D1 Class/ grad file D1 Class/grad file Class/grad file

Processes They are the action performed on data so that they are transformed (manual or automatic), stored or distributed E.g. calculate class mark Each process includes a name & process number It is represented by a bubble or rectangle with rounded corners 1.0 1.0 1.0 Calculate Class Grad Calculate Class Grad Calculate Class Grad

Sources / sinks They are the origin (sources) and/or destinations (sink) of the data, i.e. that supplies or receive data They refer to external entities (or outside) to a system; boundaries of the system. Each source/ sink has a name that states what the external agent is, e.g. students A source (sink) is represented by square Teacher

DFD Shapes from Visio Visio 2000 Visio 5.x

Naming and Drawing DFD Elements
Process Data flow Data store External entity PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 John Wiley & Sons, Inc. All rights reserved.

Example: Air line reservation

DFD levels Context Diagram Level 0 DFD Level 1 DFD Level 2 DFD

Context Diagram Shows the entire application as a single process
Identifies its external interfaces This is the starting point; also called Fundamental System Model, Level 0 DFD

Context Diagram …

Context diagram of DFD Final grades Student Register’s office Test scores Grading system Final grades Current score Final score Teacher Context diagram is an overview of an organisational system that show the system boundaries, external entities that interact with the system, and the major information flows between the entities and the system

Creating a Set of DFDs Draw a Context Diagram Drawing Guidelines
Draw the context diagram so it fits on one page Use the name of the information system as the process name in the context diagram Do not cross lines Provide a unique name and reference number for each process Obtain user input and feedback

A DFD Fragment Example

Process Refinement Decompose a process into sub processes
May reveal more data stores, external interfaces Use decimal numbering system: process 1 is decomposed into 1.1, 1.2, etc. At each level, understand all data flows and processing; label processes, data stores and data flows (arrows) meaningfully. Continue decomposition and stop when control flow (conditional branches, loops) surfaces. Refine until processes are well understood.

Level-0 diagram Level-0 diagram is a data flow diagram that represents a system’s major processes, data flows, and data stores at a high level of detail. Example of level-0 diagram Final grades Student Register’s office Current grade Test scores Current score 1.0 2.0 Teacher Calculate Class Grad Calculate University Grad Final score Final grades Save Open Save Open Class/ grad file D1 D2 Student files

Refinement … DFDs do not show control flow
DFDs do not show initializations (such as initial file creation), but show processes running in a steady state.

Refinement … Processes must be independent of each other (cohesion, coupling principles apply); work of a process depends only on its inputs and not on state of another process Only needed data should be input, and outputs should be based on data entering the process

Refinement … Ensure consistency among levels: inputs and outputs at previous level should be present at next level

Physical DFD Shows implementation details
Names and locations of places/people Ways of storing data (like card indexes) Useful for describing existing system to validate it with users Needs to be converted into logical DFD after validation from users

Showing Boundaries

DFD Example 1: Payroll

DFD Example 2: Old Car Mart
Buys and sells old cars; has large number in stock: different models, make, year,colors,… Does some repairs for adding value; records kept; has own garage Advertise in news papers Salesmen hired on commission basis to handle customers, negotiate, etc. Needs to take stocks; prepare summary of sales, profits, etc; pay salesmen Prepare DFD and ER diagrams

Car Mart …

Car Mart … Define data stores and flow clearly to understand the DFD
We can further refine some of the processes For process 5: Making a sale Take buyer requirements and his/her other details List cars that match requirements Show repair history, car history Register sale and negotiated price Compute commission

Example 3: Book Supplier
Supplies books to customers; no stocks maintained; books sourced directly from publishers Prepare context diagrams (all inputs/output not shown, such as invoices,…..

Book-Supplier : Refinement 1

Book Supplier: Exploding Process 2

High Level Structure (Hierarchy) Chart
Structured Chart: Systems documentation showing each level of design, the relationship among the levels, and the overall place in the design structure; can document one program, one system, or part of one program.

Data Flow Diagram for mail-in university registration system
1.0 Requested Courses Open courses Student Verify Availability Accepted/ rejected- Course file Confirmation- selections Course- letter Course details -enrollment 2.0 Enroll Student Student Master File Student Details Registration 3.0 Confirm registration

Level 2 Process Logic to Prepare Invoice Compute total credit
2.1 2.2 Amount 2.3 Past the Prepare Apply course Student's invoice payment courses Check Confirm Fee Invoice Student Course Fee schedule offering Process Logic to Prepare Invoice Compute total credit Compute total fee Add student fee

Context diagram of MacDonald food ordering system
Customer Kitchen Receipt Food order Customer order Food ordering system Management report Restaurant manager

Level-0 diagram Exercise in the classroom
Generate the level-0 diagram by detailing the main process Food ordering system (process 0) could be split into three sub processes Receive and transform customer food order Update good sold file Update inventory file Produce management report

Rules of DFD / decomposition of process 4.0
Functional decomposition is an iterative processes of breaking the description of a system down into finer and finer details which creates a set of charts in which one process in a given chart is explained in greater details on another chart Access good sold & inventory data 4.1 Inventory data Daily Goods Sold amounts Prepare management report 4.3 Aggregate good sold & inventory data 4.2 Good sold Aggregate data Management report Daily inventory amount Produce management report 4.0 Daily inventory amount Daily Good sold amounts Management report

Rules of DFD / balancing
Balancing is the conservation of inputs and outputs to a DFD process when that process is decomposed to lower levels

Unbalanced DFD 1 input 1 output
This is unbalanced because the process of the context diagram has only one input but the Level-0 diagram has two inputs. 2 inputs 1 output

Balanced DFD 1 input 3 outputs
These are balanced because the numbers of inputs and outputs of context diagram process equal the number of inputs and outputs of Level-0 diagram.

Balanced DFD (cont.) These are balanced because the inputs and outputs to Process 1.0 of the Level-0 diagram equals the f inputs and outputs to the Level-1 diagram. 1 input 4 outputs

Data Flow Splitting A composite data flow at a higher level may be split if different parts go to different processes in the lower level DFD. This remains balanced because the same data is involved, but split into two parts.

Which of the two diagrams is balanced or unbalanced?
Daily inventory amount Daily inventory amount Daily Good sold amounts Access data 4.1 Inventory data Daily Good Sold amounts Prepare report 4.3 Aggregate data 4.2 Good sold Management report Produce report 4.0 Management report A B Daily inventory amount Access data 4.1 Inventory data Daily Good Sold amounts Prepare report 4.3 Aggregate data 4.2 Good sold Management report Daily Good sold amounts Produce report 4.0 Management report

Using DFD in the analysis process & guideline
Correctness Completeness Inconsistency Timing Primitive DFD

Correctness and Completeness
Correctness: it refers to drawing a correct DFD (see rules e.g. balancing, functional decomposition) Completeness: it refers to whether you have included in your DFDs all the components necessary for the system you are modeling. Examples of completeness There are entities that are not connected to any thing else There is a process with only input and without output

Produce management report Receive & transform customer food order
Example of completeness: where is the error? Update inventory file Update good sold file Produce management report Customer Kitchen Good sold file Inventory file Receive & transform customer food order 1.0 2.0 3.0 4.0 Good sold Inventory sold Format data Daily good sold amount Daily inventory amount

Consistency Consistency: it refers to whether or not the depiction of the system shown in at one level of a nested set of DFD is compatible with the depiction of the system shown in at other level Example of inconsistencies Existing of a level-1 diagram with no high level -0 diagram Existing of a data flow at level-0 diagram but not at level-1 diagram

Example of inconsistencies: where is the error? (already seen)
Level-1 diagram Produce report 4.0 Daily inventory amount Daily Good sold amounts Management report Level-0 diagram Daily inventory amount Inventory data Access data 4.1 Aggregate data 4.2 Daily Goods Sold amounts Good sold data Aggregate data Prepare report 4.3 Management report

Guidelines for Drawing DFDs (cont.)
Timing Time is not represented well on DFDs. Best to draw DFDs as if the system has never started and will never stop. Iterative Development Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled.

Guidelines for Drawing DFDs (cont.)
Primitive DFDs Lowest logical level of decomposition Decision has to be made when to stop decomposition

Other guidelines DFD does not show timing, draw diagrams as if the system has never started and will never stop Iterative development: DFD recognize that system requirement determination & structuring are interacting Primitive DFD: it refers to the lowest level of DFD decomposition. When does a DFD decomposing stop? Very important idea: there is no good or bad modelling!!! Drawing DFD is facilitated by CASE upper tools (generating processes and diagrams) DFD can be used as an analysing tool to check correctness, inconsistencies and completeness DFD can be used as a tool to support Business Process Re-engineering (BPR)

DFD Diagramming Rules Process
No process can have only outputs or only inputs…processes must have both outputs and inputs. Process labels should be verb phrases.

DFD Diagramming Rules Data Store
All flows to or from a data store must move through a process. Data store labels should be noun phrases.

DFD Diagramming Rules Source/Sink
No data moves directly between external entities without going through a process. Interactions between external entities without intervening processes are outside the system and therefore not represented in the DFD. Source and sink labels should be noun phrases.

DFD Diagramming Rules Data Flow
Bidirectional flow between process and data store is represented by two separate arrows. Forked data flow must refer to exact same data item (not different data items) from a common location to multiple destinations.

DFD Diagramming Rules Data Flow (cont.)
Joined data flow must refer to exact same data item (not different data items) from multiple sources to a common location. Data flow cannot go directly from a process to itself, must go through intervening processes.

DFD Diagramming Rules Data Flow (cont.)
Data flow from a process to a data store means update (insert, delete or change). Data flow from a data store to a process means retrieve or use. Data flow labels should be noun phrases.

Book Supplier : homework
Refinement 1 needs to be extended for handling payments Extend for : Payments from customers Create ‘a/c receivable’ for books sent Update receivable when payments received Credit rating will need to be adjusted periodically Extend for : Payments to publishers Create ‘a/c payable’ when invoices received Check invoices with books actually received Make payments periodically as per payment terms (within fixed days; incentives for early payment, etc.)

Data Dictionary A data dictionary, or data repository, is a central storehouse of information about the system’s data An analyst uses the data dictionary to collect, document, and organize specific facts about the system Also defines and describes all data elements and meaningful combinations of data elements

Data Dictionary (DD) – Used to define the structure of the information being exchanged – Allow validation if the data model is free of redundancies and inconsistencies – Rules: • Every data flow arrow and every memory has a name • We define every data flow and memory name in a Data Dictionary (e.g. InquiryData =PersonalData + (CompanyData)) • The Data Dictionary entries conform to the BNF (see next).

Data Dictionary (DD) – BNF (Backus Naur Form) • Notation:
... = is equivalent with Sequence and composition ‘ ‘ Constant of Character types [... | ...] Selection (either ... or ...), e.g) [a | b] { } Repetition { }x Repetition at least x, >= X, e.g) {a}3 { }y Repetition at most y, <= y, e.g) {a}5 { }yx x <= Repetition number <= y, e.g) {a}53 x{ }y Repetition from M to N ( ) Option, e.g) (a) * ... * Comment

Data Dictionary (DD) The format of the DD is semi-formal Example: selection (or) telephone number = [ local extension | outside number ] local extension = 2 + { number }3 outside number = 0 + [ local number | long distance number ] local number = prefix + access number long distance number = (1) + area code + local number prefix = [ 123 | 124 | 125 ] access number = { number }4 number = * any number between 0 and 9 * composition (and) optional repetition a comment

Data Dictionary (DD) 자료흐름도에서 쓰인 자료 항목들이 '가나다' 순으로 사전처럼 정리되어야 함
<Example> 구독자_전화번호 = [지역번호] + 국번 + '-' + 가입자_번호 지역번호 = '(' + '0' + 첫자리 + {십진수}20 + ')' 국번 = {십진수}43 가입자_번호 = {십진수}44 첫자리 = 2|3|4|5|6 자료흐름도에서 쓰인 자료 항목들이 '가나다' 순으로 사전처럼 정리되어야 함

Example of DFD and DD DFD DD Order accepted Ticket book Ticket
allotment Ticket order Order Order rejected Bank Customer deposit Ticket sales Payment register -ation Receipt report Receipt Store DD Order accepted = name + address + payment + date + No. of orders + 1{ticket} ticket = 1{date + fee + available numbers + {ticket}} Ticket order = name + address + payment + 1{ticket} Order rejected = name + address + payment + letter for rejection

Data Dictionary A data element, also called a data item or field, is the smallest piece of data that has meaning Data elements are combined into records, also called data structures A record is a meaningful combination of related data elements that is included in a data flow or retained in a data store

Data Dictionary Documenting the Data Elements
You must document every data element in the data dictionary The objective is the same: to provide clear, comprehensive information about the data and processes that make up the system

Data Dictionary Documenting the Data Flows
The typical attributes are as follows Data flow name or label Description Alternate name(s) Origin Destination Record Volume and frequency

Data Dictionary Documenting the Data Stores
Typical characteristics of a data store are Data store name or label Description Alternate name(s) Attributes Volume and frequency

Data Dictionary Documenting the Processes
Typical characteristics of a process Process name or label Description Process number Process description

Data Dictionary Documenting the Entities
Typical characteristics of an entity include Entity name Description Alternate name(s) Input data flows Output data flows

Data Dictionary Documenting the Records
Typical characteristics of a record include Record or data structure name Definition or description Alternate name(s) Attributes

Data Dictionary Data Dictionary Reports Many valuable reports
An alphabetized list of all data elements by name A report describing each data element and indicating the user or department that is responsible for data entry, updating, or deletion A report of all data flows and data stores that use a particular data element Detailed reports showing all characteristics of data elements, records, data flows, processes, or any other selected item stored in the data dictionary

Mini Specs; Process Description
Means of specification for atomic subsystems not being refined by DFDs anymore. – specify the transformation of input data into output data in an implementation independent way – Pseudo Code, Decision Tables (DT)

Process Description Tools
A process description documents the details of a functional primitive, and represents a specific set of processing steps and business logic

Modular Design Based on combinations of three logical structures, sometimes called control structures, which serve as building blocks for the process Sequence Selection Iteration - looping

Structured Language Must conform to the following rules Use only the three building blocks of sequence, selection, and iteration Use indentation for readability Use a limited vocabulary, including standard terms used in the data dictionary and specific words that describe the processing rules

Structured Language (English) Might look familiar to programming students because it resembles pseudocode

Decision Tables Shows a logical structure, with all possible combinations of conditions and resulting actions It is important to consider every possible outcome to ensure that you have overlooked nothing Condition of Rules combinations (1) an amount of payment > 10 million Y N Y N (2) Overdue > 60 days Y Y N N Action of The rule combinations (1) Issue Invoice N Y Y Y (2) Issue Payment Bill N Y Y Y (3) Register in Credit Record N N Y N

Decision Tables Can have more than two possible outcomes Often are the best way to describe a complex set of conditions

Decision Trees Graphical representation of the conditions, actions, and rules found in a decision table Whether to use a decision table or tree often is a matter of personal preference

Summary Process modeling by process decomposition
DFD shows data flows, stores and processes, but not control flows Proper naming of stores, processes and indicating data flowing among them very important for DFDs to be independently readable

요구사항 명세서 문서 양식 1. 제목과 목차 (Title page and table of contents)
2. 서론 (Introduction) /*기술적인 목표와 사업 목표를 포함한 시스템의 목표를 기술한다.*/ 2.1 독자 (Audience) /*이 문서를 읽을 독자들을 기술하고 독자의 유형을 분류하여 문서 전체를 읽어야 하는 경우와 문서의 일부를 생략하고 읽어도 되는 경우를 기술한다. */ 2.2 전체 기술 (Overall Description), 즉 시스템 개요 2.3 목표 2.4 프로젝트 제약조건 (Project Constraints) 3. 기능 기술 (Functional Description) /*정보 흐름이 어디로 어떻게 이루어 지는지 체계적이며 구체적으로 기술 한다. 독자들이 이해하기 쉽도록 정보의 흐름과 내용, 구조 등이 쉽게 기술되어야 한다.*/ 3.1 자료 흐름도 (Data Flow Diagram) 3.2 프로세스 명세서 (Process Specification) /*DFD 의 최하위 프로세스(원시 프로세스)에 대한 기본 기능이 기술된다. 가능하면 한 장에 한 프로세스만을 기술하는 것이 좋다.*/ 3.3 자료 사전 (Data Dictionary) /*4.2의 자료사전과 합쳐질 수 있다*/ 3.4 기능면에서의 시스템 특성 4. 정보 기술 (Information Description) /*시스템의 객체, 객체의 속성, 객체 사이의 연관성을 규명한다*/ 4.1 ERD (Entity-Relationship Diagram) 4.2자료 사전 (Data Dictionary) /*3.3의 자료사전과 합쳐질 수 있다*/

요구사항 명세서 문서 양식(계속) 5. 초보 사용자 매뉴얼 (Preliminary User Manual)
/*매뉴얼의 사용자가 누구인가 규명하고 사람과 시스템 사이의 인터페이스에 대한 정보를 기술한다. 입출력 데이터를 중심으로 예상되는 메뉴구조, 스크린, 보고서 형식 등이 포함될 수 있다.*/ 6. 검증 기준 (Validation Criteria)과 인수 조건 /*최종 결과물이 실제로 요구사항 명세서에 기술되어 있는지 사용자와 평가자가 검증할 수 있도록 검증 기준을 기술한다. 약속한대로 시스템이 만들어 졌는지 결정할 수 있도록 점검 리스트(check list)를 포함 한다.*/ 6.1 기능시험 및 성능시험 7. 무기능 요구사항(Nonfunctional Requirements) 7.1 성능 요구(반응 시간, 처리소요 시간, 처리율) 7.2 하드웨어 요구(기억장치 규모, 통신 수용도) 7.3 예외 조건 및 이의처리 /*규제 조항과 제약 조건을 기술한다. 예를 들어 외부 규제, 법률 (예: 사생활 침해), 안전도 규제 사항, 표준과 관계되는 사항을 기술 한다. '모든 정보는 ASCII 문자 집합으로 기술되어야 한다' 또는 '시스템은 명령이 떨어진 후 2초 내에 반응해 야 한다' 등은 그 예이다.*/ 8. 요약 (Summary) 9. 감사의 글 (Acknowledgments) 10. 부록 (Appendices) /*이 프로젝트와 관련하여 앞으로 향상될 수 있는 부분에 대하여 기록한다*/

Soongsil University Industrial and Information Systems Engineering

Similar presentations

Presentation on theme: "Soongsil University Industrial and Information Systems Engineering"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Soongsil University Industrial and Information Systems Engineering

Similar presentations

Presentation on theme: "Soongsil University Industrial and Information Systems Engineering"— Presentation transcript:

Similar presentations

About project

Feedback