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 • Customer contact the Hotel for free room • Clerk checks room availability • Customer gives name and address • Customer pays deposit • 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

37. Example from hotel

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