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

2. Questionnaires 2

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

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

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

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

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

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

12. Before we start Evaluate the following questioner?

13. Context Diagram 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

14. Context Diagram of Alibris

15. Context of Quicken – 1995 (?) Slide 15

16. Quicken - 2006 Slide 16

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

18. 6 - 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. 6 - 19 Key Definitions Logical process models describe processes without suggesting how they are conducted. Physical process models include process implementation information.

20. 6 - 20 DATA FLOW DIAGRAMS

21. 6 - 21 Reading a DFD

22. 6 - 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. 6 - 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. 6 - 24 Naming and Drawing DFD Elements ProcessData flowData storeExternal entity

25. 6 - 25 Name the Entities of the DFD?

26. 5 - 26

27. 6 - 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. 6 - 28 Key Definition Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.

29. 6 - 29 Relationship Among DFD levels Context diagramLevel 0 diagramLevel 1 diagramLevel 2 diagram

30. 6 - 30 Context Diagram First DFD in every business process Shows the context into 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

31. 6 - 31 Level 0 Diagram 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

32. 6 - 32 Level 1 Diagrams Generally, one level 1 diagram is created for every major process on 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

33. 6 - 33 Level 2 Diagrams 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

34. 6 - 34 Data Flow Splits and Joins 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

35. 6 - 35 Alternative Data Flows 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

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. 6 - 37 Process Descriptions Text-based process descriptions provide more information about the process than 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

38. 6 - 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. 6 - 39 Decision Trees Graphical way of depicting if-then-else logic

40. 6 - 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? 5 - 41

42. 6 - 42 CREATING DATA FLOW DIAGRAMS

43. 6 - 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. 5 - 44 Use Case Analysis

45. 5 - 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 data models later based on the use cases

46. 5 - 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. 5 - 47 Role of Use Cases All possible responses to the event are documented Use cases are helpful when the situation is complicated

48. 5 - 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. 5 - 50 Building Use Cases

51. 5 - 51 Process of Developing Use Cases Identify the major use cases Identify the major steps within each use case Identify elements within steps Confirm the use case Cycle through the above steps iteratively

52. 5 - 52 Step 1 – Identify the major use cases Activities Typical Questions Asked Start a use case form for each use case If more than nine, group into packages Ask who, what, and where about the tasks and their inputs and outputs: What are the major tasks performed? What triggers this task? What tells you to perform this task? What information/forms/reports do you need to perform this task? Who gives you these information/forms/reports? What information/forms/reports does this produce and where do they go?

53. 5 - 53 Step 2 - Identify the major steps within each use case Activities Typical Questions Asked For each use case, fill in the major steps needed to process the inputs and produce the outputs Ask how about each use case: How do you produce this report? How do you change the information on the report? How do you process forms? What tools do you use to do this step (e.g., on paper, by email, by phone)?

54. 5 - 54 Step 3 – Identify elements within steps Activities Typical Questions Asked For each step, identify its triggers and its inputs and outputs Ask how about each step How does the person know when to perform this step? What forms/reports/data does this step produce? What forms/reports/data does this step need? What happens when this form/report/data is not available?

55. 5 - 55 Step 4 – Confirm the use case Activities Typical Questions Asked For each use case, validate that it is correct and complete Ask the user to execute the process using the written steps in the use case – that is, have the user role-play the use case

60. 5 - 60 Summary Use cases contain all the information needed for process modeling, but are easier for users to comprehend Use cases are created in an iterative cycle of steps until they are considered accurate and complete

61. Some of the Use Cases to work on Registration Use Cases Grades recording Use Case Uploading lectures Use Case Exams Use Case 5 - 61

62. 6 - 62 Steps in Building DFDs Build the context diagram Create DFD fragments for each use case Organize DFD fragments into level 0 diagram Decompose level 0 processes into level 1 diagrams as needed; decompose level 1 processes into level 2 diagrams as needed; etc. Validate DFDs with user to ensure completeness and correctness

63. 6 - 63 Build the Context Diagram Draw one process representing the entire system (process 0) Find all inputs and outputs listed at the top of the use cases that come from or go to external entities; draw as data flows Draw in external entities as the source or destination of the data flows

64. 6 - 64 A Context Diagram Example

65. 6 - 65 Creating DFD Fragments Each use case is converted into one DFD fragment Number the process the same as the use case number Change process name into verb phrase Design the processes from the viewpoint of the organization running the system

66. 6 - 66 Creating DFD Fragments Add data flows to show use to data stores as sources and destinations of data Layouts typically place processes in the center inputs from the left outputs to the right stores beneath the processes

67. 6 - 67 A DFD Fragment Example

68. 6 - 68 Creating the Level 0 Diagram Combine the set of DFD fragments into one diagram Generally move from top to bottom, left to right Minimize crossed lines Iterate as needed DFDs are often drawn many times before being finished, even with very experienced systems analysts

69. 6 - 69 A Level 0 DFD Example

