The Preliminary Investigation

1

• The Preliminary Investigation
• The purpose of the preliminary investigation is
  to
• Determine if a project worth looking at
• Establish the project charter.

2

• The project charter includes
• Purpose Objectives of the System
• Preliminary requirements constraints
• Scope definition
• Project participants
• Budget and schedule

3

• Preliminary requirements
• A system (or business) requirement is a
  description of the needs and desires for an
  information system.
• A requirement may describe functions, features
  (attributes), and constraints.

4

• Types of requirement
• A functional requirement is a function or feature
  that must be included in an information system in
  order to satisfy the business need and be
  acceptable to the users.
• A nonfunctional requirement is a description of
  the features, characteristics, and attributes of
  the system as well as any constraints that may
  limit the boundaries of the proposed solution.

5

• Constraints
• Refer to time, money or resource limitations on
  the system.
• Limit the possible solutions
• Usually cannot be changed
• May relate to implementation issues
• networking requirements,
• user interface standards,
• existing platforms
• internal standards.

6

• The Purpose of a System.
• A high level statement of the aims or intention
  of the system
• A brief concise textual description of what the
  system will do.
• It is intended for management and user
  management.
• Strategies, tactics, objectives, inclusions and
  exclusions may be included.

7

• Example
•  
• The purpose of the new system is to track the
  sales of products from initial quotation to their
  installation. It will result in improved
  monitoring of quotation, sales and installation.
  The placement of manufacturing orders and
  invoicing of customers is to be included within
  this system.

8

• Objectives
• Objectives are measures of success
• The expected achievements of the system.
• They must be specified
• (this could be very difficult for large systems).
• Objectives should be clearly aligned with the
  businesss mission, strategies, and/or tactics.

9

• Examples
• Reduce the number of uncollectible customer
  accounts by 50 percent within the next year.
• Increase by 25 percent the number of loan
  applications that can be processed during an
  eight-hour shift.
• Decrease by 50 percent the time required to
  reschedule a production lot when a workstation
  malfunctions.

10
Object Oriented Analysis (OOA)
The Object Oriented Approach to Requirements
Analysis and Specification (Text Chap 11)
11
Object Oriented Analysis of a system yields

• A Use Case Model
• A set of Use Case Scenarios
• Activity Workflow Diagrams
• A Class Diagram with Business Objects
• A Use Case Dependency Diagram.
• Sequence or Interaction Diagrams
• Analysis models describe what a system must do.

12

• Object Orientation describes a system and its
  requirements by
• Identifying the objects in a system
• Identifying their processes (or methods,
  functionality)
• Identifying relationships between objects.
• The analysts mind is oriented towards finding
  objects (as opposed to processes or entities).

13

• What is an Object?
• A tangible or visible thing.
• A construct which combines data and behaviour
• Examples of objects
• Concrete My bicycle, Myself
• Conceptual A linked list, A polygon, Account
• Business Bank Account 34267 Invoice 98097
• VCR s/n9870123 Customer (Alex)
• Example of Objects in a banking system
• An Account A Teller A Branch
• A Customer A Transaction A Cheque

14
Example of Objects in a banking
system AccountTeller Branch Customer Transaction
15

• Important facts about objects
• Every object has an identity
• in the real world the object exists
• allows collections of mixed objects.
• Classification
• objects with the same attributes (data structure)
  and operations (behaviour) can be grouped into a
  class.
• an abstraction that describes properties relevant
  to an application.
• choice of classes is arbitrary.
• an object is an instance of a class.

16

• Key Concepts for OOA.
• The objects in an object model match the real
  world.
• Encapsulation (information hiding).
• combines data structure and behaviour in a single
  entity.
• separation of external from implementation
  details.
• supported in other paradigms but not as well as
  in OO
• Abstraction
• Proper use of abstraction (or techniques of
  abstractions) allow the same model to be used
  for
• Analysis High level design
• Program structure Database structure
• Documentation.

17

• Key Concepts for OOA (cont).
• d) Generalisation - specialisation
• Grouping classes into a super class is
  generalisation
• Breaking a class into subclasses is
  specialisation.
• e) Inheritance
• Sharing of attributes and operations based on a
  class hierarchy.
• Subclasses inherit all properties of their
  superclass.

18

• Why OOA?
• Availability and popularity of OO languages
• Object Oriented Software
• Organises software as a collection of discrete
  objects that incorporate both data structure and
  behaviour ie it combines both processes and
  data.
• Difficulty interpreting models from traditional
  methods
• Advantages inherent in the approach.

19

• Advantages of OOA
• Seamless
• The analysis, design and code models use the same
  concepts.
• Matches Real World
• Models are made which correspond to real things
  in the real world.
• Reuse
• Objects (or their class) often are used in other
  problem domains.

20

• Emphasis comparison to other techniques
• Structured Development focuses on system
  behaviour
• Information Engineering focuses on the data
  structure
• Object Oriented Development focuses on data
  structure and its class dependant behaviour ie
  behaviour of system is tied to data.

21

• Object Oriented Techniques
• Include Object Models, Use Cases, DFDs, ...
• Object modelling
• ER modelling emphasises Entity identification
  (classification) and the relevant associations.
