Analysis paralysis is a term we often use when we analyze things to death without really making progress in our implementation. It can be the same when you're decomposing your data flow diagrams. How do you effectively know when to stop decomposing? In this video, we'll talk a little bit about what happens at the end of the DFD decomposition process, where you've essentially decompose the processes as far as they can go. After this video, you'll be able to describe why we decompose DFDs, as well as evaluate whether DFD is decomposed to the proper level. Finally, we'll talk about the concept of primitives and you'll be able to read and interpret primitives that are written in structured English or shown as a decision table. But first, in an earlier video, we talked about how we take our context diagram and decompose that into a level zero DFD. We also saw an example of taking a level zero DFD and making it a level one DFD. You can imagine that this process can continue almost indefinitely decomposing your processes further and further. So, how do you know when to stop? Well, one guideline is that the ideal level of decomposition is to decompose until you can provide a detailed description of the process in no more than one page. This usually means writing logic and something called Structured English or Decision Tree or Decision Table. Let's take a look at some of these and what they look like so that you get an idea of what the goal is. For example, let's take this process, generate orders. We might decide that this generate orders process is decomposed further enough if we can describe it with one page of structured English, and here's what Structured English might look like. We could use simple if then language. So, if an inventory level is less than the minimum order quantity, then we create a new order, otherwise, we do nothing. That's an accurate description of the process. Then, we don't need to decompose any further. Instead, our primitives are typically attached through the end of our data flow diagram so that you can get descriptions of all these processes. Structured English is not necessarily intended to be a computer language, but you can see with logic like this, it's closely approximating one. The idea here is to bridge the gap between the diagram and the system implementers who are going to implement the system or test the system if we're purchasing an external system. Here's another look at what a primitive for this might look like. Instead of if-else logic, we use a case-based logic. So, in case number one, our inventory level is greater than our minimum order quantity, we don't have anything to do. However, if the inventory is less than the minimum order quantity, but it's not zero, we'll create a new order and the delivery time can be tomorrow. On the other hand, if we're down at zero we might want to create a new order with the delivery time for later today. This gives you a few examples of how you might implement a simple primitive, this is Structured English. Another approach to doing this kind of thing is with something called a Decision Table. A Decision Table effectively maps inputs and outputs as best we can using a table structure like this. So, on the left we have Conditions, Courses of Action, so based on the type of the item, the time of the week, or the season of the year, and these could all be inputs into the process. We then follow a certain rule. So, in perishable, non-perishable weekday, weekend, and so on based on the set of rules that you will see here. These again allow a business analyst who might not be familiar with writing computer code to describe the process in a way that closely approaches or approximates the logic that a computer might use. But yet, it's still able to be read by a business analyst so that we can verify whether or not the logic is correct. Here's just an example of how you would fill out that particular decision table with additional information. So, reviewing here, a primitive is essentially the lowest level of decomposition of a process within our dataflow diagram. It should be something that we can describe in less than one page, and the logic should be able to be communicated in Structured English or in a Decision Table. When you're done doing your DFD analysis, what you'll have is essentially a set of DFDs, beginning with the context diagram, and proceeding down through however many levels is appropriate, given the size of the system. Then from there, you'll have a set of primitives, which are generally a document consisting of Structured English instructions or Decision Table instructions. These are then passed on to the system implementers who will either implement the system, by perhaps doing some custom programming, or will be purchasing the system and then verifying that the purchase system adheres to the requirements you've laid out.
