1. 44222: Information Systems Development Prototyping & The Problem Statement Ian Perry Room: C49 Extension: 7287 E-mail: I.P.Perry@hull.ac.uk http://itsy.co.uk/ac/0405/Sem1/44222_ISD/

2. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 2 Prototyping - a Definition "The process of building an experimental system quickly and inexpensively for demonstration and evaluation so that users can better determine information requirements." Management Information Systems (Laudon & Laudon 3rd Ed 1994)

3. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 3 The Prototyping Method Identify Basic Requirements Develop First "rough cut" prototype Present to User Problems? Revise & Enhance Next version of the prototype

4. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 4 Prototyping Philosophy  Prototyping is a philosophy of development; An organisational rather than a technical issue.  You do not need any special hardware or software in order to Prototype effectively; You all have a brain – don’t you?

5. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 5 Prototyping Approach  Using a Prototyping Approach we; build a series of models to establish and confirm user requirements.  These Prototypes may be: Throw-Away Evolutionary  Throw-Away Prototyping can be very time- consuming, so; try to make the transition to Evolutionary Prototyping as soon as possible.

6. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 6 As a student you really should be Prototyping everything!  Prototyping Documentation is: always having something to hand in.  Prototyping the User Interface is: always having choices to offer the User.  Prototyping Functionality is: always having something "working".  Prototyping a Presentation is: always having something to demonstrate.

7. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 7 The Problem Statement  Purpose To document problems & information requirements in terms of what NOT how.  Audience Managers who work for the ‘Main Business’ of HCHE.  This is DEFINITELY NOT a technical document!

8. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 8 Presentation, Structure & Language (20 Marks)  Document should be in a loose report format, e.g.: Introduction, Body, Conclusion.  and be between 5 and 8 pages (maximum) long.  It should provide a brief description of the organisation, its problems and functional & information requirements in a clear, consistent, complete and yet concise way. The Managers who work for the ‘Main Business’ of HCHE MUST be able to understand the report since they need to confirm that it accurately defines their problems, and promises viable solutions.

9. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 9 Understanding of Problems (60 Marks)  The Document should provide a clear statement of the problems faced by the management of HCHE, i.e. translate both the HCHE Case Study and the giddens, stanworth + hope (gs+h) reviews into a valid set of information requirements.  You MUST, therefore, produce a document which demonstrates; a clear understanding of specific problem areas (i.e. those relevant to the managers who are the audience for this report), and explains the role that management information could play in alleviating these problems (i.e. match problems to decisions and hence identify information requirements).

10. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 10 Realism (20 Marks)  Your analysis of the problems, and functional & information requirements should demonstrate business realism. Your document MUST, therefore, be realistic about what the management of ‘HCHE’ should do, can do, & want to do.  Use the Interview opportunity wisely! The Interviews will take place during next week’s Workshop sessions. So, use this week’s Workshop session in order to prepare for your Team’s Interview.

11. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 11 Prototyping the Problem Statement  Document Structure Introduction A brief re-statement of the important parts of the ‘HCHE’ Case Study. Body Identify a specific Problem;  and discuss specific Information Requirements that will help a specific Manager resolve the problem. Repeat for ALL Problems. Conclusion Might best be expressed in a tabular format, and should;  match solutions to problems for specific users.

12. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 12 Prototype as a Team  The eventual ‘users’ of your Problem Statement will be the Management of ‘HCHE’, however; you only have ONE opportunity to present a prototype of this document to those managers.  Therefore, in order to develop a good prototype, you will have to act as ‘users’, by; presenting subsequent iterations of your prototype Problem Statement to the other members of your Team.

13. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 13 Always Remember This!  More Iterations = Better Prototype

14. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 14 And This!  Prototyping Documentation is: always having something to hand in.  Prototyping the User Interface is: always having choices to offer the User.  Prototyping Functionality is: always having something "working".  Prototyping a Presentation is: always having something to demonstrate.

15. Ian Perry Information Systems Development: Prototyping & The Problem Statement Slide 15 This Week’s Workshop  Use this week’s workshop session in order to have another look at the ‘HCHE’ Case Study as a Team, so that you all agree: what IS, and what IS NOT important, i.e. which parts of the case study you really need to analyse further.  Then come up with a single set of questions that you want to ask the ‘HCHE’ Case Study characters next week. make sure that you all know/understand(?) why you are going to ask each question.  The case study is intentionally complex, sometimes contradictory, and may be confusing: so make sure that you think of questions this week that will clear things up for you during next week’s Interview.