Process specification: Difference between revisions

Revision as of 15:56, 1 April 2018

Latest revision as of 05:28, 12 August 2025

(7 intermediate revisions by 7 users not shown)

Line 1:

{{No footnotes|date=May 2022}}

'''Process specificationSpecification''' is a genericbusiness term for the specification of a process. Its contextIt is not unique to "business activity", but can be applied to any organizational activity.

Within some structured methods, the capitalized term '''Process Specification''' refers to a description of the [[Procedure (term)|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 specification''' is a generic term for the specification of a process. Its context is not unique to "business activity" but can be applied to any organizational activity.

Within some structured methods, the capitalized term '''Process Specification''' refers to a description of the [[Procedure (term)|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.

==Use 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. Process specifications are commonly included as an integral componentcomponents of a requirements documentdocuments 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. Process specifications are commonly included as an integral component of a requirements document in systems development.

==Techniques==

There are aA variety of approaches that can be used to produce a process specification, including:

*[[decisionDecision tables]]

*structuredStructured English (favored technique of most systems analysts)

*prePre/post conditions

*[[useUse cases]], basic course or events/alternate paths in [[use cases]]

*[[Flowcharts]]

*[[Nassi–Shneiderman diagram|Nassi–Shneiderman diagrams]]

*[[Unified Modeling Language|UML]] [[Activity diagram|Activity diagrams]]

No matter what approach is used, ita specification must communicate to system development designers, implementers and support professionals, as well asand be verifiable by the stakeholders/ and end users.

There are a variety of approaches that can be used to produce a process specification including

*[[decision tables]]

*structured English (favored technique of most systems analysts)

*pre/post conditions

*[[use cases]], basic course or events/alternate paths in [[use cases]]

*[[flowcharts]].

*[[Nassi–Shneiderman diagram]]

*[[Unified Modeling Language|UML]] [[Activity diagram]]

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.

== See also ==

Line 25 ⟶ 23:

== External links ==

*[https://web.archive.org/web/20151205091250/http://www.yourdon.com/strucanalysis/wiki/index.php?title=/Chapter_11 Chapter 11] of the [https://web.archive.org/web/2007020321394420151208030959/http://www.yourdon.com/strucanalysis/wiki/index.php?title=Introduction Structured Analysis Wiki], by [[Ed Yourdon]]

[[Category:Business process management]]