Content deleted Content added
m unpiped links using script |
m Disambiguating links to Object-orientation (link changed to Object-oriented programming) using DisamAssist. |
||
| (One intermediate revision by one other user 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 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 [[UML]] is interface driven with multiple abstraction mechanisms useful in describing [[service-orientation|service-oriented]] architectures (SOAs).<ref name="DoDAF V2"/>
=== Approach ===
| |||