The next step is to label each data pathway with a name and a general description of the data moving along the pathway. If the diagram is sufficiently large, this information can be noted along the length of the data pathway arrow.
If, on the other hand, the diagram is too convoluted or cramped, it is also acceptable to legend the arrow with a number and then build a list with the information. Particularly for larger systems, this method is typically easier to manage, and it also lends itself to electronic documentation better than trying to place the text along the arrow in the diagram.
Once all the data pathways between tasks are documented, it is time to add the information related to significant data storage. This information was gathered at the end of the communications section of the requirements document dissection.
To show the storage required by the individual tasks, draw an arrow from the task associated with the storage, wrap it around 180 degrees, and place the head on the same task. Then label the loop with a name indicating the nature of the storage. Use the same form of notation used in the last section when describing task-to-task pathways.
In the event that the information is also passed to another task, start the tail of the arrow at the same point on the circle as the arrow leading to the other task, and then loop the arrow around just like the other storage arrows. Label both the loop and the arrow with the same name to show that the information is local storage and a data pathway. Figure 3-4b below demonstrates an example of a storage loop.
Figure 3.13(b): Storage Loop.
When the diagram is complete, the designer should go back through the information from the requirements document dissection to verify that all task inputs and outputs have connections to other tasks. The designer should also review the function and task lists to verify that new connections have also been made.
Often in the process of task definition, new communications pathways may be created, but through an oversight, the information was not back-annotated to the requirements document. Checking the function and task lists should catch these missed pathways. (Note: The designer is strongly discouraged from skipping over this step as it is a valuable check on the design of the tasks as well as the communications layout of the system.)
Unconnected pathways can indicate any one of a number of system design problems:
• The inadvertent generation of redundant data.
• Missing data that must be generated.
• An omission in the task list documentation.
• Or, even a failure in the designer’s understanding of the operation of the system.
In any event, the problem should be identified and corrected before continuing on with the design and the affected documentation should also be revised to include the corrections. And yes, the function and task lists, as well as the requirements document should be updated.
Once all questions have been resolved and the documentation updated, the diagram should be redrawn one last time in a single color of ink with related peripherals and tasks grouped together so that the pathway arrows are reasonably straight and easy to follow.
The diagram should also leave plenty of room for the addition of new pathways. And there will be additional data pathways generated as the design evolves. No design methodology, regardless of how methodical, can accurately predict every possible need in advance. A good methodology though, should be sufficiently adaptable to handle new requirements as the project progresses.
Next, make a list of all the data pathways, prioritizing the list by name of the pathway and the name of the sending task. For pathways with multiple destinations or sources, make a single entry in the list, but list all sources and destinations for the pathway.
For each pathway, note the type of data to be transferred, whether the storage is static or dynamic, plus the estimated width and storage requirements. This information should have come from the dissection of the requirements document earlier in this series.
The designers should take their time in the generation of this list, making it as comprehensive as possible, as the list will be the basis for the final variable dictionary and the header file that will declare the variables used for communications. For dynamic variables, make a note of any estimates made concerning input and output data rates as well.