INFO1002 Systems Modelling Lecture 10 Establishing User Requirements Department of information Systems.

INFO1002Systems Modelling

Lecture 10Establishing User Requirements

Department of information Systems

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

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

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.

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.

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

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

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

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

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.

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

Summary

– There are 5 main fact finding techniques useful in systems Investigation

• Sampling

• Questionnaires

• Interview

• Research

• Observation

References

• Bennett et al Ch 5

• Hoffer et al pages 239-276

INFO1002Systems Modelling

Lecture 11Events

Department of information Systems

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

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

• Events Trigger all the processing a system does.

• There are three types of event:– External– Temporal– State

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.

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)

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)

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.

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

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.

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.

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

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?

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

6. Customer rings to order flowers

7. Customer turns up

8. Clerk find room number gives key to room

9.Clerk records room as occupied10 Customer leaves

11. Bill calculated

12. Customer pays bill

13 clerk records room now empty and customer paid

Customer Makes Booking

Customer Orders service

Customer Checks in

Customer Checks out

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

INFO1002Systems Modelling

Lecture 12Drawing an Event Table

Department of information Systems

Objectives

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

Looking at each event

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

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.

Events Table

• Source– For external events only– Usually the actor– In other words who is supplying the data which

will be typed in

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

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”

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

Example from hotelEvent 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

Summary

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

References

• Satzinger et al ch 5 pages 153-163

• Study the event table built for the Rocky Mountain Case study