Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.1.

Essentials ofSystems Analysis and Design

Fifth Edition Joseph S. Valacich

Joey F. GeorgeJeffrey A. Hoffer

Chapter 5 Determining System

Requirements

Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

5.15.1

Learning Objectives

Fundamentals of requirements Options for designing and conducting

requirements analysis interviews Advantages and disadvantages of

various requirements analysis methods Joint Application Design (JAD) Value of Prototyping during analysis


5.25.2

Requirements: Necessity not Luxury

A defective requirement is 20-50 times more expensive to repair at end of a project than at beginning ($100 -> $2000-5000)

Requirements analysis is something we must afford to due

So why do we not do it? So why do we not do it well? Instead … code and test, code and test

Project Stakeholders

Stakeholder Perspective Owner Scope (purpose) Users Requirements (what) Designers Arch./Design (how) Builders Implem. /Testing

(results)What the Designers andBuilders developed

What the Ownersare willing to pay

What the Users wanted

http://images.google.com/imgres?imgurl=http://www.vinography.com/archives/images/pennies.gif&imgrefurl=http://www.vinography.com/archives/ramblings_and_rants/&h=144&w=180&sz=5&hl=en&sig2=a9somOnL-_1QtA56O50N8w&start=3&tbnid=HnrO1L95W483WM:&tbnh=81&tbnw=101&ei=yyylRf3wIYn2aL7cjcsO&prev=/images?q=pennies&svnum=10&hl=en&lr=&sa=G

http://images.google.com/imgres?imgurl=http://www.adlertech.com/Site%2520Graphics/Amer%2520dollars%2520sm.jpg&imgrefurl=http://www.jaani.net/view/crime_and_security&h=187&w=216&sz=14&hl=en&sig2=FBmxUpRLHi95fi6upvWn3w&start=4&tbnid=ATqDbRqZvkUliM:&tbnh=93&tbnw=107&ei=6SylRZ6qL6D8aKul8NAO&prev=/images?q=dollars&svnum=10&hl=en&lr=

Why must requirements be written down?

Define the goals of the project Sets customer expectations Basis of the contract between customer

and supplier Writing is thinking Allows thorough inspection and testing Can be kept up to date Allows tracking - estimates/actuals Team communication tool

Each requirement must be …· Expressed properly,· Validated· Made easily accessible,· Numbered, · Accompanied by tests that verify it, · Provided for in the design, · Accounted for by code, · Tested in isolation, · Tested in concert with other requirements· Validated by the user

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Performing Requirements Determination

Gather information on what the system should do from many sources› Users› Reports› Forms› Procedures


5.75.7

Performing Requirements Determination

Characteristics for Gathering Requirements› Impertinence

Question everything› Impartiality

Find the best organizational solution› Relaxation of constraints

Assume anything is possible and eliminate the infeasible

› Attention to detail Every fact must fit with every other fact

› Reframing View the organization in new ways


5.85.8


5.95.9

Traditional Methods for Determining Requirements


5.105.10


Interviewing and Listening


5.115.11


Interviewing and Listening› Gather facts, opinions, and speculations› Observe body language and emotions› Interview Questions

Open-Ended No pre-specified answers Used to probe for unanticipated answers

Close-Ended Respondent is asked to choose from a set of specified

responses Work well when the popular answers to questions are

known Do not require a long period of time, and can cover a

greater number of topics


5.125.12


5.135.13


5.145.14


Directly Observing Users› Serves as a good method to supplement

interviews› Often difficult to obtain unbiased data

People often work differently when being observed


5.155.15

Analyzing Procedures and Other Documents

Types of Information to be discovered:› Problems with existing system› Opportunity to meet new need› Organizational direction› Title and names of key individuals› Values of organization› Special information processing circumstances› Rules for processing data


5.165.16


5.175.17

Modern Methods for Determining Requirements Joint Application Design (JAD)

› Brings together key users, managers, and systems analysts

› Purpose: collect system requirements simultaneously from key people

› Conducted off-site


5.185.18

Joint Application Design Participants

› Session leader› Users› Managers› Sponsor› Systems analysts› Scribe› IS staff

End Result - Documentation detailing › Existing system› Features of a replacement system


5.195.19


5.205.20

Joint Application Design

Business Process Reengineering (BPR)

Search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services

Goals› Reorganize complete flow of data in major

sections of an organization› Eliminate unnecessary steps› Combine steps› Become more responsive to future change


5.215.21

Business Process Reengineering (BPR)

Identify specific activities that can be improved through BPR

Disruptive Technologies› Technologies that enable the breaking of

long-held business rules that inhibit organizations from making radical business changes

› See Table 5-5


5.225.22


5.235.23

Function-Oriented Approaches

Entity relationship diagrams (ERDs) Data flow diagrams (DFDs) State (transition) diagrams Screen prototyping (story-boards)



7.257.25


6.266.26


A.27A.27

Prototyping

Repetitive process Rudimentary version of system is built Replaces or augments SDLC Develops more concrete specifications

for ultimate system Allows user to sees requirements converted to

system - will ask for modifications as needed


5.285.28

Prototyping

Most useful when:› User requirements are not clear› Designs are complex and require concrete

form to evaluate fully› History of communication problems

between analysts and users› Tools are readily available to build

prototype


5.295.29

Prototyping

Drawbacks› Tendency to avoid formal documentation› Sharing data with other systems is often

not considered› Systems Development Life Cycle (SDLC)

checks are often bypassed› User may misunderstand complexity of SD

process


5.305.30

Object-Oriented Approaches (App. A)

Use-case modeling Object modeling – class diagrams Relationship diagrams Generalization/Abstraction models Aggregation models State diagrams Sequence diagrams



A.32A.32


A.33A.33


A.34A.34


A.35A.35

Representing Aggregation

Aggregation› A part-of relationship between a

component object and an aggregate object


A.36A.36


A.37A.37

Date post:	03-Jan-2016
Category:	Documents
Upload:	cory-watson
View:	217 times
Download:	0 times