The Traditional Approach to Requirements

1. The Traditional Approach to Requirements

2. Overview • What the system does what an event occurs: activities and interactions • Traditional structured approach to representing activities and interactions • Diagrams and other models of the traditional approach • RMO customer support system example shows how each model is related • How traditional and IE approaches and models can be used together to describe system

3. Traditional and Object-Oriented Views of Activities

4. Requirements Models for the Traditional and OO Approaches

5. Data Flow Diagrams • Graphical system model that shows all main requirements for an IS in one diagram • External entity • Data flow • Processes • Data storage • Easy to read and understand with minimal training

6. Data Flow Diagram Symbols

7. DFD Fragment from the RMO Case

8. DFD Integrates Event Table and ERD

9. 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

10. Layers of DFD Abstraction

11. Context Diagrams • DFD that summarizes all processing activity • 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 • Doesn’t show data stores because they are considered to be within the system scope

12. DFD Fragments • Created for each event in the event table • Represents system response to one event within a single process symbol • Self contained model • Focuses attention on single part of system • Shows only data stores required to respond to events

13. DFD Fragments for Course Registration System

14. Event-Partitioned System Model • DFD to model system requirements using single process for each event in system or subsystem • Decomposition of the context level diagram • Sometimes called diagram 0 • Used primarily as a presentation tool • Decomposed into more detailed DFD fragments

15. Combining DFD Fragments

16. Context Diagram for RMO Customer Support System

17. RMO Subsystems and Events

18. Context Diagram for RMO Order-Entry Subsystem

19. DFD Fragments for RMO Order-Entry System

20. Decomposing DFD Fragments • Sometimes DFD fragments need to be explored in more detail • Broken into subprocesses with additional detail • DFD numbering scheme: • Does not equate to subprocess execution sequence • It is just a way for analyst to divide up work

21. Order-Entry Subsystem

22. Physical and Logical DFDs • Logical model • Does not tell how system is implemented • Physical model • Describes assumptions about implementation technology • Developed in last stages of analysis or in early design

23. Detailed Diagram for Create New Order

24. Physical DFD for scheduling courses

25. List of Activities

26. Stock Log

27. Current Logical System and New Logical System Current Logical System New Logical System

28. Evaluating DFD Quality • Readable • Internally consistent • Accurately represents system requirements • Reduces information overload: Rule of 7 +/- 2 • Single DFD should have not more than 7 +/-2 processes • No more than 7 +/- 2 data flows should enter or leave a process or data store on a single DFD • Minimizes required number of interfaces

29. 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

30. Consistency Rules • All data that flows into a process must: • Flow out of the process or • Be used to generate data that flow 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

31. Unnecessary Data Input: Black Hole

32. Process with Impossible Data Output: Miracle

33. Process with Unnecessary Data Input

34. Process with Impossible Data Output

35. Incorrect and Correct Ways to Draw DFD

36. Incorrect and Correct Ways to Draw DFD

37. Incorrect and Correct Ways to Draw DFD

38. 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

39. Unbalanced Set Of Data Flow Diagrams

40. Balancing DFDs • We can split a data flow into separate data flows on a lower level diagram

41. 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

42. Data Flow Definitions • Textual description of data flow’s content and internal structure • Often coincide with attributes of data entities included in ERD

43. Data Flow Definition- Example New-Order = Customer-Name + Customer-Address + Credit-Card-Information + {Item-Number + Quantity) N 1

44. Data Store Definitions • A data store on the DFD represents a data entity on the ERD

45. Data Element Definitions • Data type description • e.g. string, integer, floating point, Boolean • Sometimes very specific • Length of element • Maximum and minimum values • Data dictionary – repository for definitions of data flows, data stores, and data elements

46. DATA STRUCTURE ORDER= ORDER NUMBER + ORDER DATE+ [ PERSONAL CUSTOMER NUMBER, CORPORATE ACCOUNT NUMBER]+ SHIPPING ADDRESS=ADDRESS+ (BILLING ADDRESS=ADDRESS)+ 1 {PRODUCT NUMBER+ PRODUCT DESCRIPTION+ QUANTITY ORDERED+ PRODUCT PRICE+ PRODUCT PRICE SOURCE+ EXTENDED PRICE } N+ SUM OF EXTENDED PRICES+ PREPAID AMOUNT+ (CREDIT CARD NUMBER+EXPIRATION DATE) (QUOTE NUMBER) ADDRESS= (POST OFFICE BOX NUMBER)+ STREET ADDRESS+ CITY+ [STATE, MUNICIPALITY]+ (COUNTRY)+ POSTAL CODE ENGLISH ENTERPRETATION An instance of ORDER consists of: ORDER NUMBER and ORDER DATE and Either PERSONAL CUSTOMER NUMBER or CORPORATE ACCOUNT NUMBER and SHIPPING ADDRESS (which is equivalent to ADDRESS) and optionally: BILLING ADDRESS (which is equivalent to ADDRESS) and one or more instances of: PRODUCT NUMBER and PRODUCT DESCRIPTION and QUANTITY ORDERED and PRODUCT PRICE and PRODUCT PRICE SOURCE and EXTENDED PRICE and SUM OF EXTENDED PRICES and PREPAID AMOUNT and optionally: both CREDIT CARD NUMBER and EXPIRATION DATE An instance of ADDRESS consists of: optionally: POST OFFICE BOX NUMBER and STREET ADDRESS and CITY and Either STATE or MUNICIPALITY and optionally: COUNTRY and POSTAL CODE A Data Structure for a Data Flow

47. Data Flow Diagram and Process Specifications

48. Goal of Creating Process Specifications • Reduce process ambiguity. • Obtain a precise description of what is accomplished. • Validate the system design, including data flow diagrams and the data dictionary.

49. Process Specification Format • Process specifications link the process to the DFD and the data dictionary. • The following information should be entered: • The process number, which must match the process ID on the data flow diagram. • This allows an analyst to work or review any process and easily locate the data flow diagram containing the process. • The process name, the same as displays within the process symbol on the DFD. • A brief description of what the process accomplishes. • A list of input and output data flow, using the names found on the data flow diagram. • Data names used in the formulae or logic should match the data dictionary, for consistency and good communication. • A description of the process logic.

50. Process Specification Form