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 the 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:

• Structured English (or other natural language) serves to exploit the expressive power of everyday language while avoiding its ambiguities.
• Decision tables are particularly useful in handling multiple conditions where (a) the sequence of testing is not significant and (b) you want to make sure that no combination, however unlikely, is overlooked.
• Use case specifications are appropriate where it's important to show the interaction between a user and the computerized system. (But don't fall into the trap of premature implementation specification discussed in the next section below.) Such processes are typically associated with transactions.
• Flow diagrams are considered somewhat old-fashioned, but can still communicate clearly to the intended audiences.

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:

• "The system prompts the user to enter a destination."
• "The user clicks on the Submit button."
• "The system opens a new window . . . "

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
RegularCustomer	Logical	Customer has purchased at least $5000 in 4 out of the last 5 years
CreditRating	Discrete	Excellent / Good / HighRisk / Unsatisfactory
CreditLimit	Money	For RegularCustomer: $25000 For others, depending on CreditRating: Excellent: $25000 Good: $10000 HighRisk: $10000 Unsatisfactory $0

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 2 January 2004