44222: Information Systems Development Documenting a Solution Ian Perry Room:C49 Extension:7287

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

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: Managers who work for the ‘Main Business’ of HCHE say "this system should be implemented“ (i.e. Malcolm et. al.). IT Section Manager says "we could implement it“ (i.e. Dave Perkins).

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

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.

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.

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.

Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 8 Possible Document Structure (1)  One ‘big’ Section: Screen Shot. Information Provided/Decisions Supported (for Malcolm et. al). Where does the Data come from, and what calculations grouping/sorting are required (for Dave Perkins).  Advantages/Disadvantages: Advantage - Screen Shots of Forms only required once. Disadvantage - Might be difficult for your dual audience to know which parts are aimed at them.

Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 9 Possible Document Structure (2)  Two ‘smaller’ Sections: Information Provided/Decisions Supported; i.e. ‘problems’ solved (for Malcolm et. al.) Where does the Data come from, and what calculations grouping/sorting are required; i.e. how to implement the prototype (for Dave Perkins)  Advantages/Disadvantages: Advantage - Easy to separate you discussion for the dual audience. Disadvantage - Need to, either repeat Screen Shots, or put Screen Shots in an Appendix.

Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 10 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.

Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 11 Blank ‘Screens’ are Useless (2)  It is a good idea to try and ‘tell a story’ when presenting related Screens, 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.

Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 12 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.

Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 13 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 prototype.  Start NOW! START building your prototype information system. START thinking how you will document this prototype.

Ian Perry 44222: Information Systems Development: Documenting a Solution Slide 14 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