1. 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

2. 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

3. Requirements: Necessity not Luxury
A defective requirement is times more expensive to repair at end of a project than at beginning ($100 -> $ )
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

4. 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

5. 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

6. 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.

7. 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

8. 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

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

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

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

12. 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

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

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

15. 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

16. 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

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

18. 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

19. 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

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

21. 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

22. 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

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

24. 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

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

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

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

28. 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

29. 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

30. 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

31. 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

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

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

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

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

36. 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

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