Process specification
Process Specification is generic term whose definition is self-evident and whose context is not unique to "business activity" but that can be applied to any organizational activity.
applies to any used to refer to the collectio of requirements requiorements description of the procedure to be followed by an actor within an elementary level business activity, as represented on a process model such as a dataflow diagram or IDEF0 model. A common alias is minispec short for miniature specification. Process Specifications are commonly included as an integral component of a requirements document in systems development. The process specification defines what must be done in order to transform inputs into outputs. It is a detailed set of instructions outlining a business procedure that each elementary level business activity is expected to carry out.
There are a variety of approaches that can be used to produce a process specification: decision tables, structured English (favored technique of most systems analysts), pre/post conditions, flowcharts, Nassi-Shneiderman diagrams, use case flow descriptions, and others. No matter what approach is used, it must communicate to system development designers, implementers and support professionals, as well as be verifiable by the stakeholders/end users.
A Process Specification is a description of the procedure to be followed by an actor within an elementary level business activity, as represented on a process model such as a dataflow diagram or IDEF0 model. A common alias is minispec short for miniature specification. Process Specifications are commonly included as an integral component of a requirements document in systems development. The process specification defines what must be done in order to transform inputs into outputs. It is a detailed set of instructions outlining a business procedure that each elementary level business activity is expected to carry out.
There are a variety of approaches that can be used to produce a process specification: decision tables, structured English (favored technique of most systems analysts), pre/post conditions, flowcharts, Nassi-Shneiderman diagrams, basic course or events/alternate paths in use cases, UML Activity Diagrams and others. No matter what approach is used, it must communicate to system development designers, implementers and support professionals, as well as be verifiable by the stakeholders/end users.
External links
- Chapter 11 of the Structured Analysis Wiki, by Ed Yourdon
This article has not been added to any content categories. Please help out by adding categories to it so that it can be listed with similar articles. (July 2007) |