Structured analysis: Difference between revisions

Revision as of 19:59, 9 January 2022

Latest revision as of 09:54, 29 July 2025

(4 intermediate revisions by 4 users not shown)

Line 1:

{{Short description|Software engineering method}}

[[Image:Context diagram and Technical Criteria Derivation.jpg|thumb|320px|Example of a structured analysis approach.<ref>Tricia Gilbert (2006) [http://acast.grc.nasa.gov/wp-content/uploads/icns/2006/06_Session_B1/03-Gilbert.pdf FCS Evaluation criterea for technology assessment] {{Webarchive|url=https://web.archive.org/web/20080918012417/http://acast.grc.nasa.gov/wp-content/uploads/icns/2006/06_Session_B1/03-Gilbert.pdf |date=2008-09-18 }}</ref>]]

In [[software engineering]], '''structured analysis''' (SA) and '''structured design''' (SD) are methods for analyzing business [[requirements]] and developing [[specification]]s for converting practices into [[computer program]]s, hardware configurations, and related manual procedures.

Line 25 ⟶ 26:

* [[Jackson structured programming]] in circa 1975 developed by [[Michael A. Jackson (computer scientist)|Michael A. Jackson]]

* Structured analysis in circa 1978 with [[Tom DeMarco]], [[Edward Yourdon]], Gane & Sarson, McMenamin & Palmer.

* [[Structured Analysis and Design Technique|Structured analysis and design technique]] (SADT) developed by [[Douglas T. Ross]]

* [[Edward Yourdon#Yourdon Structured Method|Yourdon structured method]] developed by [[Edward Yourdon]].

* Structured analysis and system specification published in 1978 by [[Tom DeMarco]].

Line 35 ⟶ 36:

*[[Information technology engineering]] in circa 1990 with Finkelstein and popularised by [[James Martin (author)|James Martin]].

According to Hay (1999) "[[Information engineering (field)|information engineering]] was a logical extension of the structured techniques that were developed during the 1970s. Structured programming led to structured design, which in turn led to structured systems analysis. These techniques were characterized by their use of [[diagram]]s: structure charts for structured design, and data flow diagrams for structured analysis, both to aid in communication between users and developers, and to improve the analyst's and the designer's discipline. During the 1980s, tools began to appear which both automated the drawing of the diagrams, and kept track of the things drawn in a [[data dictionary]]".<ref>David C. Hay (1999) [http://www.ihs.gov/Misc/links_gateway/download.cfm?doc_id=138&app_dir_id=4&doc_file=ieoo.pdf Achieving buzzword compliance in Object orientation] {{Webarchive|url=https://web.archive.org/web/20081020060208/http://www.ihs.gov/misc/links_gateway/download.cfm?doc_id=138&app_dir_id=4&doc_file=ieoo.pdf |date=2008-10-20 }} Essential Strategies, Inc.</ref> After the example of [[computer-aided design]] and [[computer-aided manufacturing]] (CAD/CAM), the use of these tools was named [[computer-aided software engineering]] (CASE).

== Structured analysis topics ==

Line 43 ⟶ 44:

Structured analysis typically creates a hierarchy employing a single abstraction mechanism. The structured analysis method can employ [[IDEF]] (see figure), is process driven, and starts with a purpose and a viewpoint. This method identifies the overall function and iteratively divides functions into smaller functions, preserving inputs, outputs, controls, and mechanisms necessary to optimize processes. Also known as a [[functional decomposition]] approach, it focuses on cohesion within functions and coupling between functions leading to structured data.<ref name="DoDAF V2"/>

The functional decomposition of the structured method describes the process without delineating system behavior and dictates system structure in the form of required functions. The method identifies inputs and outputs as related to the activities. One reason for the popularity of structured analysis is its intuitive ability to communicate high-level processes and concepts, whether in single system or enterprise levels. Discovering how objects might support functions for commercially prevalent [[Object-oriented programming|object-oriented]] development is unclear. In contrast to IDEF, the [[Unified Modeling Language|UML]] is interface driven with multiple abstraction mechanisms useful in describing [[service-orientation|service-oriented]] architectures (SOAs).<ref name="DoDAF V2"/>

=== Approach ===

Line 51 ⟶ 52:

De Marco's approach<ref>[[Tom DeMarco]] (1978). ''Structured Analysis and System Specification''. Yourdon Press, New York, 1978.</ref> consists of the following objects (see figure):<ref name="HeSi86"/>

* [[Context diagram]]

* [[Dataflow diagram|Data flow diagram]]

* Process specifications

* [[Data dictionary]]

Line 58 ⟶ 59:

=== Context diagram ===

{{Main|Context diagram}}

[[Image:NDE Context Diagram (vector).svg|thumb|320px|Example of a system context diagram.<ref>[http://projects.osd.noaa.gov/NDE/proj_context_diagram.htm NDE Project Management] {{Webarchive|url=https://web.archive.org/web/20081107193850/http://projects.osd.noaa.gov/NDE/proj_context_diagram.htm |date=2008-11-07 }} (NPOESS) Data Exploitation web site. 2008.</ref>]]

[[System Context Diagram|Context diagrams]] are diagrams that represent the actors outside a system that could interact with that system.<ref name="KoSw03"/> This diagram is the highest level view of a [[system]], similar to [[block diagram]], showing a, possibly [[software system|software]]-based, system as a whole and its inputs and outputs from/to external factors.

Line 64 ⟶ 66:

=== Data dictionary ===

{{Main|Data dictionary}}

[[Image:Entity Relationship Diagram.jpg|thumb|320px|left| [[Entity relationship diagram]], essential for the design of database tables, extracts, and metadata.<ref name="USDT01"/>]]

A [[data dictionary]] or ''database dictionary'' is a file that defines the basic organization of a [[database]].<ref name="USDT01">[http://knowledge.fhwa.dot.gov/tam/aashto.nsf/All+Documents/4825476B2B5C687285256B1F00544258/$FILE/DIGloss.pdf Data Integration Glossary] {{Webarchive|url=https://web.archive.org/web/20120218233448/http://knowledge.fhwa.dot.gov/tam/aashto.nsf/All%20Documents/4825476B2B5C687285256B1F00544258/%24FILE/DIGloss.pdf |date=2012-02-18 }}, U.S. Department of Transportation, August 2001.</ref> A database dictionary contains a list of all files in the database, the number of records in each file, and the names and types of each data field. Most [[database management system]]s keep the data dictionary hidden from users to prevent them from accidentally destroying its contents. Data dictionaries do not contain any actual data from the database, only bookkeeping information for managing it. Without a data dictionary, however, a database management system cannot access data from the database.<ref name="USDT01"/>

Line 70 ⟶ 73:

=== Data flow diagrams ===

{{Main|Data flow diagram}}

[[Image:Data Flow Diagram Example.jpg|thumb|330px|Data flow diagram example.<ref>John Azzolini (2000). [http://ses.gsfc.nasa.gov/ses_data_2000/000712_Azzolini.ppt Introduction to Systems Engineering Practices]. July 2000.</ref>]]

A [[data flow diagram]] (DFD) is a graphical representation of the "flow" of data through an [[information system]]. It differs from the system [[flowchart]] as it shows the flow of data through processes instead of [[computer hardware]]. Data flow diagrams were invented by [[Larry Constantine]], developer of [[structured design]], based on Martin and Estrin's "data flow graph" model of computation.<ref>W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.</ref>

Line 78 ⟶ 82:

=== Structure chart ===

{{Main|Structure chart}}

[[Image:Configuration System Structure Chart.jpg|thumb|320px|A configuration system structure chart.<ref name="IRT"/>]]

A [[structure chart]] (SC) is a chart that shows the breakdown of the [[configuration system]] to the lowest manageable levels.<ref name="IRT">[https://www.irs.gov/irm/part2/ch17s01.html "Configuration Management"] In: ''IRS Resources Part 2. Information Technology Chapter 27. Configuration Management''. Accessed 14 Nov 2008.</ref> This chart is used in [[structured programming]] to arrange the program modules in a tree structure. Each module is represented by a box which contains the name of the modules. The tree structure visualizes the relationships between the modules.<ref>[[James Martin (author)|James Martin]], Carma L. McClure (1988). ''Structured Techniques: The Basis for Case''. Prentice Hall. p.56.</ref>

Line 131 ⟶ 136:

{{Software engineering}}

{{Edsger Dijkstra}}

{{DEFAULTSORT:Structured Analysis}}

[[Category:Software design]]

[[Category:Edsger W. Dijkstra]]