CHAPTER 7: Determining System Requirements

1. MSIS 5653Advanced Systems DevelopmentDursun Delen, Ph.D.Department of ManagementOklahoma State University CHAPTER 7: Determining System Requirements 1.1

2. Learning Objectives • Learn the classical and modern approaches to Requirements Determination • Describe options for designing and conducting interviews and develop a plan for conducting an interview to determine system requirements • Design, distribute, and analyze questionnaires to determine system requirements • Explain advantages and pitfalls of observing workers and analyzing business documents to determine requirements 7.3

3. Learning Objectives • Explain how computing can provide support for requirements determination (GSS) • Learn about Joint Application Design (JAD) • Use prototyping during requirements determination • Select the appropriate methods to discover system requirements • Apply requirements determination to Internet applications 7.4

4. Determining System Requirements in SDLC

5. Performing Requirements Determination • Organizational needs derive the requirements • Gather information on what system should do from many sources • People • Reports • Forms • Procedures 7.6

6. Performing Requirements Determination • Characteristics for gathering requirements • Impertinence • Question everything • Impartiality • Find the best organizational solution • Relaxation of constraints • Attention to detail • Reframing • View the organization in new ways 7.7

7. Deliverables and Outcomes • Types of deliverables: • Information collected from users • Existing documents and files • Computer-based information • Understanding of organizational components • Business objective • Information needs • Rules of data processing • Key events with respect to changes on the data values 7.8

8. Traditional Methods for Determining Requirements • Interviewing and Listening • Gather facts, opinions and speculations • Observe body language and emotions • Guidelines • Plan • Checklist • Appointment • Be neutral • Listen • Seek a diverse view 7.9

9. Traditional Methods for Determining Requirements • Interviewing (Continued) • Interview Questions • Open-Ended • No pre-specified answers • Close-Ended • Respondent is asked to choose from a set of specified responses • T/F, M/C, Rating, and Ranking • Additional Guidelines • Do not phrase questions in ways that imply a wrong or right answer • Listen very carefully to what is being said • Type up notes within 48 hours • Do not set expectations about the new system • Seek a variety of perspectives 7.10

10. Traditional Methods for Determining Requirements • Administering Questionnaires • More cost-effective than interviews • Choosing respondents • Should be representative of all users • Types of sampling methods • Convenient • Random sample • Purposeful sample • Stratified sample • Design • Mostly closed-ended questions • Can be administered over the phone or in person 7.11

11. Traditional Methods for Determining Requirements • Questionnaires vs. Interviews 7.12

12. Traditional Methods for Determining Requirements • Interviewing Groups • Advantages • More effective use of time • Enables people to hear opinions of others and to agree or disagree • Disadvantages • Difficulty in scheduling • Nominal Group Technique • Facilitated process to support idea generation by groups • Individuals work alone to generate ideas which are pooled under guidance of a trained facilitator 7.13

13. 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 • Time and motion study? 7.14

14. Traditional Methods for Determining Requirements • Analyzing Procedures and Other Documents • Types of information to be discovered: • Problems with existing system • Opportunity to meet new need • Organizational direction • Names of key individuals • Values of organization • Special information processing circumstances • Reasons for current system design • Rules for processing data 7.15

15. Traditional Methods for Determining Requirements • Analyzing Procedures and Other Documents • Four types of useful documents • Written work procedures • Describes how a job is performed • Includes data and information used and created in the process of performing the job or task • Business form • Explicitly indicate data flow in or out of a system • Report • Enables the analyst to work backwards from the report to the data that generated it • Description of current information system 7.16

16. Example:Business Forms and Reports

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 • Prototyping • Repetitive process • Rudimentary version of system is built • Replaces or augments SDLC • Goal: to develop concrete specifications for ultimate system 4.18

18. Joint Application Design (JAD) • Participants • Session Leader • Users • Managers • Sponsor • Systems Analysts • Scribe • IS Staff 4.19

19. Joint Application Design (JAD) • End Result • Documentation detailing existing system • Features of proposed system • CASE Tools During JAD • Upper CASE tools are used • Enables analysts to enter system models directly into CASE during the JAD session • Screen designs and prototyping can be done during JAD and shown to users 4.20

20. Joint Application Design (JAD) • Supporting JAD with GSS • Group support systems (GSS) can be used to enable more participation by group members in JAD • Members type their answers into the computer • All members of the group see what other members have been typing 7.21

21. Prototyping • Quickly converts requirements to working version of system • Once the user sees requirements converted to system, will ask for modifications or will generate additional requests • Most useful when: • User requests are not clear • Few users are involved in the system • Designs are complex and require concrete form • History of communication problems between analysts and users • Tools are readily available to build prototype 7.22

22. Prototyping • Drawbacks • Tendency to avoid formal documentation • Difficult to adapt to more general user audience • Sharing data with other systems is often not considered • Systems Development Life Cycle (SDLC) checks are often bypassed 7.23

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

24. Business Process Reengineering (BPR) • Identification of processes to reengineer • Key business processes • Set of activities designed to produce specific output for a particular customer or market • Focused on customers and outcome • Same techniques are used as were used for requirements determination • Disruptive technologies • Technologies that enable the breaking of long-held business rules that inhibit organizations from making radical business changes >>> 7.25

25. Business Process Reengineering (BPR) 7.26

26. Summary • Interviews • Open-ended and close-ended questions • Preparation is key • Questionnaires • Must be carefully designed • Can contain close-ended as well as open-ended questions • Other means of gather requirements • Observing workers • Analyzing business documents • Joint Application Design (JAD) • Prototyping • Business Process Reengineering (BPR) 7.27

