System Analysis Overview

1
System Analysis Overview

• Document functional requirements by creating
  models
• Two concepts help identify functional
  requirements in the traditional approach and
  object-oriented approach
• Events that trigger use cases
• Things in the users work domain

2
Models and Modeling

• Analyst describes information system requirements
  using a collection of models
• Complex systems require more than one type of
  model
• Models represent some aspect of the system being
  built
• Process of creating models helps analyst clarify
  and refine design
• Models assist communication with system users

3
Why modeling?

• Learning from modeling process
• Reduce complexity by abstraction
• Remembering the details
• Communicating with other team members, users, and
  stakeholders
• Documenting what was done for future
  maintenance/enhancement

4
Types of Models

• Different types of models are used in information
  systems development
• Mathematical formulas that describe technical
  aspects of the system
• Descriptive narrative memos, reports, or lists
  that describe aspects of the system
• Graphical diagrams and schematic
  representations of some aspect of the system

5
Events

• Business events trigger elementary business
  processes (EBPs)
• EBPs are at correct level of analysis for use
  cases
• Business events are memorable, can be described,
  and occur at a specific time and place

6
Sequence of Transactions for One Specific
Customer Resulting in Many Events
7
Types of Events

• External
• Outside system
• Initiated by external agent or actor
• Temporal
• Occur as result of reaching a point in time
• Based on system deadlines
• State
• Something inside system triggers processing need

8
Events Affecting a Charge Account Processing
System
9
Events modeling

• Identify business events to decompose system into
  activities/use cases
• Use cases (activities) are identified from user
  goals and business events that trigger elementary
  business processes
• Event decomposition is, therefore, used by
• Traditional approach to identify activities
• OO approach to identify use cases
• Event table records event, trigger, source, use
  case, response, and destination

10
Information about Each Event in an Event Table
11
Things

• Things are what user deals with and system
  remembers, such as an order placed by a customer
• Analysts identify these types of things by
  considering each use case in the event table
• What things does the system need to know about
  and store information about?

12
Types of Things
13
Modeling things

• Traditional approach uses entity-relationship
  diagrams (ERD) for data entities, attributes of
  data entities, and relationships between entities
• Object-oriented approach uses UML class diagrams
  for classes, attributes, methods of class, and
  associations among classes

14
Traditional and OO Approach
15
Components of a Traditional Analysis Model
16
Data Flow Diagrams (DFDs)

• Graphical system model that shows all main
  requirements for an IS in one diagram
• Inputs/outputs
• Processes
• Data storage
• Easy to read and understand with minimal training

17
Data Flow Diagram Symbols
18
(No Transcript)
19
(No Transcript)
20
DFD Integrates Event Table and ERD
21
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

22
Layers of DFD Abstraction for Course Registration
23
Context Diagrams

• DFD that summarizes all processing activity for
  the system or subsystem
• 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

24
Context Diagram
Data Flow
External entity
Data Flow
External entity
The System
Data Flow
Data Flow
External entity
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
DFD Fragments

• Created for each use case in the event table
• Represent system response to one event within a
  single process symbol
• Self-contained models
• Focus attention on single part of system
• Show only data stores required in the use case

29
Three Separate DFD Fragments for Course
Registration System
30
Event-Partitioned System Model

• DFD to model system requirements using single
  process for each use case/activity in system or
  subsystem
• Combines all DFD fragments together to show
  decomposition of the context-level diagram
• Sometimes called diagram 0
• Used primarily as a presentation tool
• Decomposed into more detailed DFD fragments

31
Combining DFD Fragments to Create Event-
Partitioned System Model
32
Decomposing DFD Fragments

• Most DFD fragments can be further described using
  structured English
• Sometimes DFD fragments need to be diagrammed in
  more detail
• Decomposed into subprocesses in a detailed DFD

33
Layers of DFD Abstraction for Course Registration
34
DFD Practice

• Precision tools sells a line of high-quality
  woodworking tools. When customers place orders on
  the companys web site, the system checks to see
  if the items are in stock, issues a status
  message to the customer, and generates a shipping
  order to the warehouse, which fills the order.
  When the order is shipped, the customer is
  billed. The system also produces various reports.

35
DFD Practice

• Draw a context diagram
• System scope is represented by a single process,
  external agents, and all data flows into and out
  of the system
• Draw Level-0 diagram
• Identify the major use cases
• Draw DFD fragment for each use case
• Combine DFD fragments together at the same level
  of detail

36
Context Diagram
37
Five Separate DFD Fragments
38
Detailed DFD for Create new order
39
Evaluating DFD Quality

• Readable
• Internally consistent and balanced
• Accurately represents system requirements
• Reduces information overload rule of 7 /- 2
• Minimizes required number of interfaces

40
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

41
Consistency Rules

• All data that flows into a process must
• Flow out of the process, or
• Be used to generate data that flows 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

42
Unnecessary Data Input Black Hole
43
Process with Impossible Data Output A Miracle
44
Process with Unnecessary Data Input
45
Process with Impossible Data Output
46
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

47
Structured English

• Method of writing process specifications
• Combines structured programming techniques with
  narrative English
• Well-suited for 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

48
Structured English Process Description
49
(No Transcript)
50
Decision Tables and Decision Trees

• Can summarize complex decision logic better than
  structured English
• Incorporate logic into the table or tree
  structure to make descriptions more readable

51
Decision Tables
52
Decision Tree
53
Decision Tables for Calculating Shipping Charges
54
Decision Tree for Calculating Shipping Charges
55
Data Flow Definitions

• Textual description of data flows content and
  internal structure
• Often coincide with attributes of data entities
  included in ERD plus computed values
• Algebraic notion describes data elements on data
  flow plus data structure

56
Data Element Definitions

• Data type description
• String, integer, floating point, Boolean
• Sometimes very specific written description
• Length of element
• Maximum and minimum values
• Data dictionary repository for definitions of
  data flows, data stores, and data elements

57
Data Element Definition
58
Physical and Logical DFDs

• Logical model
• Assumes implementation in ideal situation
• Does not tell how system is implemented
• Physical model
• Describes assumptions about implementation
  technology
• Developed in last stages of analysis or in early
  design
• Current physical -gt Current logical -gt New
  logical -gt New physical

59
Summary

• Data flow diagrams (DFDs) are 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

60
Assignment 2

• Draw a context diagram of the proposed student
  housing system
• Draw a level-0 data flow diagram. Specify the
  main functions of the system (data flow, process,
  and data store).
• Draw a level-1 data flow diagram for the process
  of student searching for houses.
• Use of drawing tools

61
http//www.homes4students.ca/add_a_listing.html
62
http//www.homes4students.ca/ontario.html