ICT117 Week04 Requirements Determination S

Requirements Determination
Chapter 4: Dennis, Wixom and Tegarden
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition
Copyright 2009 John Wiley & Sons, Inc. All rights reserved.
Enquiry
VTAC are interested in hearing from any student selected for this course from VTAC who would be prepared to provide a profile and photo for publication Contact information from lecturer
17 March, 2011
ICT117 Systems Analysis & Design, Semester 1, 2011 Includes John Wiley& Sons Inc material
4.2
Next week 24th March

No lecture or tutorial next week New lecturer from 31st March
17 March, 2011
4.3
The SDLC and Requirements

The SDLC transforms the existing (as-is) system into the proposed (to-be) system Requirements Determination reveals how the to-be system must function The Requirements Determination step is the single most critical step of the entire SDLC
Studies show that more than half of all system failures are due to problems with requirements
17 March, 2011
Defining a Requirement
A statement of what the system must do or what characteristic it must have During analysis, requirements are written from the perspective of the businessperson Two kinds of requirements: Functional Nonfunctional
17 March, 2011
Nonfunctional Requirements
Requirement type Operational Example The system should be able to fit in a pocket or purse The system should be able to integrate with the existing inventory system. Any interaction between the user and the system should not exceed 2 seconds. The system should receive updated inventory information every 15 minutes. Only direct managers can see personnel records of staff Customers can see their order history only during business hours.
Figure 4-1, pg 113
Performance
Security
Cultural & Political
17 March, 2011
The system should be able to distinguish between United States and European currency The system shall comply with insurance industry ICT117 Systems Analysis & Design, Semester 1, 2011 Includes 6 standards.
John Wiley& Sons Inc material
Requirements Definition Report aka FRS

Correct Unambiguous Complete Consistent Verifiable Modifiable Traceable Ranked for importance
(IEEE Standard 830-1998: Recommended Practice for Software Requirements Specifications)

17 March, 2011 ICT117 Systems Analysis & Design, Semester 1, 2011 Includes John Wiley& Sons Inc material 7
Determining Requirements
Requirements are best determined by systems analysts and business people together Techniques available to the systems analyst:
Interviews Questionnaires Observation Joint application development (JAD) Document analysis
REQUIREMENTS ANALYSIS STRATEGIES

Requirements Analysis Strategies

The basic process of analysis is divided into:
Understanding the AS-IS system Identifying improvements Developing requirements for the TO-BE system
There are 3 requirements analysis strategies

Business process automation Business process improvement Business process reengineering
Business Process Automation

BPA leaves organizational operations mostly unchanged and uses computer technology to do some of the work Low risk, but low payoff Planners in BPA projects invest significant time in understanding the as-is system using:
Problem analysis Root cause analysis
Problem Analysis
Users and managers identify problems with the as-is system and describe how to solve them in the to-be system Tends to solve problems rather than capitalise on opportunities Improvements tend to be small and incremental
17 March, 2011
12
Root Cause Analysis

Users are not asked for solutions, but for: A list of (prioritised) problems All possible root causes for those problems Analysts investigate each root cause to find: Solutions for the highest priority problems Root causes that are common to multiple problems
Root Cause Analysis Example
17 March, 2011
14
Business Process Improvement

BPI makes moderate changes to the way in which the organisation operates to take advantage of new opportunities offered by technology or to copy what competitors are doing Common activities: Duration analysis Activity-based costing Informal benchmarking
Business Process Reengineering

BPR changes the fundamental ways in which the organisation operates Spends little time understanding the as-is, because the goal is to focus on new ideas and new ways of doing business Popular activities: Outcome analysis Technology analysis Activity elimination
17 March, 2011
16
Selecting the Appropriate Strategies

Choice of strategy is based on an analysis of four characteristics
Business Process Automation Potential benefit Project cost Breadth of analysis Risk
17 March, 2011
Business Process Improvement Moderate Lowmoderate Narrowmoderate Lowmoderate
Business Process Reengineering High High Very broad

