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:
Therefore, you need to prepare some sort of process specification for any lowest-level process that isn't absolutely obvious.
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.
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:
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:
||Customer has purchased at least $5000 in 4 out of the last 5 years|
||Excellent / Good / HighRisk / Unsatisfactory|
||For RegularCustomer: $25000|
For others, depending on CreditRating:
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