Process specification: Difference between revisions

Revision as of 07:01, 15 March 2010

Latest revision as of 05:28, 12 August 2025

(18 intermediate revisions by 16 users not shown)

Line 1:

{{OrphanNo footnotes|date=NovemberMay 20062022}}

'''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]] 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. butProcess itsspecifications onlyare acommonly jokeincluded :)as integral components of requirements documents 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. but its only a joke :).

==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/20151208030959/http://www.yourdon.com/strucanalysis/wiki/index.php?title=Introduction Structured Analysis Wiki], by [[Ed Yourdon]]

[[Category:ProcessBusiness process management]]

[[Category:Software development process]]