70. 6 - 70 Creating Level 1 Diagrams (and Below) Each use case is turned into its own DFD Take the steps listed on the use case and depict each as a process on the level 1 DFD Inputs and outputs listed on use case become data flows on DFD Include sources and destinations of data flows to processes and stores within the DFD May also include external entities for clarity

71. 6 - 71 Creating Level 1 Diagrams (and Below) Input data flows shown on a parent DFD are often unbundled on the child diagram using splits Output data flows shown on a child DFD are often bundled using joins and shown as a larger data flow on the parent diagram When to stop decomposing DFDs? Ideally, a DFD has at least 3 processes and no more than 7-9.

72. 6 - 72 Validating the DFD Syntax errors – diagram follows the rules Assure correct DFD structure For each DFD: Check each process for: A unique name: action verb phrase; number; description At least one input data flow At least one output data flow Output data flow names usually different than input data flow names Between 3 and 7 processes per DFD

73. 6 - 73 Validating the DFD For each DFD: Check each data flow for: A unique name: noun; description Connects to at least one process Shown in only one direction (no two-headed arrows) A minimum number of crossed lines Check each data store for: A unique name: noun; description At least one input data flow At least one output data flow Check each external entity for: A unique name: noun; description At least one input or output data flow

74. 6 - 74 Validating the DFD Across DFDs: Context Diagram: Every set of DFDs must have one Context Diagram Viewpoint: There is a consistent viewpoint for the entire set of DFDs Decomposition: Every process is wholly and complete described by the processes on its children DFDs Balance: Every data flow, data store, and external entity on a higher level DFD is shown on the lower level DFD that decomposes it No data stores or data flows appear on lower-lever DFDs that do not appear on their parent DFD

75. 6 - 75 Validating the DFD Semantics errors – diagram conveys correct meaning Assure accuracy of DFD relative to actual/desired business processes To verify correct representation, use User walkthroughs Role-play processes Examine lowest level DFDs to ensure consistent decomposition Examine names carefully to ensure consistent use of terms

76. 6 - 76 Summary The Data Flow Diagram (DFD) is an essential tool for creating formal descriptions of business processes. Use cases record the input, transformation, and output of business processes and are the basis for process models. Eliciting use cases and modeling business processes are critically important skills for the systems analyst to master.

77. When databases are used, we need schema translation ? 5 - 77

78. 78 Schema Translation

79. 79 Extended Entity Relationship(EER) Model The ER model has been widely used but does not have some shortcomings. It is difficult to represent cases where an entity may have varying attributes dependent upon some property. ER model has been extended into Extended Entity Relationship model It includes more semantics such as generalization, categorization and aggregation.

80. 80 Cardinality: One-to-one relationship A one-to-one relationship between set A and set B is defined as: For all a in A, there exists at most one b in B such that a and b are related, and vice versa. Example A president leads a nation.

81. 81 Cardinality: One-to-one relationship Relational Model: Relation President (President_name, Race, *Nation_name) Relation Nation (Nation_name, Nation_size) Where underlined are primary keys and "*" prefixed are foreign keys Extended Entity Relationship model

82. 82 In Election System : One-to-one relationship !!!!! Person and ID Persons’ and Vote Judge and Box Username and Person

83. 83 Cardinality: Many-to-one relationship A many-to-one relationship from set A to set B is defined as: For all a in A, there exists at most one b in B such that a and b are related, and for all b in B, there exists zero or more a in A such that a and b are related. Example A director directs many movies.

84. 84 Cardinality: Many-to-one relationship Relational Model: Relation Director (Director_name, Age) Relation Movies (Movie_name, Sales_volume, *Director_name) Extended entity relationship model:

85. 85 In Election System : many to one relationship !!!! Box and judge President position and candidates Candidate and votes Candidate and position

86. 86 Cardinality: Many-to-many relationship A many-to-many relationship between set A and set B is defined as: For all a in A, there exists zero or more b in B such that a and b are related, and vice versa. Example Many students take many courses such that a student can take many courses and a course can be taken by many students. many-many

87. 87 Cardinality: Many-to-many relationship Relational Model: Relation Student (Student_id, Student_name) Relation Course (Course_id, Course_name) Relation take (*Student_id, *Course_id) Extended entity relationship model:

88. 88 In Election System : many to many relationship !!!! Boxes and judges at the same place Security table contains many user names and passwords for many persons

89. 89 Data Semantic: Is-a (Subtype) relationship The relationship A isa B is defined as: A is a special kind of B. Example Father is Male.

90. 90 Data Semantic: Is-a (Subtype) relationship Relational Model: Relation Male (Name, Height) Relation Father (*Name, Birth_date) Extended entity relationship model

91. 91 Data Semantic: Disjoint Generalization The process of generalization is to classify similar entities into a single entity. More than one isa relationship can form data abstraction (i.e. superclass and subclasses) among entities. A subclass entity is a subset of its superclass entity. There are two kinds of generalization. The first is disjoint generalization such that subclass entities are mutually exclusive. The second is overlap generalization such that subclass entities can overlap each other. Example of Disjoint Generalization A refugee and a non-refugee can both be a boat person, but a refugee cannot be a non-refugee, and vice versa.

