INFO1002 Systems Modelling

1
INFO1002Systems Modelling

• Lecture 10
• Establishing User Requirements
• Department of information Systems

2
Objectives

• At The end of this section you will be able to-
• Describe the 5 main techniques for fact finding
• Understand the advantages and disadvantages of
  each technique

3
User requirements

• At first we know nothing about what the users
  want
• .and maybe a little about the organisation
• This may be any business area
• We need to find out about
• Their circumstances including constraints
• Their problems
• What they want

4
What we need to achieve

• The goal is simple to learn enough to develop a
  computerised IS that will be useful to
• These specific users, in..
• These particular circumstances, with
• These unique problems
• We must also document what we learn, so others
  can access our knowledge.

5
User requirements

• What is useful depends on the type of information
  that matters to the users
• We may need to capture details of
• Timing and sequence
• Data (relationships between and structure)
• Processes
• Other aspects e.g. user issues, legislative and
  safety factors
• We use fact finding techniques to do this.

6
Fact Finding Techniques

• S.. For Sampling (existing documents)
• Q.. For questionnaires
• I.. For Interviewing
• R.. For Research ( background reading)
• O.. For Observation
• Not in order of importance, or sequence

7
Interviewing

• Most widely used Technique
• Often done top down through the organisation
• Very flexible ( Can be tailored to each
  individual user)
• Can probe when necessary
• Requires skill and sensitivity on part of
  interviewer
• Can be time consuming

8
Sampling

• Almost always used
• Can be used to support other techniques
• Adds further details to information already
  gathered
• Can resolve errors and ambiguities
• Identifies precise data content and structures
• Confirms sequence of input/output
• Identifies flow of work from one user to another

9
Research (Or Reading)

• Particularly useful at the start of the project
• Official company reports can give an overview of
  the company and system
• Company organisation chart can help identify
  users helping interview planning
• External sources can give ideas for solution to
  problems e.g. journals

10
Observation and Questionnaires

• Less widely used
• Observation can
• Confirm the detail of complex processes
• Resolve conflicting stories ( Check what really
  happens not what people think happens)
• Questionnaires useful where
• Large user base
• Geographically dispersed users
• As a starting point for following up with
  interview etc
• Caution a questionnaire is difficult and time
  consuming to design, use and analyse.

11
Establishing user Requirements

• At the start we know nothing at all
• By the end we have
• Decided more or less what matters
• Found out what the users want
• Recorded this in a useful way

12
Summary

• There are 5 main fact finding techniques useful
  in systems Investigation
• Sampling
• Questionnaires
• Interview
• Research
• Observation

13
References

• Bennett et al Ch 5
• Hoffer et al pages 239-276

14
INFO1002Systems Modelling

• Lecture 11
• Events
• Department of information Systems

15
Objectives

• At The end of this section you will be able to-
• Explain what is meant by an Event
• Identify events that trigger the system

16
Events

• Having carried out our Fact finding we must
  record what we know in an unambiguous way, so we
  or others may refer to it i.e. develop a model.
  One approach to this is to identify the events
  which will affect the system.
• An occurrence at a specific time and place that
  can be described and is worth remembering
• Satzinger 2002

17

• Events Trigger all the processing a system does.
• There are three types of event
• External
• Temporal
• State

18
External events

• Is an event that occurs outside the system
  usually initiated by a person (often called an
  actor)
• The system is required to record details about
  this event eg customer places an order
• Or the system is required to produce something
  in response to the request eg customer rings to
  ask if order has been sent.

19
Actors

• The people who initiate these responses from the
  system are called actors.
• They are carrying out a role (hence actor)
• When you place an order you are taking the role
  of a customer, if you are requesting management
  information you are taking the role of a
  particular job task. You could be both hence we
  use the term actor ( more later on this)

20
Typical external events

• Actor wants some information (e.g. customer
  enquires about an order they have placed)
• Data needs to be updated (e.g. employee changes
  address)
