1. 44222: Information Systems Development Documenting a Solution Ian Perry Room:C41C Extension:7287 E-mail:I.P.Perry@hull.ac.uk http://itsy.co.uk/ac/0708/Sem1/44222_ISD/

2. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 2 Assignment 2 – is all about exploring/documenting HOW: How Decisions will be ‘improved’. How Information will be ‘presented’. How Data will be ‘used’. How Problems will be ‘solved’.

3. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 3 Prototype Documentation  Keep your Audience in mind! Managers who work for the ‘Main Business’ of HCHE, and the IT Section Manager.  Purpose To define the proposed information system in such a way that; the Managers who work for the ‘Main Business’ of HCHE say "this system should be implemented“ (i.e. Malcolm et. al.). the IT Section Manager says "we could implement it“ (i.e. Dave Perkins).

4. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 4 Marking Guidelines (1)  Presentation and Structure (25 Marks) Should be presented and structured so that it can meet its dual purpose and satisfy its dual audience, i.e.: the Managers who work for the ‘Main Business’ can agree to the objectives and style of the system. the IT Section Manager can understand what has been agreed to and would be able to implement it.

5. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 5 Marking Guidelines (2)  Interface & Functional Requirements (75 Marks) This documentation should describe a system that would address ALL of the problems highlighted by the Problem Statement. This definition should clearly show what the system would do and, broadly speaking, how it would do it. It should document the user interface and its functional aspects in a way appropriate to the Management Representatives and the IT Section Manager.

6. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 6 Marking Guidelines (3)  The document MUST, therefore, include enough detail so that it: indicates the overall structure of the system; i.e. which screen is connected to which. describes the interface and functionality in diagrammatic, narrative or other form; i.e. screen appearance and operation.

7. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 7 Marking Guidelines (4)  And also: matches the proposed solution to specific 'problems'; i.e. 'solves' the problems highlighted by the Problem Statement. matches the 'information' displayed on screen to data that is maintained by the current operational systems; i.e. the source of all data MUST be explained for the benefit of the IT Section Manager.

8. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 8 Possible Document Structure (1)  One Screen at a time, described for the dual audience: Screen Shot; with example data (information?). Information Provided/Decisions Supported; i.e. ‘problems’ solved (for Malcolm et. al). Where the Data comes from, and calculations grouping/sorting required; i.e. how to implement the prototype (for Dave Perkins).  Advantages/Disadvantages: Advantage - Screen Shots only required once. Disadvantage - Might be difficult for your dual audience to know which parts of the document are aimed at them.

9. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 9 Possible Document Structure (2)  Two Sections, each for a specific audience: Screen Shot & Information Provided/Decisions Supported; i.e. ‘problems’ solved (for Malcolm et. al.) Screen Shot, where the Data comes from & calculations grouping/sorting required; i.e. how to implement the prototype (for Dave Perkins)  Advantages/Disadvantages: Advantage - Easy to separate your discussion for the dual audience. Disadvantage - Need to repeat Screen Shots.

10. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 10 Possible Document Structure (3)  Three Sections, one ‘common’ for both audiences: All ‘common’ Screen Shots in an Appendix. Information Provided/Decisions Supported; i.e. ‘problems’ solved (for Malcolm et. al.) Where the Data comes from & calculations grouping/sorting required; i.e. how to implement the prototype (for Dave Perkins)  Advantages/Disadvantages: Advantage - Easy to separate your discussion for the dual audience. Disadvantage – Appendix of Screen Shots will need to be very well organised/labelled, so that it can be effectively referenced for the dual audience.

11. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 11 Possible Document Structure (4)  Something else? Don’t feel constrained by my suggestions.  If you begin the production of your Prototype Document early enough, then you can; try out a number of different document structures,  and; pick the one that you (i.e. the Team) feel ‘works’ best.

12. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 12 Blank ‘Screens’ are Useless (1)  Use ‘fairly extreme’ examples, e.g.: If you are trying to show that some stock sells well; and perhaps we don’t hold enough of these stock items. Whilst other stock does not sell well; tying up cash unnecessarily. Then: make sure that the data values you choose make this distinction very clear.

13. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 13 Blank ‘Screens’ are Useless (2)  When presenting/discussing related screens; it is a good idea to try to tell a consistent ‘story’, e.g.: If you want to show that your system can; identify good/bad customers. Then, make sure that; the same customers are good/bad on all Screens which investigate this.

14. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 14 Blank ‘Screens’ are Useless (3)  The data displayed should be ‘sorted’ in different ways, for maximum impact, e.g.: if assessing good/bad customers you could sort their data by; Outstanding Balance, Amount over Credit Limit, Average Days Taken to Pay, Oldest Outstanding Invoice, etc.

15. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 15 This Week’s Workshop  Hopefully, by now, each Team has: started to think how the information ‘promised’ by their Problem Statement might best be organised/presented. chosen the software application(s) with which they intend to build their Screens for inclusion in the Prototype Document.  Start NOW! START building the Screens for your prototype information system. START thinking how you will document this prototype.

16. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 16 Remember to Prototype! Identify Basic Requirements Develop First "rough cut" prototype Present to User Problems? Revise & Enhance Next version of the prototype More Iterations = Better Prototype

17. Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 17 Next Week!  There is NO Lecture! There will, however, be a ‘Workshop’ session.  During next week’s Workshop session; each Team will have an opportunity to Interview some of the HCHE case study characters.  I am not, as yet, sure if ALL of the managers will be able to make it to these Interviews, however: Malcolm & Dave will be ‘there’.  Make sure to make the most of this opportunity: have your questions prepared in advance, don't just 'wing-it' on the day. the Managers are very busy, so each interview will last 15 minutes MAXIMUM.