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

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

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

4. StakeholderPerspective  Owner Scope (purpose)  UsersRequirements (what)  DesignersArch./Design (how)  BuildersImplem. /Testing (results) What the Designers and Builders developed What the Owners are willing to pay What the Users wanted

5.  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.  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.  Gather information on what the system should do from many sources › Users › Reports › Forms › Procedures Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.7

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

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

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

11.  Interviewing and Listening Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.11

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

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

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

15.  Directly Observing Users › Serves as a good method to supplement interviews › Often difficult to obtain unbiased data  People often work differently when being observed Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.15

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

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

18.  Joint Application Design (JAD) › Brings together key users, managers, and systems analysts › Purpose: collect system requirements simultaneously from key people › Conducted off-site Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.18

19.  Participants › Session leader › Users › Managers › Sponsor › Systems analysts › Scribe › IS staff  End Result - Documentation detailing › Existing system › Features of a replacement system Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.19

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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