27. CHAPTER 8: Structuring Systems Requirements: Process Modeling 2.28

28. Learning Objectives • Understand the logical modeling of processes through studying data flow diagrams • How to draw data flow diagrams using rules and guidelines • How to decompose data flow diagrams into lower-level diagrams • Balancing of data flow diagrams 8.2

29. Learning Objectives • Explain the differences among four types of DFDs: current physical, current logical, new physical and new logical • Discuss the use of data flow diagrams as analysis tools • Compare and contrast data flow diagrams with Oracle’s process modeling tool and with functional hierarchy diagrams • Discuss process modeling for Internet applications 8.30

30. Requirement Structuring: Process Modeling in SDLC 8.31

31. Process Modeling • Graphically represent the processes that capture, manipulate, store and distribute data between a system and its environment and among system components • Data flow diagrams (DFD) • Graphically illustrate movement of data between external entities and the processes and data stores within a system 8.32

32. Process Modeling • Modeling a system’s process • Utilize information gathered during requirements determination • Structure of the data is also modeled in addition to the processes • Deliverables and Outcomes • Set of coherent, interrelated data flow diagrams >>> 8.33

33. Process Modeling • Deliverables and outcomes (Continued…) • Context data flow diagram (DFD) • Scope of system • DFDs of current system • Enables analysts to understand current system • DFDs of new logical system • Technology independent • Show data flows, structure and functional requirements of new system • Project dictionary and CASE repository 8.34

34. Data Flow Diagramming Mechanics • Four symbols are used… 8.35

35. Data Flow Diagramming Mechanics • Data Flow • Depicts data that are in motion and moving as a unit from one place to another in the system. • Drawn as an arrow • Select a meaningful name to represent the data 8.36

36. Data Flow Diagramming Mechanics • Data Store • Depicts data at rest • May represent data in • File folder • Computer-based file • Notebook • The name of the store as well as the number are recorded in between lines 8.37

37. Data Flow Diagramming Mechanics • Process • Depicts work or action performed on data so that they are transformed, stored or distributed • Number of process as well as name are recorded • Name is a verb phrase 8.38

38. Data Flow Diagramming Mechanics • Source/Sink • Depicts the origin and/or destination of the data • Sometimes referred to as an external entity • Drawn as a square symbol • Name states what the external agent is • Because they are external, many characteristics are not of interest to us • Interactions that occur between sources and sinks • What they do with the information internally • How to control or redesign them • How to provide them with direct access to data stores 8.39

39. Data Flow Diagramming Definitions • Context Diagram • A data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system • Level-0 Diagram • A data flow diagram (DFD) that represents a system’s major processes, data flows and data stores at a high level of detail 8.40

40. Developing DFDs: An Example • Hoosier Burger’s automated food ordering system • Context Diagram (Figure 8-4) contains no data stores • Next step is to expand the context diagram to show the breakdown of processes (Figure 8-5) 8.41

41. Figure 8-4Context diagram of Hoosier Burger’s food ordering system 8.42

42. Figure 8-5Level-0 DFD of Hoosier Burger’s food ordering system 8.43

43. Data Flow Diagramming Rules • Basic rules that apply to all DFDs • Inputs to a process are always different than outputs • Objects always have a unique name • In order to keep the diagram uncluttered, you can repeat data stores and sources/sinks on a diagram 8.44

44. Process A. No process can have only outputs (a miracle) B. No process can have only inputs (black hole) C. A process has a verb phrase label Data Store D. Data cannot be moved directly from one store to another E. Data cannot move directly from an outside source to a data store F. Data cannot move directly from a data store to a data sink G. Data store has a noun phrase label Data Flow Diagramming Rules 8.45

45. Source/Sink H. Data cannot move directly from a source to a sink I. A source/sink has a noun phrase label Data Flow J. A data flow has only one direction of flow between symbols K. A fork means that exactly the same data goes from a common location to two or more processes, data stores or sources/sinks Continues >>> Data Flow Diagramming Rules 8.46

46. Data Flow Diagramming Rules • Data Flow (Continued…) • L. A join means that exactly the same data comes from any two or more different processes, data stores or sources/sinks to a common location • M. A data flow cannot go directly back to the same process it leaves • N. A data flow to a data store means update • O. A data flow from a data store means retrieve or use • P. A data flow has a noun phrase label 8.47

47. Decomposition of DFDs • Functional decomposition • Iterative process of breaking the description of a system/process down into finer and finer detail • Repetitive procedure that creates hierarchically related set of diagrams representing the system • Lowest level is called a primitive DFD • Level-N Diagrams • A DFD that is the result of n nested decompositions of a series of sub-processes from a process on a level-0 diagram 8.48

48. Figure 8-7: Level-1 DFD showing the decomposition of Process 1.0 from the Level-0 diagram for Hoosier Burger’s food ordering system Process Numbering 0 1.0, 2.0, … 1.1, 1.2, … 1.1.1, 1.1.2, … 8.49

49. Balancing DFDs • When decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decomposition • This is called balancing • Example: Hoosier Burgers • In Figure 8-4, notice that there is one input to the system, the customer order • Three outputs: • Customer receipt • Food order • Management reports 8.50

50. Balancing DFDs • Example (Continued) • Notice Figure 8-5. We have the same inputs and outputs • No new inputs or outputs have been introduced • We can say that the context diagram and level-0 DFD are balanced 8.51