Structured Analysis

1. Structured Analysis Infsy 570 Dr. R. Ocker

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

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

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

5. Systems Analysis

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

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

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

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

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

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

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

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

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

15. Requirements • 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 • analyst derives new system requirements from an analysis and synthesis of a,b,& c

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

17. Major steps in determining requirements for new system

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

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

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

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

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

23. 3. Requirements specification • 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 • sampling and investigating hard data, interviewing, questionnaires, observation, and prototyping

25. CASE tools • DFD - data flow diagram - used to chart the input, processes, and output of the business's functions in a structured graphical form • 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 • 1. Increase productivity - draw and modify diagrams easily • 2. Improve analyst-user communication - same - draw and modify diagrams easily • CASE tools integrate activities within the SDLC

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

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

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

30. Structured Development • 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. • this process can continue to the primitive level, where programming begins directly from the exploded diagram

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

32. Structured terms • process specifications - definitions of how processes work • 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 • graphic tool to represent all the tasks or processes in a system • groups them into hierarchical levels • one-to-many relationship between upper and lower levels of the chart • node has single parent and >=0 children nodes • all sibling nodes have same level of detail

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

36. II. Data Flow Diagrams • DFDs - graphic representation of the flow of data through a system; • 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 • 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) • contains combinations of only four symbols

40. 1. External entities • also called sources or sinks • people or groups of people who interact with the current system but are not internal to the system; • outside of boundary of our system • square is symbol for an external entity • 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 • processes=functions • actions performed on data flowing through the system • rounded rectangle - symbol for process • each process is identified by a number corresponding to the level of the process on the hierarchy chart. • each process is named with a simple verb-object pair, i.e. enter transaction

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

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

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

45. 5. Exploding DFDs into levels • diagrams move from general to specific • 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 • contains all the options on the main menu • a leveled set of DFDs has a 1-to-1 correspondence with the levels on the hierarchy chart

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

49. Creating child diagrams • each process on diagram 0 can be exploded to create a more detailed child diagram • parent - process on diagram 0 that is exploded • child - resulting diagram • 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 • all data flow in or out of the parent process must be shown flowing in or out of the child diagram • child diagram given the same number as its parent process in Diagram 0 (e.g., process 3 would explode to diagram 3) • processes on the child diagram are numbered using the parent process number, a decimal point, and a unique number for each child process