Business rules, decision logic, and algorithms . . .

Specifying a Process
©Information Disciplines, Inc., Chicago
Conrad Weisert, 1 January 2004

Background -- When do we need to specify a process?

If you prepare a complete set of multi-level dataflow diagrams, as we recommend, then they will show every process in the system and its relationship to other system components. On the other hand if you prefer a different form of big-picture documentation, then that documentation should at least identify every process and show where it fits in the system. In either case, the processes will have to be rigorously specified.

In discussing dataflow diagrams we agreed that every process symbol must satisfy one of the following criteria:

  1. The description label is so simple and unambiguous that every reader will understand it in full detail and in exactly the same way.

  2. The process is expanded or decomposed into a separate lower-level dataflow diagram that preserves exactly the same net inputs and outputs, but shows internal detail, such as data stores and internal processes.

  3. The process is rigorously described by a separate process specification (business rule, decision rule, function definition, algorithm, etc.).

Therefore, you need to prepare some sort of process specification for any lowest-level process that isn't absolutely obvious.

Alternative forms

There is no one form of process specification that suits all situations. For processes that consist of multiple steps with decision points the most common useful techniques include these four:

Any of the above can be embedded in an I-P-O diagram (input-process-output), useful for showing relationships between individual process steps and specific process inputs or outputs.

Early structured analysis textbooks also suggested decision trees, an abbreviated form of flow diagram, but they often (a) unnecessarily constrain the sequence of condition testing and (b) exceed the bounds of a printed page.

You'll find explanations and guidance on all of the above in a good textbook on systems analysis.

Don't describe implementation or dialogues

A common mistake among inexperienced systems analysts is to describe implementation details, i.e. how a process is implemented rather than what it does. Such details are best left to the internal design (or system architecture) phase of the project, and won't be needed at all if the project should elect to purchase packaged application software.

Here are examples of such steps that should never appear in requirements documentation or external system specification:

Prefer data definition to process definition

Sometimes you can avoid detail in a process specification, or even avoid writing one altogether, thereby simplifying the requirements documentation. You may instead be able to define a data item that captures a formula, a simple decision rule, or even just a constant. For example:
Data item Type Meaning
RegularCustomerLogical Customer has purchased at least $5000 in 4 out of the last 5 years
CreditRatingDiscrete Excellent / Good / HighRisk / Unsatisfactory
CreditLimitMoney For RegularCustomer: $25000
For others, depending on CreditRating:
Good: $10000
HighRisk: $10000

Then whenever any part of the requirements specification refers to the customer's CreditLimit, there's no need to repeat the logic that determines its value.

Return to Requirements Guidelines
IDI home page

Last modified 21 September 2010