• Management wants some information (e.g. manager
  want to know who has holidays booked)
• Actor wants something that the system must record
  i.e. a transaction (e.g. customer places order)

21
Temporal Events

• These are events triggered by a specific time
  being reached.
• Many systems produce daily, weekly, monthly and
  annual reports. These reports are triggered when
  a specific date and time are reached.
• Some events are triggered after a certain amount
  of time has passed e.g. reminder produced 2 weeks
  after the bill was sent.

22
Typical Temporal Events

• Internal outputs required
• Management reports (e.g. summary of all orders)
• Operational reports (detail of daily operation)
• Internal statements and documents (including
  payroll)
• External outputs required
• E.g. Statements,bills and reminders

23
State events

• Occur when the system reaches a certain state.
  Triggers some response by the system when a
  particular condition becomes true. Similar to
  Temporal except that the time cannot be defined.
• EG reorder stock because the number in stock has
  reached a certain value known as the re-order
  level or send out a letter because a bank
  customer has gone overdrawn.

24
Identifying Events

• Can be difficult
• Following the process through can identify the
  sequence of events. If there is no time delay
  between two or more interactions then they are
  the same event, otherwise they are different
  events.

25
Events we are not interested in

• The Analyst is not interested in events that the
  do not normally concern the users .
• These are dealt with during Design
• Logging on
• Passwords
• Backups
• The other type of events we are not interested in
  just yet are the error routines
• It helps to think that everything is perfect and
  concentrate on events that are required in a
  perfect world

26
Example Look at the following sequence of
occurrences at a hotel- identify the events

• Look for things that occur together without any
  time delays
• What are the events ?
• What do they involve?
• What would you call the events?

27
Answers
Customer Makes Booking

1. Customer contact the Hotel for free room
2. Clerk checks room availability
3. Customer gives name and address
4. Customer pays deposit
5. Clerk updates system to show room booked

Customer Orders service
6. Customer rings to order flowers
Customer Checks in
7. Customer turns up 8. Clerk find room number
gives key to room 9.Clerk records room as
occupied
Customer Checks out
10 Customer leaves 11. Bill calculated 12.
Customer pays bill 13 clerk records room now
empty and customer paid
28
Summary

• An event is something that occurs in the real
  world that triggers processing in the computer
  system
• External Events
• Temporal events
• State events
• References See next lecture references

29
INFO1002Systems Modelling

• Lecture 12
• Drawing an Event Table
• Department of information Systems

30
Objectives

• At the end of this section you will be able to-
• Draw an events table

31
Looking at each event

• For each event the analyst must determine the
• Trigger
• Source
• Activity/Use Case
• Response
• Destination

32
Trigger

• How does the system know the event has occurred?
• For external events data enters the system
• For temporal it is the date or time
• For state events it is the condition has been met.

33
Events Table

• Source
• For external events only
• Usually the actor
• In other words who is supplying the data which
  will be typed in

34
The events table

• Activity or Use Case
• What process does the system carry out in
  response to the event trigger ?
• Response
• What output (if any) is produced by the system
• Destination
• What actor gets this output

35
Building an event table

• A table can be build using one row for each event
• Using the hotel booking example we can build a
  table
• Starting with Customer makes booking

36
Example from hotel
Event Trigger Source Use Case Response Destination
Customer makes Booking Customer inquiry Customer Create new booking Room Booking confirmation Customer and clerk

37
Example from hotel
Event Trigger Source Use Case Response Destination
Customer makes Booking Customer inquiry Customer Create new booking Room Booking confirmation Customer and clerk
Customer orders service Customer order Customer Order service
Customer checks in Customer arrives customer Check in
Customer Checks out Customer checks out customer Check out Print bill Customer
38
Summary

• When we have identified an event we must also
  identify its
• Trigger
• Activity
• Response
• Source and/or Destination

39
References

• Satzinger et al ch 5 pages 153-163
• Study the event table built for the Rocky
  Mountain Case study