1. System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach and object-oriented approach Events that trigger use cases Things in the users’ work domain

2. Models and Modeling Analyst describes information system requirements using a collection of models Complex systems require more than one type of model Models represent some aspect of the system being built Process of creating models helps analyst clarify and refine design Models assist communication with system users

3. Why modeling? Learning from modeling process Reduce complexity by abstraction Remembering the details Communicating with other team members, users, and stakeholders Documenting what was done for future maintenance/enhancement

4. Types of Models Different types of models are used in information systems development Mathematical – formulas that describe technical aspects of the system Descriptive – narrative memos, reports, or lists that describe aspects of the system Graphical – diagrams and schematic representations of some aspect of the system

5. Events Business events trigger elementary business processes (EBPs) EBPs are at correct level of analysis for use cases Business events are memorable, can be described, and occur at a specific time and place

6. Sequence of “Transactions” for One Specific Customer Resulting in Many Events

7. Types of Events External Outside system Initiated by external agent or actor Temporal Occur as result of reaching a point in time Based on system deadlines State Something inside system triggers processing need

8. Events Affecting a Charge Account Processing System

9. Events modeling Identify business events to decompose system into activities/use cases Use cases (activities) are identified from user goals and business events that trigger elementary business processes Event decomposition is, therefore, used by Traditional approach to identify activities OO approach to identify use cases Event table records event, trigger, source, use case, response, and destination

10. Information about Each Event in an Event Table

11. Things “Things” are what user deals with and system remembers, such as an order placed by a customer Analysts identify these types of things by considering each use case in the event table What things does the system need to know about and store information about?

12. Types of Things

13. Modeling things Traditional approach uses entity- relationship diagrams (ERD) for data entities, attributes of data entities, and relationships between entities Object-oriented approach uses UML class diagrams for classes, attributes, methods of class, and associations among classes

14. Traditional and OO Approach

15. Components of a Traditional Analysis Model

16. Data Flow Diagrams (DFDs) Graphical system model that shows all main requirements for an IS in one diagram Inputs/outputs Processes Data storage Easy to read and understand with minimal training

17. Data Flow Diagram Symbols

20. DFD Integrates Event Table and ERD

21. DFD and Levels of Abstraction Data flow diagrams (DFDs) are decomposed into additional diagrams to provide multiple levels of detail Higher-level diagrams provide general views of system Lower-level diagrams provide detailed views of system Differing views are called levels of abstraction

22. Layers of DFD Abstraction for Course Registration

23. Context Diagrams DFD that summarizes all processing activity for the system or subsystem Highest level (most abstract) view of system Shows system boundaries System scope is represented by a single process, external agents, and all data flows into and out of the system

24. Context Diagram External entity External entity External entity The System Data Flow Data Flow Data Flow Data Flow

28. DFD Fragments Created for each use case in the event table Represent system response to one event within a single process symbol Self-contained models Focus attention on single part of system Show only data stores required in the use case

29. Three Separate DFD Fragments for Course Registration System

30. Event-Partitioned System Model DFD to model system requirements using single process for each use case/activity in system or subsystem Combines all DFD fragments together to show decomposition of the context-level diagram Sometimes called “diagram 0” Used primarily as a presentation tool Decomposed into more detailed DFD fragments

31. Combining DFD Fragments to Create Event- Partitioned System Model

32. Decomposing DFD Fragments Most DFD fragments can be further described using structured English Sometimes DFD fragments need to be diagrammed in more detail Decomposed into subprocesses in a detailed DFD

33. Layers of DFD Abstraction for Course Registration

34. DFD Practice Precision tools sells a line of high-quality woodworking tools. When customers place orders on the company’s web site, the system checks to see if the items are in stock, issues a status message to the customer, and generates a shipping order to the warehouse, which fills the order. When the order is shipped, the customer is billed. The system also produces various reports.

35. DFD Practice Draw a context diagram System scope is represented by a single process, external agents, and all data flows into and out of the system Draw Level-0 diagram Identify the major use cases Draw DFD fragment for each use case Combine DFD fragments together at the same level of detail

36. Context Diagram

37. Five Separate DFD Fragments

38. Detailed DFD for Create new order

39. Evaluating DFD Quality Readable Internally consistent and balanced Accurately represents system requirements Reduces information overload – rule of 7 +/- 2 Minimizes required number of interfaces

40. Data Flow Consistency Problems Differences in data flow content between a process and its process decomposition Data outflows without corresponding inflows Data inflows without corresponding outflows Results in unbalanced DFDs

41. Consistency Rules All data that flows into a process must Flow out of the process, or Be used to generate data that flows out of the process All data that flows out of a process must Have flowed into the process, or Have been generated from data that flowed into the process

42. Unnecessary Data Input: Black Hole

43. Process with Impossible Data Output: A Miracle

44. Process with Unnecessary Data Input

45. Process with Impossible Data Output

46. Documentation of DFD Components Lowest-level processes need to be described in detail Data flow contents need to be described Data stores need to be described in terms of data elements Each data element needs to be described Various options for process definition exist

47. Structured English Method of writing process specifications Combines structured programming techniques with narrative English Well-suited for lengthy sequential processes or simple control logic (single loop or if-then-else) Ill-suited for complex decision logic or few (or no) sequential processing steps

48. Structured English Process Description

50. Decision Tables and Decision Trees Can summarize complex decision logic better than structured English Incorporate logic into the table or tree structure to make descriptions more readable

51. Decision Tables

52. Decision Tree

53. Decision Tables for Calculating Shipping Charges

54. Decision Tree for Calculating Shipping Charges

55. Data Flow Definitions Textual description of data flow’s content and internal structure Often coincide with attributes of data entities included in ERD plus computed values Algebraic notion describes data elements on data flow plus data structure

56. Data Element Definitions Data type description String, integer, floating point, Boolean Sometimes very specific written description Length of element Maximum and minimum values Data dictionary – repository for definitions of data flows, data stores, and data elements

57. Data Element Definition

58. Physical and Logical DFDs Logical model Assumes implementation in ideal situation Does not tell how system is implemented Physical model Describes assumptions about implementation technology Developed in last stages of analysis or in early design Current physical -> Current logical -> New logical -> New physical

59. Summary Data flow diagrams (DFDs) are used in combination with event table and entity- relationship diagram (ERD) to model system requirements DFDs model system as set of processes, data flows, external agents, and data stores DFDs easy to read – graphically represent key features of system using small set of symbols

60. Assignment 2 Draw a context diagram of the proposed student housing system Draw a level-0 data flow diagram. Specify the main functions of the system (data flow, process, and data store). Draw a level-1 data flow diagram for the process of student searching for houses. Use of drawing tools

61. http://www.homes4students.ca/add_a_listing.html

62. http://www.homes4students.ca/ontario.html