System Analysis and Design Rabie A. Ramadan, PhD 3 5/4/2011.

Slides:



Advertisements
Similar presentations
Fact Finding Techniques
Advertisements

Chpter#5 -part#1 Project Scope and Human Resource Planning
Slide 1 Systems Analysis and Design with UML Version 2.0 Alan Dennis, Barbara Wixom, and David Tegarden Chapter 5: Requirements Determination John Wiley.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.1.
Systems Analysis Chapter 4.
© Copyright 2011 John Wiley & Sons, Inc.
ANALYSIS PHASE Systems analysis is the part of the SDLC in which to determine how the current information system functions and asses what users would like.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
IS 421 Information Systems Analysis James Nowotarski 30 September 2002.
PowerPoint Presentation for IS-207 Copyright 2006 © Michael W. Schaffer. All rights reserved. Slide 1 Systems Analysis & Design Everything you wanted to.
12 C H A P T E R Systems Investigation and Analysis and Analysis.
Systems Requirements 10/4/2010 © Abdou Illia MIS Fall 2010.
Systems Analysis and Design
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 © John Wiley & Sons, Inc. All rights reserved.
Fundamentals of Information Systems, Second Edition
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Slide 1.
Systems Analysis Chapter 4
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design Copyright 2000 © John Wiley & Sons, Inc. All rights reserved. Slide 1 Systems.
Systems Analysis Requirements determination Requirements structuring
Systems Analysis and Design in a Changing World, Fourth Edition
Slide 1 Systems Analysis & Design CS183 Spring Semester 2008 Dr. Jonathan Y. Clark Course Website:
Requirements Gathering. Adapted from PowerPoint Presentation for Dennis, Wixom & Tegardem, Systems Analysis and Design, John Wiley & Sons, Inc. For CSU’s.
Chapter 4: Beginning the Analysis: Investigating System Requirements
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design Copyright 2000 © John Wiley & Sons, Inc. All rights reserved. Slide 1 Systems.
Slide 1 IS6112 – Application Modelling and Design.
Chapter 4: Beginning the Analysis: Investigating System Requirements
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 7 Determining.
Systems Analysis and Design with UML Version 2.0, Second Edition
Chapter 6 Determining System Requirements
PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 3rd Edition Copyright 2006 © John Wiley & Sons, Inc. All rights reserved.
Requirement Gathering Fall 2006/1385 Semester 1 Sharif Univ. of Tech.2 Sources Gather information on what system should do from many sources –Users –Reports.
Systems Analysis Strategies Chapter 4
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Slide 1.
Requirements Gathering Chapter 5 Alan Dennis, Barbara Wixom, and David Tegarden John Wiley & Sons, Inc. Slides by Fred Niederman Edited by Solomon Negash.
PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 3rd Edition Copyright 2006 © John Wiley & Sons, Inc. All rights reserved.
ZEIT2301 Design of Information Systems Requirements Gathering
SYSTEM ANALYSIS Chapter 5.
System Analysis and Design Dr. Taysir Hassan Abdel Hamid Lecture 5: Analysis Chapter 3: Requirements Determination November 10, 2013.
Modern Systems Analysis and Design Third Edition
PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 3rd Edition Copyright 2006 © John Wiley & Sons, Inc. All rights reserved.
Lecture 3 Managing the Development Project SFDV Principles of Information Systems.
Chapter 6 Determining System Requirements. 2 2 What are Requirements? “Requirements are … a specification of what should be implemented. They are descriptions.
Slide 1 Requirements Determination Chapter 5. Slide 2 Objectives ■ Understand how to create a requirements definition. ■ Become familiar with requirements.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Essentials of Systems Analysis and Design Fourth Edition Joseph S. Valacich Joey F.
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 7 Determining.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 © John Wiley & Sons, Inc. All rights reserved.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition Copyright © 2009 John Wiley & Sons, Inc. All rights.
PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 3rd Edition Copyright 2006 © John Wiley & Sons, Inc. All rights reserved.
Slide 1 Requirements Analysis - What is a Requirement? - Business requirements -> System requirements - Functional Requirements: _______________ - Nonfunctional.
Slide 1 Systems Analysis and Design with UML Version 2.0, Second Edition Alan Dennis, Barbara Wixom, and David Tegarden Chapter 5: Requirements Determination.
4 - 1 Systems Analysis and Design, 2 nd Edition Alan Dennis and Barbara Haley Wixom John Wiley & Sons, Inc. Slides by Roberta M. Roth University of Northern.
Chapter 6 Determining System Requirements. Objectives:  Describe interviewing options and develop interview plan.  Explain advantages and pitfalls of.
© 2005 by Prentice Hall Chapter 6 Determining System Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 © John Wiley & Sons, Inc. All rights reserved.
SYSTEM ANALYSIS AND DESIGN SAFAA S.Y. DALLOUL. REQUIREMENT DETERMINATION.
Slide 1 Systems Analysis and Design with UML Version 2.0, Second Edition Alan Dennis, Barbara Wixom, and David Tegarden Chapter 5: Requirements Determination.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 © John Wiley & Sons, Inc. All rights reserved.
Requirements Determination
Systems Analysis and Design 3rd Edition
Systems Analysis and Design in a Changing World, 4th Edition
Requirements Determination
Rekayasa Perangkat Lunak Part-14
Systems Analysis and Design with UML Version 2.0, Second Edition
TIM 58 Chapter 3: Requirements Determination
Systems Analysis and Design
Essentials of Systems Analysis and Design Fourth Edition
Rekayasa Perangkat Lunak
Joint Application Development (JAD)
Presentation transcript:

