Systems Analysis and Design

1. Systems Analysis and Design Rabie A. Ramadan Slides by Roberta M. Roth University of Northern Iowa

2. Questionnaires

3. A set of written questions, often sent to a large number of people May be paper-based or electronic Select participants using samples of the population Design the questions for clarity and ease of analysis Administer the questionnaire and take steps to get a good response rate Questionnaire follow-up report Questionnaires

4. Good Questionnaire Design • Begin with non-threatening and interesting questions • Group items into logically coherent sections • Do not put important items at the very end of the questionnaire • Do not crowd a page with too many items • Avoid abbreviations • Avoid biased or suggestive items or terms • Number questions to avoid confusion • Pretest the questionnaire to identify confusing questions • Provide anonymity to respondents

5. Document Analysis

6. Study of existing material describing the current system Forms, reports, policy manuals, organization charts describe the formal system Look for the informal system in user additions to forms/report and unused form/report elements User changes to existing forms/reports or non-use of existing forms/reports suggest the system needs modification Document Analysis

7. Observation

8. Watch processes being performed Users/managers often don’t accurately recall everything they do Checks validity of information gathered other ways Be aware that behaviors change when people are watched Be modest (seems to be shy) Identify peak and lull (quite) periods Observation

9. Type of information Depth of information Breadth of information Integration of information User involvement Cost Combining techniques Selecting the Appropriate Requirements-Gathering Techniques

10. Design a Questionnairefor the project ? Report your observations on the current projects and usabilities ? Collect at least 5of them Your turn

11. At the core: any system is defined by the data obtained, stored, and displayed Data flow analysis is the center/core/key The System is the Data

12. Evaluate the following questioner? Before we start

13. Shows the context into which the system fits Shows the overall business process as just one process Shows all the outside entities that receive information from or contribute information to the system Context Diagram

14. Context Diagram of Alibris

15. Context of Quicken – 1995 (?)

16. Quicken - 2006

17. Draw the context diagram for e-learning system ? Your turn

18. Key Definitions • Process model • A formal way of representing how a business operates • Illustrates the activities that are performed and how data moves among them • Data flow diagramming • A popular technique for creating process models

19. Key Definitions • Logicalprocess models describe processes without suggesting how they are conducted. • Physical process models include process implementation information.

20. DATA FLOW DIAGRAMS

21. Reading a DFD

22. DFD Elements • Process • An activity or function performed for a specific business reason • Manual or computerized • Data flow • A single piece of data or a logical collection of data • Always starts or ends at a process

23. DFD Elements • Data Store • A collection of data that is stored in some way • Data flowing out is retrieved from the data store • Data flowing in updates or is added to the data store • External entity • A person, organization, or system that is external to the system but interacts with it.

24. Process Data flow Data store External entity Naming and Drawing DFD Elements

25. Name the Entities of the DFD?

27. Depicting Business Processes with DFDs • Business processes are too complex to be shown on a single DFD • Decomposition is the process of representing the system in a hierarchy of DFD diagrams • Child diagrams show a portion of the parent diagram in greater detail

28. Balancinginvolves insuring that information presented at one level of a DFD is accurately represented in the next level DFD. Key Definition

29. Context diagram Level 0 diagram Level 1 diagram Level 2 diagram Relationship Among DFD levels

30. First DFD in every business process Shows the contextinto which the business process fits Shows the overall business process as just one process (process 0) Shows all the external entities that receive information from or contribute information to the system Context Diagram

31. Shows all the major processes that comprise the overall system – the internal components of process 0 Shows how the major processes are interrelated by data flows Shows external entities and the major processes with which they interact Adds data stores Level 0 Diagram

32. Generally, one level 1 diagram is created for every major processon the level 0 diagram Shows all the internal processes that comprise a single process on the level 0 diagram Shows how information moves from and to each of these processes If a parent process is decomposed into, for example, three child processes, these three child processes wholly and completely make up the parent process Level 1 Diagrams

33. Shows all processes that comprise a single process on the level 1 diagram Shows how information moves from and to each of these processes Level 2 diagrams may not be needed for all level 1 processes Correctly numbering each process helps the user understand where the process fits into the overall system Level 2 Diagrams

34. A data flow split shows where a flow is broken into its component parts for use in separate processes Data flow splits need not be mutually exclusive nor use all the data from the parent flow As we move to lower levels we become more precise about the data flows A data flow join shows where components are merged to describe a more comprehensive flow Data Flow Splits and Joins

35. Where a process can produce different data flows given different conditions We show both data flows and use the process description to explain why they are alternatives Tip -- alternative data flows often accompany processes with IF statements Alternative Data Flows

36. Your Turn • At this point in the process it is easy to lose track of the “big picture”. • Describe the difference between data flows, data stores, and processes. • Describe in your own words the relationship between the DFD and the ultimate new application being developed.

37. Text-based process descriptions provide more information about the processthan the DFD alone If the logic underlying the process is quite complex, more detail may be needed in the form of Structured English Decision trees Decision tables Process Descriptions

38. Structured English Common Statements Example Action Statement Profits = Revenues - Expenses Generate Inventory Report Add Product record to Product Data Store If Statement IF Customer Not in Customer Data Store THEN Add Customer record to Customer Data Store ELSE Add Current Sale to Customer’s Total Sales Update Customer record in Customer Data Store For Statement FOR all Customers in Customer Data Store, do Generate a new line in the Customer Report Add Customer’s Total Sales to Report Total Case Statement CASE If Income < 10,000: Marginal tax rate = 10% If Income < 20,000: Marginal tax rate = 20% If Income < 30,000: Marginal tax rate = 31% If Income < 40,000: Marginal tax rate = 35% ELSE Marginal tax rate = 38% ENDCASE

39. Decision Trees • Graphical way of depicting if-then-else logic

40. Decision Tables • Represent very complex processes with multiple decision rules

41. Explain the following decision tree ? When should I take a decision not to buy?

42. CREATING DATA FLOW DIAGRAMS

43. Integrating Scenario Descriptions • DFDs start with the use cases and requirements definition • Generally, the DFDs integrate the use cases • Names of use cases become processes • Inputs and outputs become data flows • “Small” data inputs and outputs are combined into a single flow

44. Use Case Analysis

45. Key Ideas • Use cases are a text-based method of describing and documenting complex processes • Use cases add detail to the requirements outlined in the requirement definition • Systems analysts work with users to develop use cases • Systems analysts develop process and datamodels later based on the use cases

46. Role of Use Cases • A use case is a set of activities that produce some output result • Describes how the system reacts to an event that triggers the system • Trigger -- event that causes the use case to be executed • Event-driven modeling – everything in the system is a response to some triggering event

47. Role of Use Cases • All possible responses to the event are documented • Use cases are helpful when the situation is complicated

48. Elements of a Use Case • Basic information • Name, number and brief description • Trigger – event that causes the use case to being • External trigger – some from outside the system • Temporal triggers – time-based occurrences • Viewpoint of the use cases should be consistent • Major inputs and outputs • Sources and destinations • Goal is to be all inclusive • Details • Steps performed and the data inputs and outputs

49. Sample Use Case

50. Building Use Cases