• Object modelling adds generalisation/specialisatio
  n, aggregation, and methods..
• Object modelling shifts focus to identification
  of classes and subclasses.
• Relationships are of three types
• Association, Specialisation, Composition
• Shifts emphasis to include class structures
• Includes services or functions with data

22
Defining the Scope of a System
An initial step in requirements definition using
Object Oriented Techniques
23

• The Scope
• Identifies what belongs within a system and what
  is external to it
• Defines the interfaces between the proposed
  system and the rest of the universe.
• The scope of a project is what is to be included
  within the new system.
• The boundary between the system under study and
  the outside world defines the scope of a project,
  setting the boundary is crucial.

24

• To document the scope
• List the Objectives of the system.
• Prepare a Statement of Purpose
• Prepare a Context Diagram
• Prepare an Event Table (or list).
• Prepare a Use Case Diagram.
• Document the Scenarios for the events.

25
1. Develop context diagram and identify events
26

• The Context Diagram (p 85-86, 204-206)
•  
• What it will show
•  
• Data from the outside which will be used by the
  system (inputs).
•  
• Data produced by the system and sent out
  (outputs).
•  
• People, organisations, or systems which will
  communicate with the system (the terminators).

27

• 2. Prepare an Event Table (or List). (p 158-169)
• The Event Table is a list of all events in the
  environment to which the system must respond.
• This list helps identify data flows in out of
  the system.

28

• Examples of events
• The manager requires a monthly production
  statement.
• A customer orders products.
• Manager changes production schedule.
• Stock quantity on a product falls below
  acceptable levels.

29

• Events and System Requirements
• Events
• Occurrences at a specific time and place
• Trigger all system processing
• For a Requirements definition
• Determine relevant events
• External events first
• Temporal events second
• Decompose system into manageable units

30
Events Affecting a Charge Account Processing
SystemFigure 5-6
Systems Analysis and Design in a Changing World,
2nd Edition, Satzinger, Jackson, Burd
31
Types of Events

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

Systems Analysis and Design in a Changing World,
2nd Edition, Satzinger, Jackson, Burd
32
External Event ChecklistFigure 5-7
Systems Analysis and Design in a Changing World,
2nd Edition, Satzinger, Jackson, Burd
33
Temporal Event Checklist Figure 5-8
Systems Analysis and Design in a Changing World,
2nd Edition, Satzinger, Jackson, Burd
34
Identifying Events

• Can be difficult to determine
• Often confused with conditions and responses
• May be useful to trace a transactions life cycle
• Certain events left to design phase
• Systems controls
• Perfect technology assumption

Systems Analysis and Design in a Changing World,
2nd Edition, Satzinger, Jackson, Burd
35
Sequence of Actions that Lead up to Only One
Event Affecting the SystemFigure 5-9
Systems Analysis and Design in a Changing World,
2nd Edition, Satzinger, Jackson, Burd
36
The Sequence of Transactions for One Specific
Customer Resulting in Many Events Figure 5-10
Systems Analysis and Design in a Changing World,
2nd Edition, Satzinger, Jackson, Burd
37
Events Deferred Until the Design PhaseFigure 5-11
Systems Analysis and Design in a Changing World,
2nd Edition, Satzinger, Jackson, Burd
38
Documenting Information Events in an Event
TableFigure 5-14
Systems Analysis and Design in a Changing World,
2nd Edition, Satzinger, Jackson, Burd
39

• 3. Prepare a Use Case Diagram.
• The actions taken for the events are the Use
  Cases
• Use Cases.
• A Use Case is a related sequence of steps, both
  automated and manual, for the purpose of
  completing a single business task.
• Use Case modelling is the process of identifying
  and modelling business events, who initiated them
  and how the system responds to them.
• Use cases correspond to the events in an event
  list, only it is from the perspective of the
  process performed to respond to the event.
• Examples of use cases in a banking system
• Withdraw funds Accept Deposit Funds
• Secure a Loan Open an Account.

40
A Use Case
41
(No Transcript)
42

• The Use Case Diagram.

The use case diagram groups the individual use
cases into subsystems. The diagram shows use
cases and the actor which initiates the use case.
Figure 7-4 (from Text)
43
4. Document the Scenarios for the events.
Narrative form of a Use Case Scenario
Figure 7-8 from text Two scenarios for Create
New Order
44
Data Flow Diagramsp 198-219A common Modeling
technique used for process Modeling
45

• 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).

46
The Context DiagramA data flow diagram used to
show the boundary of a system an the systems
interactions with its environment.
47
Example of a Top Level DFD
48
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.
49

• 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.

50

• 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.

51

• 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.

52

• 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
53

• 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

54
A Data Flow Fragment (Event Diagram)
55

• 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.)

56

• 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

57

• 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)

58
A Data Flow Fragment (Event Diagram)
59

• 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)

60
DFD Fragments laid out grouped
61
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.
62
Bottom Level Diagrams provide a detailed view of
each part of the system.
63

• 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

64

• 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

65

• 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

66

• But data is not conserved in the following

67

• 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)
68

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

What is missing in this diagram?