System Analysis and Design Rabie A. Ramadan, PhD 3 5/4/2011

Your Project During the Semester Step 1: Since you are here at Future University, Define the needed projects for the University and asses their feasibility. Write a complete proposal by the next week in a doc file I will asses your proposals and approve one

Plan B Student Web Site Auto registration Auto timetable Generator System Quiz Generator E-learning System ……

Questions to answer Which development methodology to use ? What are the criteria for selecting your methodology ? Name the team and their roles ? What are the values of the project (tangible and intangible)? Who is the sponsor of the project ? Did you get the committee approval ?

Questions to answer Is it a new system ? If yes, answer the following questions? Define the problem Establish system objectives Identify the USERS Establish functional scope What are the project issues and constraints ?

Questions to answer What is the technical feasibility of the project ? Do we have the capability to develop the system? Does the necessary tech exist? Can it be acquired? Does the proposed equipment have the right capacity for the data? Does the propose have the right: response time, interface, Can the system be expanded? Are the accuracy, reliability, ease of use, ease of access, security ok?

Identify Costs and Benefits CostsBenefits Tangible Intangible ************ ************

Organizational feasibility Is there support/resistance; from or by who? Are current business methods acceptable? Have the user's will be involved? Will the system cause harm?

Remember 1 - 9

Work and Meta-work Work is what we do to deliver elements of the project: design, coding, testing, etc. Meta-work, “work about the work”, is the organization and management of the tasks and deliverables to maximize the effectiveness of the work itself. Meta-Meta work: process definition … design of the meta-work of all your projects (process and procedures).

Project Manager: Role Slide 11 Responsible for “When” Not responsible for understanding every detail of implementation dependencies PM needs to engage all team members to extract dependencies and possibilities spine PM needs serious “spine” to get straight answers to “how long?”

Nomenclature – I Slide 12 Resource: anything with a cost … People, conference rooms, machines, test labs, customers (for testing) Once you get going, resources become fixed. Negotiate early! Most of what you manage are People.

Your turn Slide 13 What are the main resources for your project?

Nomenclature - II Slide 14 Task Task: an activity that results in a specific deliverable – should be verifiable Each task needs an estimated effort, for each resource assigned to the task. Start with “large grain”, then break down to consistent sizes (measured in days, for example).

Your turn Slide 15 What are the main tasks for your project?

Estimates of Effort Slide 16 Effort vs. Duration Effort: how long it takes in “abstract” Duration, how long it takes with discounts for meetings, travel, dentists, etc. Be consistent across the entire team, or be specific about the “overhead” rates you apply.. “Uncertainly” can overwhelm the value of an estimate. Be clear with staff as to quality of estimates.

Your turn Slide 17 Put a schedule for each task you defined ?

Nomenclature – III Slide 18 Tasks are aligned using dependencies … For each task, what other tasks must be accomplished to enable the work. This will require some digging with the individual developers and designers.

Nomenclature - IV Slide 19 Milestone: a clearly definable & measurable state that has meaning and importance to the team encapsulates functionality, denotes a specific deliverable Must be verifiable!