92. 92 Data Semantic: Disjoint Generalization Relational Model: Relation Boat_person (Name, Birth_date, Birth_place) Relation Refugee (*Name, Open_center) Relation Non-refugee (*Name, Detention_center) Extended entity relationship model:

93. 93 Data Semantic: Overlap Generalization Example of Overlap Generalization A computer programmer and a system analyst can both be a computer professional, and a computer programmer can also be a system analyst, and vice versa.

94. 94 Data Semantic: Overlap Generalization Relational Model: Relation Computer_professional (Employee_id, Salary) Relation Computer_programmer (*Employee_id, Language_skill) Relation System_analyst (*Employee_id, Application_system) Extended entity relationship model:

95. 95 Data Semantic: Categorization Relationship In cases the need arises for modeling a single superclass/subclass relationship with more than one superclass(es), where the superclasses represent different entity types. In this case, we call the subclass a category.

96. 96 Data Semantic: Categorization Relationship Relational Model: Relation Department (Borrower_card, Department_id) Relation Doctor (Borrower_card, Doctor_name) Relation Hospital (Borrower_card, Hospital_name) Relation Borrower (*Borrower_card, Return_date, File_id) Extended Entity Relationship Model

97. 97 Data Semantic: Aggregation Relationship Aggregation is a method to form a composite object from its components. It aggregates attribute values of an entity to form a whole entity. Example The process of a student taking a course can form a composite entity (aggregation) that may be graded by an instructor if the student completes the course.

98. 98 Data Semantic: Aggregation Relationship Relational Model: Relation Student (Student_no, Student_name) Relation Course (Course_no, Course_name) Relation Takes (*Student_no, *Course_no, *Instructor_name) Relation Instructor (Instructor_name, Department) Extended Entity Relationship Model

99. 99 Data Semantic: Total Participation An entity is in total participation with another entity provided that all data occurrences of the entity must participate in a relationship with the other entity. Example An employee must be hired by a department.

100. 100 Data Semantic: Total Participation Relational Model: Relation Department (Department_id, Department_name) Relation Employee (Employee_id, Employee_name, *Department_id) Extended entity relationship model:

101. 101 Data Semantic: Partial Participation An entity is in partial participation with another entity provided that the data occurrences of the entity are not totally participate in a relationship with the other entity. Example An employee may be hired by a department.

102. 102 Data Semantic: Partial Participation Relational Model: Relation Department (Department_id, Department_name) Relation Employee (Employee_no, Employee_name, &Department_id) Where & means that null value is allowed Extended entity relationship model:

103. 103 Data Semantic: Weak Entity The existence of a weak entity depends on its strong entity. Example A hotel room must concatenate hotel name for identification.

104. 104 Data Semantic: Weak Entity Relational Model: Relation Hotel (Hotel_name, Ranking) Relation Room (*Hotel_name, Room_no, Room_size) Extended entity relationship model

105. 105 Cardinality: N-ary Relationship Multiple entities relate to each other in an n-ary relationship. Example Employees use a wide range of different skills on each project they are associated with.

106. 106 Cardinality: N-ary Relationship Relational Model: Relation Engineer (Employee_id, Employee_name) Relation Skill (Skill_name, Years_experience) Relation Project (Project_id, Start_date, End_date) Relation Skill_used (*Employee_id, *Skill_name, *Project_id) Extended entity relationship model:

107. 107 Example Drinkers addrname Beers manfname Bars name license addr Note: license = beer, full, none Sells Bars sell some beers. Likes Drinkers like some beers. Frequents Drinkers frequent some bars.

108. Example 108 For the relationship Sells, we might have a relationship set like: BarBeer Joe’s BarBud Joe’s BarMiller Sue’s BarBud Sue’s BarPete’s Ale Sue’s BarBud Lite

109. Example 109 Bars Beers Drinkers name addr manf nameaddr license Preferences

110. A Typical Relationship Set 110 BarDrinker Beer Joe’s BarAnnMiller Sue’s BarAnnBud Sue’s Bar AnnPete’s Ale Joe’s BarBobBud Joe’s Bar BobMiller Joe’s Bar CalMiller Sue’s Bar CalBud Lite

111. 111 Your Assignment Build Entity-relationship model Relation Order (Order_code, Order_type, Our_reference, Order_date, Approved_date, *Head, *Supplier_code) Relation Supplier (Supplier_code, Supplier_name) Relation Product (Product_code, Product_description) Relation Department (Department_code, Department_name) Relation Head (Head, *Department_code, Title) Relation Order_Product (*Order_code, *Product_code, Qty, Others, Amount) Relation Note (*Order_code, Sequence#, Note) where underlined are primary keys and prefixed with ‘*’ are foreign keys.