Chapter 5 Determining System Requirements Essentials of Systems Analysis and Design Fifth Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter 5 Determining System Requirements Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.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.2 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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 Users wanted What the Owners are willing to pay What the Designers and Builders developed

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.7 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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.8 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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

Traditional Methods for Determining Requirements 5.10 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

Traditional Methods for Determining Requirements Interviewing and Listening 5.11 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

Traditional Methods for Determining Requirements 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.12 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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

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

Traditional Methods for Determining Requirements 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.15 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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.16 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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

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.18 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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.19 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

Joint Application Design 5.20 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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.21 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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.22 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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

Function-Oriented Approaches Entity relationship diagrams (ERDs) Data flow diagrams (DFDs) State (transition) diagrams Screen prototyping (story-boards) Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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

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

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

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.28 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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.29 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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.30 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

Object-Oriented Approaches (App. A) Use-case modeling Object modeling – class diagrams Relationship diagrams Generalization/Abstraction models Aggregation models State diagrams Sequence diagrams Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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

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

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

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

Representing Aggregation A part-of relationship between a component object and an aggregate object A.36 Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall

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