Verifiable Milestones Slide 20 “SMART” Specific Measurable Aligned Realistic Time-based

Your turn Slide 21 What are the mail stones of the project ?

Critical Path Slide 22 The set of tasks and milestones that determine the earliest delivery of the project. Map tasks and their dependencies in a tool, and the critical path falls out.

More on Milestones Slide 23 Tasks can be hard to manage in detail: omissions, complications.. Build a schedule with excellent Milestones, and manage your team to hit the milestones. Celebrate & acknowledge major milestones.

Slack Slide 24 Free slack: The amount of time that a task can be delayed without delaying its successor tasks. Once you lay out the critical path, slack is your friend. Zero slack … everything is on the critical path. Too much slack … not tight enough, or dependencies are not exposed.

Drive the Project Slide 25 Often, it is the PM that pushes Gets commitments to delivery (public testimony) Schedules meetings, publishes meeting notes and tasks Do not attend meetings without an agenda. Do not let a meeting end without a summary and next steps. Communication of the expectation makes it happen

Before the Project … Slide 26 Develop a Shared Vision Earliest “Discovery”: identifies what system does and for whom Get senior management to respond with scope estimates

Discovery & Scope Slide 27 Senior leadership drives project as it is conceived. Keep them involved. Constraints on project (cost, schedule) are documented up front.

Bottom-up Scheduling Slide 28 Use a structured breakdown to identify components and interfaces Data Flow Diagram (DFD) is a good source (be consistent) Use experienced developers to estimate effort for each component or interface Early estimates are low quality: iterate The toolset changes everything …

Bottom-up Scheduling Slide 29 Each component needs requirements, design, spec, implementation and testing … include it all Assign / allocate resources Look for trouble … Overbooking, gaps, availability

Function Point Approach Slide 30 Method to develop estimates of time and resources needed

Good Estimates … Slide 31 Reliable estimates can be accomplished by senior engineers when: Platform exists: incremental additions Tool-set well understood and stable Nothing too new or radical

Bad Estimates … Slide 32 Estimates get funky when: New tools or language New application area (no established models) New team working together Process is not respected by leadership (scope creep).

Risks … Slide 33 Identify risk areas, unknowns: Technology, Skill gaps Resource commitment/focus Use early phases to mitigate risk Prototypes Consultants (with care)

Your turn Slide 34 What are the risks of your project?

Contingency Planning Slide 35 PM is responsible for leading contingency planning … get team to walk through “plan B”. When risk / uncertainly is high on any particular component. For all elements on the Critical Path.

Break the critical path Slide 36 Create mechanisms to reduce dependencies Sample data to drive processes XML is a useful tool for these tricks. Assign more resources … ?

A Holy Trinity Slide 37 Do your best to set a plan and allocate your resources. Assuming that you have done a credible job. Additional features require additional testing

“Brooks’ Law” Slide 38 From “The Mythical Man-month”, a classic in Software Engineering “Adding resources to a late project only makes it later.” Thus the demands on tracking resources and adjusting early, to compensate while there is still hope.

Telling Bad News Slide 39 You have got to do it … Blame is rarely needed: Focus on how, and what next? There is always time to punish later Forest and trees: sometimes its not as bad as it seems. The earlier, the better.

Key Definitions The As-Is system is the current system and may or may not be computerized. The To-Be system is the new system that is based on updated requirements. The System Proposal is the key deliverable from the Analysis Phase.

Key Ideas The goal of the analysis phase is to truly understand the requirements of the new system and develop a system that addresses them -- or decide a new system isn’t needed. The System Proposal is presented to the approval committee via a system walk-through. Systems analysis incorporates initial systems design. Requirements determination is the single most critical step of the entire SDLC.

REQUIREMENTS DETERMINATION

What is a Requirement ? A statement of what the system must do A statement of characteristics the system must have Focus is on business user needs during analysis phase Requirements will change over time as project moves from analysis to design to implementation

Requirement Types Functional Requirements A process the system hast to perform Information the system must contain Nonfunctional Requirements Behavioral properties the system must have Operational Performance Security Cultural and political

Documenting Requirements Requirements definition report Text document listing requirements in outline forming Priorities may be included Key purpose is to define the project scope: what is and is not to be included.

Basic Process of Analysis (Determining Requirements) Understand the “As-Is” system Identify improvement opportunities Develop the “To-Be” system concept Techniques vary in amount of change BPA – small change BPI – moderate change BPR – significant change Additional information gathering techniques are needed as well

