Www.monash.edu.au IMS1805 Systems Analysis Topic 3: Doing analysis.

Slides:



Advertisements
Similar presentations
Chapter 7 Structuring System Process Requirements
Advertisements

© 2005 by Prentice Hall 7-1 Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey.
Chapter 7 Structuring System Process Requirements
CS 411W - Notes Product Development Documentation.
COMP 208/214/215/216 – Lecture 5 Presentation Skills.
How to write a review Set the book in context. When, where and if possible why was it written. Tell us a little about the author and his/her objectives.
Software Requirements
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
IMS Systems Analysis and Design Communication and Documentation: Additional Notes on Written Reports.
IMS1805 Systems Analysis Topic 1: Recap: The elements of analysis.
IMS1805 Systems Analysis Topic 2: Introduction to some key techniques for systems analysis in IS.
IMS1805 Systems Analysis Topic 4: How do you do it? Guidelines for doing analysis (continued from last week)
IMS1805 Systems Analysis Topic 3 (revisited and continued): Doing analysis – a ‘soft’ systems perspective.
introduction to MSc projects
IMS1805 Systems Analysis Topic 3: Doing analysis (cont)
IMS1805 Systems Analysis Topic 3: Doing analysis.
IMS1805 Systems Analysis Topic 4: How do you do it? Guidelines for doing analysis.
IMS1805 Systems Analysis Topic 3: Doing Analysis (continued from previous weeks)
Writing Good Software Engineering Research Papers A Paper by Mary Shaw In Proceedings of the 25th International Conference on Software Engineering (ICSE),
Analytical methods for Information Systems Professionals Week 13 Lecture 1 CONCLUSION.
Soft. Eng. II, Spr. 2002Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 1 (cont ’d) Title : Client requirements (Review) Mandatory reading: I.
Math 105: Problem Solving in Mathematics. Course Description This course introduces students to the true nature mathematics, what mathematicians really.
IMS1805 Systems Analysis Topic 1(c): Analysis and Information Systems.
IMS1805 Systems Analysis Topic 1(b): The elements of analysis.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
Copyright 2004 Monash University IMS1805 Systems Analysis Week 2(b): Analysis for Information Systems.
IMS1805 Systems Analysis Topic 6: Analysis as a process within a process.
ECE Lecture 1 1 ECE 3561 Advanced Digital Design Department of Electrical and Computer Engineering The Ohio State University.
IMS1805 Systems Analysis Review.
IMS1805 Systems Analysis Topic 2: Introduction to some key techniques for systems analysis in IS.
Process Modelling Using Data Flow Diagrams - Building and Levelling Them; Process Modelling Using Function Decomposition CSE Information Systems.
Methods of Instruction. Learning Objectives Upon completion of this lesson, participants will be able to: – Compare and contrast a range of instructional.
DATA FLOW DIAGRAMS IT 155.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Chapter 7 Structuring System Process Requirements
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Traditional Approach to Requirements Data Flow Diagram (DFD)
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
Data Flow Diagrams (DFDs)
Chapter 1: Data Flow Diagram Structuring System Process Requirements
Structuring System Process Requirements. Learning Objectives Understand the logical modeling of processes by studying examples of data flow diagrams (DFDs).
Information Literacy in the workplace: implications for trainers By Dr. Mark Hepworth Department of Information Science Loughborough University.
Determining System Requirements Classes 9,10. SDLC Project Identification & Selection Project Initiation & Planning Analysis ** Logical Design Physical.
Business and Management Research WELCOME. Lecture 2 Business and management research?
Chapter 7 Structuring System Process Requirements
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
IS 466 ADVANCED TOPICS IN INFORMATION SYSTEMS LECTURER : NOUF ALMUJALLY 22 – 10 – 2011 College Of Computer Science and Information, Information Systems.
Requirements Analysis via Use Cases SE-2030 Dr. Rob Hasker 1 Based on slides written by Dr. Mark L. Hornick Used with permission.
Methods and Models Choice of methods for Development of IT related products and systems SVINGSVING Conference held in Gothenburg, Sweden, October 2000.
Chapter 7 System models.
IMAT1906 Systems Development Lecture week 6: systems analysis (1) : feasibility.
System models l Abstract descriptions of systems whose requirements are being analysed.
NESCent Postdoc Professional Development Series on Effective Teaching and Learning Session 7 – Testing, Assessment and Grading October 20 th, 2006 NESCent.
Systems Analysis and Design in a Changing World, Fourth Edition
20CC Ltd Independent Consultants © 20CC Ltd Systems Thinking Overview Sources from The Open University acknowledged.
Modern Systems Analysis and Design Fifth Edition
Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Yr 7.  Pupils use mathematics as an integral part of classroom activities. They represent their work with objects or pictures and discuss it. They recognise.
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Lecture 3 : Hard Systems Modelling UFCE8V-20-3 Information Systems Development SHAPE Hong Kong 2010/11.
 To explain why the context of a system should be modelled as part of the RE process  To describe behavioural modelling, data modelling and object modelling.
