REQUIREMENTS FROM DIAGRAMS
Functional requirements can be depicted by various types of diagrams. Each element of the diagram should be associated with the requirement it depicts. If there is a gap, either the requirements or the diagram needs correction.
Text requirements can be extracted from diagrams. The diagram structure can also be used to organize text requirements. Be sure to create traceability from diagrams to text requirements. The example below illustrates the process.
Extracting Requirements from DFDs
Data flow diagrams depict the flow of data and its transformation. Through decomposition, greater detail is revealed and documented in layers of DFDs. A numbering system is used to hierarchically relate the process layers. Data stores are also numbered so they can be traced to data models. There are four diagram components: processes, data stores, external entities, and data flows.
Processes have at least one input and one output. The process is usually symbolized by a "bubble" or similar figure. The process is what transforms the data. Functional primitives are at the lowest level of the DFDs and can be decomposed no further. You know you have gone past the functional primitive when the result sounds like program logic (if, then; case, case).
Data stores are used to represent data structures or logical data files. They are often represented as open-ended shapes.
External entities represent interfaces external to the system. These are often represented as a small shape, such as a diamond. Data flows represent the exchange of data between processes, processes and data stores, and processes and external entities. The direction of the data flow defines how data flows through the system. Data flow direction is represented by arrows.
To extract requirements from the data flow diagrams, create a template. This will make the work go quickly and ensure consistency. Insert the exact names from the diagram into the template. Users will be interested mainly in the processes and external inputs and outputs. Non-functional requirements can't be extracted from DFDs. Sample template:
Inputs from external entity: The system shall receive (DFD data name) from (DFD entity name).
Outputs to external entity: The system shall produce (DFD output name) to (DFD entity name).
Processes: The system shall (DFD process name).
Internal inputs and outputs can also be specified:
Outputs to internal entity: The system shall produce (DFD data name) to (DFD entity name).
Data from store: The system shall retrieve (DFD data name) from (DFD store name).
Data to stores: The system shall store (DFD data name) in (DFD store name).
Review and edit the requirements if they are unclear. DFDs were not worded to be extracted into text. Use the DFD hierarchy to organize the requirements: higher-level processes are the parents of the primitives. Establish traceability using the DFD numbering scheme:
A simplified DFD and some requirements extracted using the template.
In the examples, all the requirements belong under the parent 220.127.116.11: The system shall process payment returns and adjustments (in a separate DFD, not shown). The parent is compound and should be reworded. However, if you have limited resources, focus on the functional primitives because they are critical to the subsequent development phases. In backward traceability, if all the children are satisfied, the compound parent will be satisfied--if all of the parent is planned for implementation at the same time during the project. If it is not, you will have traceability problems.