Determining Requirements Participation by business users is essential Three techniques help users discover their needs for the new system: Business Process Automation (BPA) - small change Business Process Improvement (BPI) - moderate change Business Process Reengineering (BPR)- significant change

Business Process Automation Goal: Efficiency for users

Identifying Improvements in As-Is Systems Problem Analysis Ask users to identify problems and solutions Improvements tend to be small and incremental Rarely finds improvements with significant business value Root Cause Analysis Challenge assumptions about why problem exists Trace symptoms to their causes to discover the “real” problem

Root Cause Analysis Example

Business Process Improvement Goal: Efficiency and effectiveness for users

Duration Analysis Calculate time needed for each process step Calculate time needed for overall process Compare the two – a large difference indicates a badly fragmented process Potential solutions: Process integration – change the process to use fewer people, each with broader responsibilities Parallelization – change the process so that individual step are performed simultaneously

Activity-Based Costing Calculate cost of each process step Consider both direct and indirect costs Identify most costly steps and focus improvement efforts on them

Benchmarking Studying how other organizations perform the same business process Informal benchmarking Common for customer-facing processes Interact with other business’ processes as if you are a customer

Business Process Reengineering Goal: Radical redesign of business processes

Outcome Analysis Consider desirable outcomes from customers’ perspective Consider what the organization could enable the customer to do

Technology Analysis Analysts list important and interesting technologies Managers list important and interesting technologies The group identifies how each might be applied to the business and how the business might benefit

Activity Elimination Identify what would happen if each organizational activity were eliminated Use “force-fit” to test all possibilities

Your Turn How do you know whether to use business process automation, business process improvement, or business process reengineering? Provide one example.

REQUIREMENTS-GATHERING TECHNIQUES

Interviews Most commonly used technique Basic steps: Selecting Interviewees Designing Interview Questions Preparing for the Interview Conducting the Interview Post-Interview Follow-up

Selecting Interviewees Based on information needs Best to get different perspectives Managers Users Ideally, all key stakeholders Keep organizational politics in mind

Types of Questions Types of Questions Examples Closed-Ended Questions* How many telephone orders are received per day? * How do customers place orders? * What additional information would you like the new system to provide? Open-Ended Questions* What do you think about the current system? * What are some of the problems you face on a daily basis? * How do you decide what types of marketing campaign to run? Probing Questions* Why? * Can you give me an example? * Can you explain that in a bit more detail?

Organizing Interview Questions Unstructured interview useful early in information gathering Goal is broad, roughly defined information Structured interview useful later in process Goal is very specific information

Structuring the Interview High Level: Very General Medium-Level: Moderately Specific Low-Level: Very Specific TOP DOWN BOTTOM UP EXAMPLES?

Interview Preparation Steps Prepare general interview plan List of question Anticipated answers and follow-ups Confirm areas of knowledge Set priorities in case of time shortage Prepare the interviewee Schedule Inform of reason for interview Inform of areas of discussion

Conducting the Interview Appear professional and unbiased Record all information Check on organizational policy regarding tape recording Be sure you understand all issues and terms Separate facts from opinions Give interviewee time to ask questions Be sure to thank the interviewee End on time

Conducting the Interview Practical Tips Take time to build relationship Pay attention Summarize key points Be brief Be honest Watch body language

Post-Interview Follow-Up Prepare interview notes Prepare interview report Have interviewee review and confirm interview report Look for gaps and new questions

Your Turn Based on the previous tips, work in two groups to conduct an interview. Prepare questions and try to interview the other party. Exchange your rules

Your Assignment Prepare interview notes Prepare interview report Have interviewee review and confirm interview report Look for gaps and new questions Do this for at least 5 people ?

Joint Application Development (JAD)

Joint Application Development A structured group process focused on determining requirements Involves project team, users, and management working together May reduce scope creep by 50% Very useful technique

JAD Participants Facilitator Trained in JAD techniques Sets agenda and guides group processes Scribe(s) Record content of JAD sessions Users and managers from business area with broad and detailed knowledge

JAD Sessions Time commitment – ½ day to several weeks Strong management support is needed to release key participants from their usual responsibilities Careful planning is essential e-JAD can help alleviate some problems inherent with groups

JAD Meeting Room JPEG Figure 5-5 Goes Here