According to an old adage, “The proof is in the pudding.” Ergo, we will offer you some “Pudding” by walking you through a real life example of Problem Analysis using a DFD. To make it easier to follow, we will use our standard Data Flow Diagram of a typical Order Entry process. We are also including the text that we used to create the diagram.
Getting and Writing IT Requirements in a Lean/Agile World
Upon completion of this course, you can:
- Define the capabilities and challenges of Lean and Agile software development philosophies
- Adapt 10 different requirements gathering (elicitation) techniques to Lean, Agile, and Continuous Delivery software development environments
- Support Lean or Agile teams by expressing business needs and wants in formats that optimally support all modern Software Development Methodologies (SDM)
- Drill-down into requirements, features, user stories, and functions to identify and express test scenarios in Given-When-Then statements to facilitate automated testing
- Identify 17 types of Non-Functional Requirements (NFR) and develop Given-When-Then (GWT) test scenarios for them
Interview Notes
The customer triggers all the actions in our department. We receive an order (with or without payment), a complaint or a payment (with or without invoice copy) from the customer. These are separated and the following actions take place:
If it is an order, we verify an existing customer’s credit status and then we verify that the item numbers are valid by checking our inventory file. New customer’s orders are sent to the credit department and held until they clear a credit check. (If half payment or more is included, that order is treated as if it were a credit order with good credit.)
Valid orders are accumulated and grouped into shipping zones and transmitted to the warehouse to be filled. After an order is filled, the customer address is attached, the best or requested shipping method determined, postage or shipping costs calculated, the order is shipped, and the warehouse inventory is reduced. A copy of the packing slip goes to accounting where an invoice is created and sent to the customer, and the customer’s account updated. Copies of orders with payments and payments go to accounting, where the payments are applied to the customer’s account. The item inventory is officially updated in accounting.
Customer complaints go directly to customer service. They research the situation and respond to the customer as soon as possible. Any action taken by customer service, which affects accounting or inventory, is passed to them for updating. Possible actions are a new order, a debit, or a credit. These look exactly like the regular order process.
The Data Flow Diagram
As stated earlier, the exercise also requires a list of problem statements. On this project, the SMEs had identified the following problems:
- Customers with bad credit are getting their orders filled.
- New customer orders are taking too long to process.
- The warehouse gets so-called valid orders with incorrect item#/descriptions.
- Shipping is delayed
- Additional or new staff is not performing well enough.
- Pickers are away from the warehouse floor
- Customer invoices have incorrect prices.
- Orders are incorrectly filled.
OK, now that we have all of the pieces we need, let’s apply this technique.
Locating the Business Problems
The first problem states, “Customers with bad credit are getting their orders filled.” Where do you think this problem could be caused on the diagram? As you view the diagram, the first place that you see anything about customers with “bad” credit is the flow “Credit NOK Orders” from the VERIFY CREDIT process to the external CREDIT DEPARTMENT.
Based on that, the SMEs decided that the problem could be caused by mistakes in the VERIFY CREDIT process. We reflect this by writing a “!” (the number/ID of the problem) inside that process symbol. Further, the group determines that the problem would also happen if the data in the CUSTOMERS data store were inaccurate or not current. We represent that by adding the number “1”a to that data store.
A SME then observes that the problem could be caused by the CREDIT DEPARTMENT if we send them a Credit NOK Order and they send it back as Credit OK Order. That causes us to add the 1 to the External Entity CREDIT DEPARTMENT. Note that I had advised against locating problems in the External Entities but since we had eliminated any other internal causes, this is a legitimate move. Finally, another SME points out that complaints sent to CUSTOMER SERVICE could cause them to send a Credit OK Order to us and we do not check the credit on those. Ergo, we write the number 1 on that External Entity as well.
And the Problem Analysis Continues
At this time, the group feels that we identified at least all of the primary suspects that could cause the first problem. We now repeat the process with Problem number 2, which states “New customer orders are taking too long to process.”
Here again, looking at the diagram, the first place that we see New Customer Orders being treated differently than other orders is the dataflow coming out of the DETERMINE CREDIT STATUS process. One possible cause could be that it takes that process very long to determine that the order is form a New Customer. Ergo, we write the number “2” inside the process. Since we already had written the number “1” in that process, the best way to avoid confusion is to note both problems could be caused here by writing “1,2” together inside the process symbol.
Several of the SMEs observe that it could take the CREDIT DEPARTMENT an inordinate long time to run a credit check on a New Customer Order, which causes us to add the number 2 to the CREDIT DEPARTMENT entity as well. One of the SMEs’ observation that it could take a long time to get the New Customer Order to the CREDIT DEPARTMENT causes us to add the number 2 to the dataflow itself as well.
Online Course: Data Flow Diagrams — Simply Put!
Learn how to implement process modeling techniques for Requirements Elicitation and Workflow Analysis
Keep the Discussion Going
A discussion between several SMEs results in the recognition that it could also take a long time to get the Credit OK Orders back from the CREDIT DEPARTMENT, so we add the 2 to that flow coming from the CREDIT DEPARTMENT as well. Suddenly a light bulb goes off and another SME points out that new customers are also more likely to submit Invalid Orders as well, so we have to add the number 2 to the process VALIDATE ITEM #s AND DESCRIPTIONS, to the Invalid Order dataflow, to the CUSTOMER SERVICE External entity, and to the Valid Order flow coming back from them.
Note
We have written problem # 2 on the diagram in many different processes, on dataflows, and inside data stores. That is a measure of the group’s uncertainty as to where the problem really is caused and implies that someone will have to analyze each of those areas more closely to eliminate the problem. The more familiar the group is with the process under analysis, the fewer places they will put the problem and, unfortunately, the more likely it is that they miss some isolated, quirky causes.
On to problem 3, “The warehouse gets so-called valid orders with incorrect item#/descriptions.” Since this problem statement specifically calls out Valid Orders, the most obvious spot to consider is the process that creates that dataflow, namely the VALIDATE ITEM #s AND DESCRIPTIONS. The group immediately asked for the 3 to be placed inside the process and on the outgoing dataflow as well. Getting the hang of the process, they also mentioned that the problem could be caused if CUSTOMER SERVICE did not correctly fix the Item Number on an Invalid Order. We added the 3 to that External Entity and to the Valid Order flow coming back from them. Another participant pointed out that the problem would also occur if the data in the INVOICES data store were incorrect. That caused us to write the number 3 on that object as well.
Symptoms of Problems
The group pointed out that problem 4 “Shipping is delayed” could only be caused in the WAREHOUSE since we obviously have nothing to do with it. We add that to the diagram but meanwhile a discussion ensues in which they recognized that the delay really could be caused by the previous problem. If a Valid Order actually contained incorrect Item #’s AND Descriptions, that could easily cause the delay. We added the number 4 everywhere we had added the number 3.
Note that this step actually suggests that problem 4 is a potential symptom of problem 3. Properly executed Aristotelian Problem Symptom Reduction should have identified that but, in this case, it did not. Anytime the group decides that a particular problem really should be written everywhere another problem was located, revisiting the Problem Analysis technique could save you a ton of time – in particular if you have a ton of problem statements to consider!
Moving on to Problem 5 “Additional or new staff is not performing well enough”, the group discussion quickly reveals that this problem statement is too vague and could really be written inside every process on the diagram. Without further analysis to uncover Who was not performing well enough doing What, there was no way to localize this problem. We suggest categorizing problems like this one as “Systemic” which limits the need for further discussion by the group and allows them to proceed to the next problem.
The Final Result
The DFD below shows the final result of this exercise with all remaining problem statements allocated. Study the diagram to identify where the group put problem statements 6, 7, and 8 and determine why. As a guideline, compare the logic that we explained related to problem statement 4. To simplify the comparison, we have repeated the problem statements below the diagram.
Problem Statements
- Customers with bad credit are getting their orders filled.
- New customer orders are taking too long to process.
- The warehouse gets so-called valid orders with incorrect item#/descriptions.
- Shipping is delayed
- Additional or new staff is not performing well enough.
- Pickers are away from the warehouse floor
- Customer invoices have incorrect prices.
- Orders are incorrectly filled.
Now notice the clustering of problem statements around the process of validating Item #’s and Descriptions and related symbols. That implies that someone should analyze those areas very thoroughly before the group moves into defining the requirements for any proposed solution. That is the power of visualization at work.
Upon completion of this course, you can:
- Document existing business processes and workflows in Data Flow Diagrams (DFD) to initiate business process analysis
- Defend the need for Data Flow Diagrams, Context Diagrams, and Rigorous Physical Process Models
- Explode a high level Data Flow Diagram to its lower level details to reveal underlying processes and procedures
- Balance DFD’s to identify missing processes
- Use Horizontal Balancing to discover missing data and minimize redundancies
- Document process specifications for functional primitives to guide the solution providers
- Express metadata to reveal informational details that developers need to build the solution
