1. Structured Analysis Infsy 570 Dr. R. Ocker

2. What is structured analysis? n It focuses on specifying what the system or application is required to do. n Elements of structured analysis n. Graphical description n. Data Flow Diagrams n. Data Dictionary: definitions of elements in the system

3. What is structured Design? n Focus on the development of n software specifications

4. Three primary modules in SDLC (1) Analysis (2) Design (3) Implementation n various phases within each module

5. Systems Analysis

6. A. Objectives of System Analysis n determine if current system is in trouble n determine appropriate alternatives n make recommendation

7. To establish in detail what the system is to do n objectives n costs n benefits n implementation process n organizational changes required n defines who the USERS are n Their input and output

8. Phase 1 Identify problems, opportunities, and objectives n analyst looks at what is occurring in the business n look for problems and opportunities n People involved: n users, analysts, systems managers

9. Phase 1 n Activities include: n interviewing user management n summarizing knowledge obtained n estimating scope of project n documenting results n Output of this phase: n feasibility study (report) containing a problem definition and summarizing the objectives

10. Feasibility Study: The Basic Tasks n Problem Orientation n. Define the problem n. Establish system objectives n. Identify the users n. Establish functional scope

11. Feasibility Study n Alternative Specification – Propose options – Cost-Benefit analysis – Assess project risk – Recommend

12. Feasibility Study n Technical n Do we have the capability to develop the system? n Does the necessary technology exist? n Does the proposed system have the right: –response time, interface, n Can the system be expanded?

13. Feasibility Study n Economic n Is there an economic payoff? n cost of hardware/software/ other n benefits in terms of reduced costs n opportunity costs

14. Phase 2Determining Requirements Phase 3Analyzing System Needs n goal - determine the requirements of the new system -- must obtain a consensus from the user community on the ideal information system

15. Requirements n Analyst must understand: a. the CURRENT SYSTEM b. what information users need to perform their jobs c. why and how current system is no longer effective n analyst derives new system requirements from an analysis and synthesis of a,b,& c

16. Requirements n People involved in this phase: n analysts, users - operations managers and workers

17. Major steps in determining requirements for new system

18. 1.Requirements capture and analysis n The process of deriving system requirements n accomplished through observation of existing systems, discussions with potential users and task analysis. n very time consuming step

19. Analyst needs to know details of current system functions n who - the people who are involved n what - the business activity n where - the environment in which the work occurs n when - the timing of the activity n how - how the current procedures are performed

20. 2.Requirements definition n document containing an abstract description of: n - user functions the new system is expected to provide n - constraints under which the system must operate. n only specifies the external behavior of the system - does not cover any implementation considerations.

21. 2.Requirements definition n written without using any specialized notations so that it is understandable by non-systems professionals (e.g., potential users, system procurers). n becomes the focus for much of the work involved in developing system requirements.

22. 3.Requirements specification n document that details the functions that the system is to include - sometimes called a functional specification n written using a formal systems specification language n more precise than the requirements definition - for use by the technical staff

23. 3.Requirements specification n creation of this document might be carried out in parallel with some high- level design (this may be essential) as the design and requirements activities influence each other as they develop.

24. Tools used to determine requirements n sampling and investigating hard data, interviewing, questionnaires, observation, and prototyping

25. CASE tools n DFD - data flow diagram - used to chart the input, processes, and output of the business's functions in a structured graphical form n data dictionary - developed from the DFDs; lists all of the data items used in the system along with their specifications

26. Analysts use CASE tools to n 1.Increase productivity - draw and modify diagrams easily n 2.Improve analyst-user communication - same - draw and modify diagrams easily n CASE tools integrate activities within the SDLC

27. types of CASE n 1.Upper CASE - used by analysts to create and modify system design n 2.Lower CASE - used to generate computer source code

28. Using Data Flow Diagrams n structured approach - take a top-down approach to system development n system is defined first at a general level - overview n successive refinement occurs until the bottom (primitive) levels are defined. n primitive level - point where specifications can be translated into lines of code n So...system is decomposed into small modules that perform simple tasks

29. Structured Development n the systematic and integrated use of tools and techniques to aid the analysis and design of information systems n structured methodologies use one or more tools to define information flow and processes.

30. Structured Development n definition is from top to bottom in increasing levels of detail. 1.major flows and processes identified 2.these are exploded into subprocesses 3.subprocesses are exploded into more detail. n this process can continue to the primitive level, where programming begins directly from the exploded diagram

31. Structured terms n data elements - lowest level of information on which a process can act n i.e. DB attributes/record fields - e.g. unit price n data stores - places where data are stored; e.g. files; microfiche, filing cabinets n data flows - represent movement of data in a system; consist of data input and data output n e.g. forms, reports, invoices, letters n show movement of data about a physical “thing”

