Systems Analysis

1
Systems Analysis Design

• Systems Analysis determining the requirements
  for a system
• What the system must do.
• Systems Design designing a system that meets the
  requirements
• How the system will do it.
• The phrase Systems Analysis and Design refers
  to an ordered process for the development of
  system.
• Came about though early failures to build systems
  in an ad-hoc manner.

2
Why do we need Systems Analysis Design?

• Large numbers of IS projects fail
• A study of well run organisations
• 10 of IS projects 100 over budget.
• A study of 600 companies
• 30-35 of IS projects are runaways
• A study by Yourdon (1992)
• 50 of IS projects at least 1 year late 100
  over budget.
• And worse
• Projects are frequently abandoned only when funds
  are nearly exhausted.

3
The Results

• Lost credibility
• Wasted funds
• Lost business opportunity
• Low morale
• Possible bankruptcy

4
Why do projects fail?

• Working without a clear set of specifications
• Lack of user involvement/agreement
• Lack of planning
• Poor estimation of resources required
• Poor documentation of decisions
• Premature coding
• Lack of quality assurance
• Staff turnover
• Over-manning in a crisis
• Inadequate knowledge of tools and or techniques

5
But also

• Requirements change throughout development
• (Scope Creep)
• Productivity levels vary widely
• Estimation techniques are poorly developed
• IS staff have distinct personality profiles

6
Can We Improve?

• Building IS systems has a short history,
• Maybe we just need to learn how to do IT!

7
Successful Projects

• The success of a project is measured by its
  ability
• To meet the expressed requirements
• To meet the needs of the client/user
• To be completed on time and within budget.

8
How?

• Applying rigor to development projects
• Researching successes and failures
• Collecting statistics
• Applying sound System Analysis and Design
  Principles
• Use of Modeling Techniques
• Use of Methodologies

9

• Models
• Are a representation of reality
• Analysts describe 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

10
Reasons for ModelingFigure 5-2
Systems Analysis and Design in a Changing World,
2nd Edition, Satzinger, Jackson, Burd
11

• 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

12

• Logical models show what a system does.
• Independent of implementation
• Referred to as essential models, conceptual
  models or business models.
• Mainly used in requirements definition
• (Models used in this subject will mostly be
  logical models)

13

• Physical models show how ( what) a system does.
• Implementation dependant
• Referred to as implementation models or technical
  models.
• Mainly used in the design phase

14
Data Flow Diagramsp 195-212A common Modeling
technique used for process Modeling
15

• Data Flow Diagrams (DFDs)
•  
• A data flow diagram depicts the flow of data
  through a systems and the processes performed by
  the system.
•  
• DFDs are a commonly used Modeling tool
•  
• Business planning, Business Process Redesign
•  
• Elements of the system connected by data flows.
•  
• Processes are identified (but not defined).

16
Example of a Top Level DFD
17
Levelling Balance across DFD Levels
Parent (Partial diagram)
Expansion of Process 3.0
DFDs allow one to have high level abstract views
of a system or a very detailed view.
18

• The Symbols and Components for DFD's
•  
• DATA FLOWS
•  
• Show the flow of data (eg bits, characters etc,
  often as a form) from one part of the system to
  another.

19

• PROCESS
•  
• The part of a system that transforms inputs into
  outputs.
• A process is shown as a uniquely numbered and
  named circle or bubble.
•  
• The name should be meaningful and apply to the
  process performed.

20

• DATA STORE
•  
• Models a collection of data "at rest". Often this
  data resides in a database. A data store may
  represent several entities.
•  
• A unique name is given to data packets that are
  carried by flows into and out of the store.

21

• ACTOR or TERMINATOR
•  
• Represent systems or things with which the system
  communicates or interacts with in its
  environment.
• Shown as a uniquely named rectangle, but
  multiples can be used
•  
• The analyst/designer has no control over
  terminators because they are external to the
  system under study.
•  
• Also referred to as sources, sinks, or external
  agents

Supplier
22

• Data flow fragment (Event Diagram).
•  
• Model the response to an event
• Used to gain an initial understanding of a
  process
• Are the starting point for creating a complete
  set of DFDs for a system

23
A Data Flow Fragment (Event Diagram)
24

• Data flow fragments (How to create one).
•  
• Name the bubble by describing the response to the
  associated event.
• Connect the data flows that are required for each
  event.
• Prepare a preliminary description of the process.
• Identify the data elements on each data flow.
• Identify the required data stores and add them to
  the diagram. Use the data flows to determine the
  data stores required. (The data model should be
  developed in parallel with DFDs.)

25

• Creating Data flow diagrams.
• Two common techniques for generating DFD's are
  used
• Event Driven
• Based on the identified events
• Top Down
• Based on the decomposition of business processes
  from the top level down

26

• The event driven approach or middle out approach
• Create an Event List
• An event list is a list of all events in the
  environment to which the system must respond.
• For each event in the event list, prepare an Data
  flow fragment (Event Diagram).
• Name the bubble by describing the response to the
  associated event.
• Connect the data flows that are required for each
  event.
• Prepare a preliminary description of the process.
• Identify the data elements on each data flow.
• Identify the required data stores and add them to
  the diagram.
• Use the data flows to determine the data stores
  required. (The data model should be developed in
  parallel with DFDs.)
• (Text p196-197)

27
A Data Flow Fragment (Event Diagram)
28

• Build the first-cut, leveled, DFD's.
• Place all event diagrams on a large sheet
• Place diagrams using similar data stores close
  together.
• Stores should be created for communication
  between bubbles.
• Check the diagram for completeness against the
  context diagram and the event list.
• Identify groups of processes that seem to either
  be working with the same data or actions in the
  system.
• Each group becomes a single process for a higher
  level diagram. Each group itself becomes a single
  lower level diagram.
• (Text p 198, 200-206)

29
DFD Fragments laid out grouped
30
The groupings on the Top Level Diagram will match
those of the Use Case Model. Top level diagrams
provide a high-level view of a system.
31
Bottom Level Diagrams provide a detailed view of
each part of the system.
32

• 4. Other Guidelines for Preparing DFDs
• (Text, p208-212)
• Choose meaningful (and unique) names for
  processes, flows, stores and terminators
• Number the processes consistently
• Redraw the DFD as many times as necessary to get
  it right
• replace physical references with logical names.
• group processes at lower levels into more logical
  functions.
• Avoid overly complex DFDs

33

• 5. Data Flow Conventions. (Text, p208-212)
• Data flows only occur
• between two processes
• from a data store to a process
• from a process to a data store
• from a process to a sink
• from a source to a process
• Data flows do not occur
• from a data store to a data store
• from a data store to a sink
• from a source to a data store
• from a source to a sink

34

• Data Conservation
• What comes out of a data store must go in.
• (a data store cannot create new elements nor
  should it store unused elements).
• Data is conserved in this example

35

• But data is not conserved in the following

36

• Other data conservation problems
• No infinite sinks (inputs but no outputs),
• No spontaneous bubbles (outputs but no inputs),
• Beware "read-only or write-only" stores

(note for data stores check the whole system)
37

• A process can not create new data.
• (it can only be transformed or output again).

What is missing in this diagram?