Figure 4-4, p123
Lowmoderate Low Narrow Lowmoderate
Very high
17
References
Booch, Maksimchuk, Engle, Young, Conallen & Houston (2007) Object-Oriented Analysis and Design with Applications, 3e, AddisonWesley, Upper Saddle River, NJ
17 March, 2011
18
Requirements Determination techniques

Chapter 4: Dennis, Wixom and Tegarden
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition
Copyright 2009 John Wiley & Sons, Inc. All rights reserved.
Objectives
Become familiar with requirements determination or gathering techniques. Understand when to use each requirements gathering technique. Understand how to gather requirements using interviews, JAD sessions, questionnaires, document analysis, and observation. Understand when to use each requirementsgathering technique.
Terminology alert
Requirements gathering Requirements determination Requirements engineering Requirements elicitation are terms that are used interchangeably across many text books They mean the processes of finding out what the business must be able to do
Context
Some requirements gathering occurs during the planning phase of the SDLC in order to justify whether a project proceeds or not Once a project has been approved (refer ICT318) significant Requirements Gathering occurs during the Analysis phase of the SDLC As circumstances change during the project the Systems Analyst is always gathering some requirements
What is Data Gathering?

A simple task requiring the application of some basic common sense techniques to finding out what people want (as described in textbooks) or: A difficult task requiring skill and experience and which, even when done well, can produce incomplete or inadequate results (as practiced in industry)
What business data do you gather?
The business data gathered should include: Business system description how things actually work how things should work Business system problems what is wrong what needs improvement Opportunities - identifying scope for innovation or new ways of doing things
ICT117 Systems Analysis & Design, Semester 1, 2011 Includes John Wiley& Sons Inc material 24
17 March, 2011
What business data do you gather?
The business data gathered should include: Business system description how things actually work (as-is) how things should work (to-be) Business system problems what is wrong (faults) what needs improvement (inefficiencies) Opportunities - identifying scope for innovation or new ways of doing things
ICT117 Systems Analysis & Design, Semester 1, 2011 Includes John Wiley& Sons Inc material 25
17 March, 2011
Other information
You need to find out: what the Users want what the Owner will pay for what the Business actually needs what can be cost justified These four viewpoints could all be different What is technically possible? What constraints exist?
Sampling issues
All data gathering involves sampling. You dont get ALL data from ALL participants at ALL times, only responses from a sample of participants Ensure that the sample size and type you select for data gathering is statistically adequate
Analysing what you gather

You will need to negotiate some concessions and compromises to get a set of functional requirements that satisfy: The users The owners Business needs Technical limitations Constraints (political, financial, time, practical)
Information sources
System sponsor: overall project objectives and project management information Business managers: high-level system operational information Operational users: detailed system operational information
Information sources cont

Other related systems: interface and compatibility requirements Technical staff: technical resources, capabilities and limitations Customers and industry sources: external needs, industry trends Note: cross check information with different sources (triangulation)

ICT117 Week04 Requirements Determination S

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ICT117 Week04 Requirements Determination S

Caricato da

Copyright:

Formati disponibili

Requirements Determination

Chapter 4: Dennis, Wixom and Tegarden

Next week 24th March

The SDLC and Requirements

Cultural & Political

Requirements Definition Report aka FRS

(IEEE Standard 830-1998: Recommended Practice for Software Requirements Specifications)

REQUIREMENTS ANALYSIS STRATEGIES

Requirements Analysis Strategies

There are 3 requirements analysis strategies

Business Process Automation

Root Cause Analysis

Root Cause Analysis Example

Business Process Improvement

Business Process Reengineering

Selecting the Appropriate Strategies

Business Process Improvement Moderate Lowmoderate Narrowmoderate Lowmoderate

Business Process Reengineering High High Very broad

Lowmoderate Low Narrow Lowmoderate

Requirements Determination techniques

What is Data Gathering?

What business data do you gather?

What business data do you gather?

Analysing what you gather

Information sources cont

Potrebbero piacerti anche