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

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 (p49-50, 198)
•  
• 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 161-163)
• 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-8 (from Text)
43
4. Document the Scenarios for the events.
Narrative form of a Use Case Scenario
Figure 7-3 from text Two scenarios for Create
New Order