Www.themegallery.com CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 03: Requirements Capture Requirements Analysis.

Slides:



Advertisements
Similar presentations
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 1.Gain agreement on the problem definition. 2.Understand the root causes 3.Identify the.
Advertisements

Session # 2 SWE 211 – Introduction to Software Engineering Lect. Amanullah Quadri 2. Fact Finding & Techniques.
MIS (Management Information System)
Slide 1 Systems Analysis and Design with UML Version 2.0 Alan Dennis, Barbara Wixom, and David Tegarden Chapter 5: Requirements Determination John Wiley.
Chapter 6 Review Questions
CSE Information Systems 1
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
Chapter 8 Information Systems Development & Acquisition
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Monash University, SIMS, Semester One, DATA GATHERING FOR INFORMATION SYSTEMS DEVELOPMENT CSE Information Systems 1 CSE Information Systems.
INFORMATION GATHERING FOR INFORMATION SYSTEMS DEVELOPMENT IMS Information Systems 1 CSE Information Systems 1.
Requirements Analysis 2. 1 Req. Capture b502.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Requirements.
Systems Analysis and Design
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
Fact-Finding Fact-Finding Overview
Systems Analysis and Design in a Changing World, 6th Edition
03/12/2001 © Bennett, McRobb and Farmer Requirements Capture Based on Chapter 6 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
Interviewing Stakeholders: Evaluating Support for Policy Change in Your Community.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes 1.
CSC271 Database Systems Lecture # 20.
Systems Life Cycle A summary of what needs to be done.
Approaches to Investigating a System “Who knows what’s happening now?”
Chapter 8: Systems analysis and design
Module 4: Systems Development Chapter 13: Investigation and Analysis.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Chapter 5: Requirement Engineering Process Omar Meqdadi SE 2730 Lecture 5 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
PRJ566 Project Planning and Management
1 WXGC6102: Object-Oriented Techniques Requirements Capture References: Chapter 6 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
Requirements Capture Fact Finding Part 2.
 To describe the principal requirements engineering activities and their relationships  To introduce techniques for requirements elicitation and analysis.
1 SYS366 Week 4, Lecture 1 Introduction to Requirements Gathering: Part 3 – Getting to Software Requirements.
INTERNATIONAL LABOUR ORGANIZATION Conditions of Work and Employment Programme (TRAVAIL) 2012 Module 13: Assessing Maternity Protection in practice Maternity.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
Introduction to Evaluation Odette Parry & Sally-Ann Baker
System Analysis-Gathering Requirements.  System analysis is the process of gathering info about existing system, which may be computerized or not, while.
Lecture 7: Requirements Engineering
IS2210: Systems Analysis and Systems Design and Change Twitter:
Database Analysis and the DreamHome Case Study
Slide 1 Requirements Determination Chapter 5. Slide 2 Objectives ■ Understand how to create a requirements definition. ■ Become familiar with requirements.
University of Sunderland Professionalism and Personal Skills Unit 9 Professionalism and Personal Skills Lecture Data Collection.
Ways of Collecting Information Interviews Questionnaires Ethnography Books and leaflets in the organization Joint Application Design Prototyping.
IFS310: Module 3 1/25/2007 Fact Finding Techniques.
1 Chapter 3 1.Quality Management, 2.Software Cost Estimation 3.Process Improvement.
Data Gathering Techniques 27 th February Data Gathering Techniques System requirements specify what the system must do or what property or quality.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Chapter 4 Requirements Engineering (3/3) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
Centre for Information & Knowledge Management INFORMATION SYSTEMS MANAGEMENT Jamie O’Brien Centre for Information & Knowledge Management University of.
INFO1002 Systems Modelling Lecture 10 Establishing User Requirements Department of information Systems.
The techniques involved in systems analysis Explanation of a feasibility study:Explanation of a feasibility study: –economic, –legal, –technical, –time.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
CC20O7N Software Engineering 1 CC2007N Software Engineering 1 Introduction to Requirements Engineering/Analysis.
Chapter 6 Determining System Requirements. Objectives:  Describe interviewing options and develop interview plan.  Explain advantages and pitfalls of.
Usability Evaluation, part 2. REVIEW: A Test Plan Checklist, 1 Goal of the test? Specific questions you want to answer? Who will be the experimenter?
SOME OTHER CONSIDERATIONS You should consider the -Need/Expectations of Trainees *The trainees expectations should be identified before designing the program.
Requirements Engineering Requirements Validation and Management Lecture-24.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
CS223: Software Engineering Lecture 8: Requirement Engineering.
6-1 Functional vs. Nonfunctional Requirements Functional requirement - something the information system must do Nonfunctional requirement - a property.
5. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Describe the activities of the requirements discipline  Describe the difference.
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
Fact Finding (Capturing Requirements) Systems Development.
Systems Analysis Lecture 5 Requirements Investigation and Analysis 1 BTEC HNC Systems Support Castle College 2007/8.
Unit F451 Computer Fundamentals Components of a Computer System Software Data: Its representation, structure and management in information.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVII. Verification and Validation.
Investigating System Requirements
Systems Analysis and Design
SYSTEMS ANALYSIS Chapter-2.
Systems Analysis and Design in a Changing World, 6th Edition
Presentation transcript:

CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 03: Requirements Capture Requirements Analysis

© Bennett, McRobb and Farmer In This Lecture You Will Learn:  The distinction between the current and required systems  When and how to apply the main fact finding techniques  The roles played by users  The need to document requirements

© Bennett, McRobb and Farmer User Requirements  Need to understand how the organization operates at present  What are the problems with the current system?  What are the requirements users have of a new system that are not in the current system?

© Bennett, McRobb and Farmer Current System  Much of the current system meets the needs of people who use it  Sections of the system no longer meet the needs of the organization  Some aspects of the organization’s work are not covered by the current system  The system can no longer evolve but needs to be replaced

© Bennett, McRobb and Farmer Current System  It is important to understand current system to carry functionality forward into new system  It is also important to understand it so that shortcomings and defects can be corrected in the new system

© Bennett, McRobb and Farmer Current System  Yourdon (1989) argues against spending a lot of time analysing the existing system—it’s being replaced!  SSADM makes the case for modelling the current system—much of its functionality will be required in the new system

© Bennett, McRobb and Farmer Reasons for Investigating the Current System  Functionality is required in new system  Data must be migrated into new system  Technical documentation provides details of processing algorithms  Defects of existing system must be avoided  Parts of existing system may have to be kept  We need to understand the work of the users  Baseline information about the existing system helps set targets for the new one

© Bennett, McRobb and Farmer New Requirements  Organizations operate in a rapidly changing business environment  Organizations operate in a changing technical environment  Governments and supra-governmental organizations introduce legislation  Organizations merge, demerge, take over and get taken over  All this drives the need to replace systems and build new ones

© Bennett, McRobb and Farmer Types of Requirements  Functional  Non-functional  Usability

© Bennett, McRobb and Farmer Functional Requirements  Describe what a system must do  Include:  processes  interfaces with users and other systems  what the system must hold data about  Modelled with Use Case Diagrams  Modelled with Use Case Diagrams. Later will be modelled with other kinds of diagrams that show the structure of the system (Class Diagrams) and its behaviour (Interaction Diagrams and Statechart Diagrams)

© Bennett, McRobb and Farmer Non-functional Requirements  Concerned with how well the system performs  Include:  response times  volumes of data  security considerations  Documented in Requirements List or in Use Case Model  Documented in Requirements List or in Use Case Model (for requirements that can be linked to specific use cases)

© Bennett, McRobb and Farmer Usability Requirements  Concerned with matching the system to the way that people work  Sets measurable objectives  Include:  characteristics of users  tasks users undertake  situational factors  acceptance criteria for the working system  Documented in Requirements List  Documented in Requirements List. May be tested by Prototypes

© Bennett, McRobb and Farmer Fact Finding Techniques  Background Reading  Interviewing  Observation  Document Sampling  Questionnaires

© Bennett, McRobb and Farmer Background Reading  Aim is to understand the organization and its business objectives  Includes:  reports  organization charts  policy manuals  job descriptions  documentation of existing systems

© Bennett, McRobb and Farmer Background Reading  Advantages:  helps to understand the organization before meeting the people who work there  helps to prepare for other types of fact finding  documentation of existing system may help to identify requirements for functionality of new system

© Bennett, McRobb and Farmer Background Reading  Disadvantages:  written documents may be out of date or not match the way the organization really operates  Appropriate situations:  analyst is not familiar with organization  initial stages of fact finding

© Bennett, McRobb and Farmer Interviewing  Aim is to get an in-depth understanding of the organization’s objectives, users’ requirements and people’s roles  Includes:  managers to understand objectives  staff to understand roles and information needs  customers and the public as potential users