Requirements in the product life cycle Chapter 7.
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
BSc Honours Project Introduction CSY4010 Amir Minai Module Leader.
7-1 Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition.
Business System Development
Process Modelling Chapter 6.
Chapter 1: Data Flow Diagram Structuring System Process Requirements
Chapter 7: Data Flow Diagram Structuring System Process Requirements
Presentation transcript:

IMS1805 Systems Analysis Topic 3: Doing analysis

2 Recap of last lecture You have all demonstrated significant analytical skills You have certain biases in your analytical techniques which make you favour certain approaches You need to learn different techniques and become more flexible in your analytical thinking

3 Agenda Aim: To identify some of the main areas of difficulty you will find in doing information- related analysis To examine important aspects of thinking like an information systems analyst To discuss the first assignment and your approach to it

Problems in changing scale and scope of analysis From last week’s tute to this week’s tute From actions to information processes From movement of objects to movement of information From things to information about things From hierarchies of objects to hierarchies of processes From small/localised/simple to large/extensive/ complex

5 Dealing with systems For want of a nail …. How you make things happen at Coles-Myer Understanding interactions/connections Partitioning systems horizontally Keeping the system manageable Setting boundaries and identifying movement across them How many partitions? The magical number 7 (plus or minus 2)

6 Dealing with information The problem of dealing with the intangible Recognising information and information processes Breaking information and information processes into their component parts Computers, data and information

7 Understanding the big picture The hierarchy of objectives and functions: Basic objectives of the system? Main functions needed to achieve these objectives? Smaller functions needed to support these main functions And so on? An analyst needs to be clear about the big picture, and keep it as context within which the details can be understood Consider supermarket example from tute

8 Understanding the small (ie detailed) picture What is needed to make the lowest-level functions work? The importance of precision in understanding and language The importance of getting it right (more horse shoe nails) The way computers make things worse (or at least harder)

9 Learning the language Every business/organisation has a specialised vocabulary/jargon Some industry-specific (invoice, purchase order; enrolment, course); some company- specific (EFTSL, Form L2A) Usually not very large or complex, but it needs to be learned Beware of words and phrases which are familiar – but which you don’t actually understand

10 Detail and comprehensibility Partitioning vertically: decomposing to specify functions in more detail breaking objects into multiple smaller objects How much do you partition? How low do you need to go? (how deep the hierarchy) When is the detail too much? The magical number 7 (plus or minus 2) Adapting your descriptions – from general and broad (high-level) to specific and precise (low-level)

11 “Logical” vs “physical” models Understanding the difference: Physical vs logical processes Physical vs logical objects See examples given in class Why are they both useful? Physical models to aid understanding and implementation Logical models to aid flexibility of thought and creativity

Analysis as a part of development - the story of the bracket The need – what was the objective and how was it to be achieved? The initial analysis and request The response The formal analysis The model The final outcome

13 Being a systems analyst: Living in the middle In the middle of the organisation Going from top-level/management to bottom-level operations Analysis at each end and analysis in the middle The analyst as organisational expert In the middle of the development process Going from user needs to technological capabilities Analysis at each end and analysis in the middle The analyst as interpreter Choosing the analytical position which suits you and the situation

14 Making assumptions No data collection about a problem or situation will ever describe all aspects of it fully You make assumptions to “fill the gaps” in what you have been told This is sometimes necessary and often dangerous! Always be alert to your assumptions and test them Assumptions in your assignment

15 Minimising assumptions: the most important phrases in systems analysis Some very powerful analytical tools: “Please explain” “I don’t know what you mean” “Could you please take me through that again?” “Is this what you said?” Your capacity to absorb is limited Asking the same thing in different ways Confirming what you have heard

First assignment Assignment requirements Finding out what you need to know Developing your explanations of how it works Testing your assumptions Selecting diagramming technique(s) Explaining and justifying your choices

17 What do you need to know? Modelling (diagramming), data collection and problem definition as iterative processes Problem definition System representation (modelling) Data collection Problem definition Data collection System representation (modelling) Simplistic picture (waterfall) More realistic picture (iteration)

Summary Analysis is as much an art as a science Learning about how to do it requires experience and reflection You never master it; but you can get better!