32. Structured terms n process specifications - definitions of how processes work n data dictionary - document containing definitions of all system data; includes data elements, data structures, data stores, data flows, and process specifications

33. Tools

34. I.Hierarchy Chart n graphic tool to represent all the tasks or processes in a system n groups them into hierarchical levels n one-to-many relationship between upper and lower levels of the chart n node has single parent and >=0 children nodes n all sibling nodes have same level of detail

35. I.Hierarchy Chart n functional primitives - bottommost nodes; get translated into programming code n control modules - any node above the functional primitives n topmost node - always single node, ties whole system together

36. II.Data Flow Diagrams n DFDs - graphic representation of the flow of data through a system; n can be physical DFDs or logical DFDs

37. Logical DFDs  shows sources and sinks (destinations) of data  identifies and names the logical functions (processes) of the system  identifies and names the groups of data elements that connect one process to another  identifies the data stores  each function broken down into more detailed DFD (levels)  descriptions of processes, flows, stores, elements recorded in data dictionary

38. Logical DFDs n All of the above documentation comprises a logical functional specification for an existing or new system.  a detailed statement of what the system does/is to do  free from physical considerations of how it will be implemented

39. DFD components (Gane & Sarson Methodology) n contains combinations of only four symbols

40. 1.External entities n also called sources or sinks n people or groups of people who interact with the current system but are not internal to the system; n outside of boundary of our system n square is symbol for an external entity n to identity an external entity - place a unique, lower-case alphabetic character in upper-left- hand corner of square. Then give entity a single, descriptive noun as a name.

41. 2.Processes n processes=functions n actions performed on data flowing through the system n rounded rectangle - symbol for process n each process is identified by a number corresponding to the level of the process on the hierarchy chart. n each process is named with a simple verb-object pair, i.e. enter transaction

42. 3.Data Stores n repository for data n can be as simple as an in/out box or as complex as a database n open-ended rectangle - symbol of a data store; open end on right side

43. 3.Data Stores n identified by upper-case alphabetic character and a digit: –each data store within the same system has the same alphabetic characters with different digits. n when a process stores data n data flow arrow goes into data store n when process accesses data n data flow arrow goes into process n avoid crossed data flow lines by repeating the data stores on the DFD as needed

44. 4.Data flows n represents the movement of data through the system n data often moves through the system as a form or a report n solid line with arrowhead - symbol for a data flow n each data flow must be identified with a descriptive name

45. 5.Exploding DFDs into levels n diagrams move from general to specific n similar to levels in a menu-driven system; top-level node is analogous to the main menu

46. Context-level  highest level in a DFD  lays out sources and sinks and a single process representing the entire system

47. Diagram 0.first-level explosion n contains all the options on the main menu n a leveled set of DFDs has a 1-to-1 correspondence with the levels on the hierarchy chart

48. Developing DFDs n Diagram 0 - explosion of context diagram n may include from 3 to 9 processes n ignore exception handling processes for the first 2-3 levels of a DFD n each process numbered with an integer n includes major data stores and all external entities

49. Creating child diagrams n each process on diagram 0 can be exploded to create a more detailed child diagram n parent - process on diagram 0 that is exploded n child - resulting diagram n vertical balancing - a child diagram cannot produce output or receive input that the parent process does not also produce or receive

50. Creating child diagrams n all data flow in or out of the parent process must be shown flowing in or out of the child diagram n child diagram given the same number as its parent process in Diagram 0 (e.g., process 3 would explode to diagram 3) n processes on the child diagram are numbered using the parent process number, a decimal point, and a unique number for each child process

51. Creating child diagrams n external entities - not shown on child diagrams below Diagram 0 n child diagram may include data stores not shown on the parent process n processes may or may not be exploded, depending on level of complexity n primitive process - when a process is shown at its lowest level of detail, cannot be exploded any further

52. Some general rules 1.a DFD level should contain from 3-9 processes 2.data flows should not split into two or more different flows 3.all data flows must EITHER originate or terminate at a process 4.processes need to have at least one input data flow and one output data flow

53. Some general rules 5. each child diagram should have the same input and output data flow as the parent process 6. avoid crossing data flow lines by repeating data stores and external entities 7. do not show exception handling processes until the lower levels of the DFD

54. Physical DFDs vs. Logical DFDs n physical DFDs - contain both what processes are in the system and how the processes operate; show movement of things n allow us to understand how the current system works n can be restrictive in the design process

55. logical DFDs n contains only the minimal data that flow through the system, independent of any devices, persons, forms, or specific physical implementations; n implementation-free