© Bennett, McRobb and Farmer Interviewing  Advantages:  personal contact allows the inetrviewer to respond adaptively to what is said  it is possible to probe in greater depth  if the interviewee has little or nothing to say, the interview can be terminated

© Bennett, McRobb and Farmer Interviewing  Disadvantages:  can be time-consuming and costly  notes must be written up or tapes transcribed after the interview  can be subject to bias  if interviewees provide conflicting information this can be difficult to resolve later

© Bennett, McRobb and Farmer Interviewing  Appropriate situations:  most projects  at the stage in fact finding when in-depth information is required  Requires skill to carry out effectively  Requires skill to carry out effectively (See Box 6.1 for guidelines)

© Bennett, McRobb and Farmer Observation  Aim is to see what really happens, not what people say happens  Includes:  seeing how people carry out processes  seeing what happens to documents  obtaining quantitative data as baseline for improvements provided by new system  following a process through end-to-end  Can be open-ended or based on a schedule

© Bennett, McRobb and Farmer Observation  Advantages:  first-hand experience of how the system operates  high level of validity of the data can be achieved  verifies information from other sources  allows the collection of baseline data

© Bennett, McRobb and Farmer Observation  Disadvantages:  people don’t like being observed and may behave differently, distorting the findings  requires training and skill  logistical problems for the analyst with staff who work shifts or travel long distances  ethical problems with personal data

© Bennett, McRobb and Farmer Observation  Appropriate situations:  when quantitative data is required  to verify information from other sources  when conflicting information from other sources needs to be resolved  when a process needs to be understood from start to finish

© Bennett, McRobb and Farmer Document Sampling  Aims to find out the information requirements that people have in the current system  Also aims to provide statistical data about volumes of transactions and patterns of activity  Includes:  obtaining copies of empty and completed documents  counting numbers of forms filled in and lines on the forms  screenshots of existing computer systems

© Bennett, McRobb and Farmer Document Sampling  Advantages:  for gathering quantitative data  for finding out about error rates  Disadvantages:  not helpful if the system is going to change dramatically  Appropriate situations:  always used to understand information needs  where large volumes of data are processed  where error rates are high

© Bennett, McRobb and Farmer Questionnaires  Aims to obtain the views of a large number of people in a way that can be analysed statistically  Includes:  postal, web-based and questionnaires  open-ended and closed questions  gathering opinion as well as facts

© Bennett, McRobb and Farmer

© Bennett, McRobb and Farmer Questionnaires  Advantages:  economical way of gathering information from a large number of people  effective way of gathering information from people who are geographically dispersed  a well designed questionnaire can be analysed by computer

© Bennett, McRobb and Farmer Questionnaires  Disadvantages:  good questionnaires are difficult to design  no automatic way of following up or probing more deeply  postal questionnaires suffer from low response rates

© Bennett, McRobb and Farmer Questionnaires  Appropriate situations:  when views of large numbers of people need to be obtained  when staff of organization are geographically dispersed  for systems that will be used by the general public and a profile of the users is required

© Bennett, McRobb and Farmer Questionnaires  Require skill to design effectively (See Box 6.2 for guidelines)

© Bennett, McRobb and Farmer User Involvement  A variety of stakeholders:  senior management—with overall responsibility for the organization  financial managers—who control budgets  managers of user departments  representatives of users of the system

© Bennett, McRobb and Farmer User Involvement  Different roles:  subjects of interviews  representatives on project committees  evaluators of prototypes  testers  as trainees on courses  end-users of new system

© Bennett, McRobb and Farmer Documenting Requirements  Documentation should follow organizational standards  CASE tools that produce UML models maintain associated data in a repository  Some documents will need separate storage in a filing system:  interview notes  copies of existing documents  minutes of meetings  details of requirements

© Bennett, McRobb and Farmer Documenting Requirements  Documents should be kept in a document management system with version control  Use use cases to document functional requirements  Maintain a separate requirements list  Review requirements to exclude those that are not part of the current project

© Bennett, McRobb and Farmer

© ennett, McRobb and Farmer

© Bennett, McRobb and Farmer Summary In this lecture you have learned about:  The distinction between the current and required systems  When and how to apply the main fact finding techniques  The roles played by users  The need to document requirements

CSE323 Systems Analysis and Design 40 Oct-15 Next Lecture Process Modeling