44222: Information Systems Development Prototyping & The Problem Statement Ian Perry Room: C49 Extension: 7287

Slides:



Advertisements
Similar presentations
Information technology solutions development Fundamentals of Information Technology Session 3.
Advertisements

Philanthropy, Values and Citizenship
South Pacific Board for Educational Assessment M & E Teacher Performance Improving teaching effectiveness Capacity Building Workshop on ‘Monitoring and.
Ncfe Academy Advert Project By the Rising Stars Academy.
Advanced Database Projects In Access © Hodder Education 2008 Access Projects – Problem Specification.
Evaluating Requirements. Outline Brief Review Stakeholder Review Requirements Analysis Summary Activity 1.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
ACTIVELY ENGAGING THE STAKEHOLDER IN DEFINING REQUIREMENTS FOR THE BUSINESS, THE STAKEHOLDER, SOLUTION OR TRANSITION Requirements Elicitation.
Human Computer Interaction G52HCI
Unit 211 Requirements Phase The objective of this section is to introduce software system requirements and to explain different ways of expressing these.
CS351 © 2003 Ray S. Babcock Requirements What not How “The Pizza Experiment” 1994, 350 companies, 8000 software projects. 31% were canceled before they.
CS 501: Software Engineering
Lecture 3 Managing your project How? Milestones Deliverables Meeting tutors.
Technical Communication 1
SE 555 Software Requirements & Specification 1 SE 555 Software Requirements & Specification Prototyping.
7M822 Software Requirements Introduction 7 September 2010.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Software Life Cycle Model
1 © 2009 University of Wisconsin-Extension, Cooperative Extension, Program Development and Evaluation Getting started with evaluation.
System Analysis & Design
The Software Development Life Cycle: An Overview
Collaborating in the Workplace C H A P T E R 3. In What Settings Do Employees Write Collaboratively? How Do You Manage a Project? How Do You Conduct Effective.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
#17 - Involve Users in the Development Model of Multinational Corporations - Is it worth it? Experience Report IRCSE '08: IDT Workshop Friday 31 October.
Administrative Policy Writing Spring Administrative Policy Writing Spring 2011 Introduction This week we are discussing a type of public-policy.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
How to write your special study Step by step guide.
44222: Information Systems Development Operational & Information Systems Ian Perry Room:C41C Extension:7287
Chapter 13– Strategies for Effective Oral Presentations The goal of the presentation is to communicate, clearly and concisely, the results and implications.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Requirements Engineering Requirements Elicitation Process Lecture-8.
44222: Information Systems Development Introduction to Module Ian Perry Room: C41C Extension: 7287
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
{ The writing process Welcome. In the prewriting stage the follow must be considered:   factual information pertaining to topic   clear definition.
How to write a technical report Powerpoint: H VenterSpeakers: L Kruger Editor: GF De Wet G Claassen Group 42.
Communications Skills (ELE 205)
Dissertation Document?
442421: Dissertation Interim Report Ian Perry Room: C49 Extension: 7287
44222: Information Systems Development Documenting a Solution Ian Perry Room:C41C Extension:7287
Communications Skills (ELE 205) Dr. Ahmad Dagamseh Dr. Ahmad Dagamseh.
Lecture 6: Writing the Project Documentation Part IV.
Systems Development Life Cycle
Software Prototyping Rapid software development to validate requirements.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Preparing a Written Report Prepared by: R Bortolussi MD FRCPC and Noni MacDonald MD FRCPC.
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
Evaluating Requirements
Real-World Writing. Forms Speech Editorial Article Letter.
ENGR 1181 College of Engineering Engineering Education Innovation Center Introduction to Technical Communication.
44222: Information Systems Development
National PE Cycle of Analysis. Fitness Assessment + Gathering Data Why do we need to asses our fitness levels?? * Strengths + Weeknesses -> Develop Performance.
44222: Information Systems Development Documenting a Solution Ian Perry Room:C49 Extension:7287
ATTACKING THE (SAR) OPEN ENDED RESPONSE. Get out a sheet of paper(or 2?)! Your responses to the questions on this power point will be your SAR test grade.
The Research Process for EE. THE RESEARCH PROCESS DEFINELOCATESELECT ORGANISE PRESENT EVALUATE Writing the essay!
44222: Information Systems Development Review & Assignment 1 Requirements Ian Perry Room: C49 Extension: 7287
Unit 6 Application Design.
Creating a personal statement for university or college
ACTION LEARNING Ian Duncan Action Learning Facilitator
Requirements Analysis
The genre The purpose The game
Unit 5 – eProject – Starting to look at projects Unit 5
Introduction to Engineering Design II (IE 202)
Requirement Analysis.
Joint Application Development (JAD)
English 1301 Week 13 November 20, 2017.
Writing Information Reports
Enhancing Learning in Practice
Presentation transcript:

44222: Information Systems Development Prototyping & The Problem Statement Ian Perry Room: C49 Extension:

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)

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

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?

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.

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.

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!

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.

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

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.

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.

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.

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

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.

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.