This example might appear to be contrived, but these lessons generalize. We too have
situations in many different settings and with many different representation techniques and methods. The DFD notation is not the only one that suffers from these problems and misuses.
They were all ready to start the walkthrough. Fred had been working on part of the sales accounting system: the problem of matching customers' payments to their outstanding invoices. He had produced a data flow diagram, and was going to walk through it with Ann and Bill. Jane was there too, because she was new to the team and didn't know about data flow diagrams. This was a good opportunity for her to learn about them. Fred had invited her, and the project manager said it was a good idea.
"The diagram I'm going to show you," said Fred, "expands a process bubble in the diagram at the
level up. Here's the bubble to be expanded." He showed this viewgraph on the overhead projector:
"The payments come in from customers—that's the arrow on the left. Basically, we have to send the payment details to the cashiers for banking—that's the arrow on the right—and put a payment record into the Receivables file on the top right. To do that, we must match the payments with invoices that we get from the Receivables file. If we can't match a payment we put it into the Untraced Payments file, and someone else deals with it. If the payment is not enough to cover the amount in the invoice we send the customer a request to pay in full—that's up at the top left. Oh, and we also send them
to explain untraced payments. OK so far?"
"I suppose you need the Customer file so you can put names and addresses on the payment and explanation requests," said Ann.
"Right," said Fred. "Now here's the diagram I've done that expands the process bubble." He put another viewgraph on the projector. It was this:
"Looks good," said Bill. "Let me see if I can walk through it. The Verify Payments process checks to see whether a payment has an invoice number. If it has, you find the invoice—that's the Find Invoice by No process at the top of the diagram—and send it with the payment to the Compare Amount process. If it hasn't, you have to search for the invoice by using the customer's name and the amount of the payment. If that doesn't work you have an untraced payment. Otherwise, you send the invoice and payment details to the Compare Amount process as before. Am I on the right lines?"
"Absolutely," said Fred. "Right on."
"The Compare Amount process checks the amount paid against the invoice, and whether it's a full or a part payment you send the details to the cashier for banking and put a payment record in the Receivables file. If it's a part payment you also produce a full payment request. Am I right, or am I right?"
"Terrific," said Fred. "You just
to say that untraced payments go to the Produce Explanation Request process so we can send a request to the customer."
"Sounds good to me," said Ann. "We could have an early
"Well, wait a minute," said Jane. "I haven't really
what's going on. You said that Verify Payments sends each payment either to Find Invoice by No, or to Search for Invoice, depending on whether it has an invoice number or not. Where does it say that in the diagram?"
"Verify Payments has one input data flow and two outputs," said Ann. "That's where it says it. It's just like the Search for Invoice process. That's got one input data flow of payments without invoice
, and two output flows, one for untraced payments, and one for payments with invoices."
"But the Create Payment Record process also has two output flows," said Jane, "one for payment records for the Receivables file, and one for payment details for the bank. But it sends each full or part payment to both of those, not just to one."
"Ann's a bit
," said Bill. "A data flow diagram doesn't show whether a process
to one or more of its output flows for each input message. That's at a lower level, probably in the process specification. It's a top-down technique."
"I'm not at all confused," said Ann. "It just depends on your conventions. And I know about top-down as well as you do."
"All right," said Jane. "So we're using Bill's convention. So how do you know that Verify Payments never writes on both its output data flows?"
question," said Fred. "It's obvious, because one flow is named Payment Quoting Invoice No and the other one is Payment Without Invoice No. You have to read the names. Names are very important in systems analysis."
"I am reading the names," said Jane, "and I don't understand them at all. For example, does 'Full Payment' mean the exactly right amount has been paid, or does it include overpayments? And does 'Invoice and Payment Details' mean exactly one invoice and one payment? Don't customers sometimes send one payment to cover more than one invoice? And they could send two checks to cover one invoice, I suppose, as well, couldn't they? And then, what's this Search for Invoice process doing? Suppose there are two invoices for the customer, both with the same amount as the payment? Or two invoices adding up to the amount of the payment? Does 'Search for Invoice' mean it's only searching for one invoice? Or suppose it finds just one invoice, but it's less than the payment? I don't see how you can work out from the diagram whether these are real possibilities, and, if so, what's supposed to happen when they
"Look, Bill's already said it's top-down," said Fred, "so you can't expect to answer all these detailed questions now. You'll have to come along to the next walkthrough when I'll have the next level of data flow diagrams for the more complicated processes here—probably for Search for Invoice and Compare Amount—and process specifications for the rest."
"But I don't think these are detailed questions," said Jane. "The problem is matching payments to invoices, and you're telling me that the diagram doesn't show whether the matching is one-to-one, one-to-many,
, or many-to-many. I'd have thought that was a fundamental question about a matching problem, not a detailed question. If the diagram doesn't show that, what does it show?"
"Well," said Bill, "it shows that the function of matching payments to invoices needs seven processes connected by the data flows you can see. That's what it shows."
"I don't understand," said Jane. "It seems to me that it just shows that Fred thinks that seven processes connected like that would be useful. But to find out what the function is, or what the processes are, we have to wait till the next level. So the diagram shows that Fred thinks seven processes would be good for the function, but we don't know what function and we don't know what processes. That can't be right, surely?"
"Hold on," said Fred. "We're going way off track here. The questions Jane is asking about the matching problem are all good questions, and the whole point of the data flow diagram is that it makes you think about the good questions—just like Jane is doing. She's got the idea pretty fast," he said, ingratiatingly. "That's what a walkthrough's all about."
"Nice of you to say so," said Jane, "but I'm still lost. Suppose we do discuss and think about these questions, would we be able to show the answers in the diagram? From what everyone's been saying, we wouldn't be able to. We'd have to wait till the next level. But I don't see how you'd do it at the next level either. Until you get down to the process specifications you keep talking about. I suppose you could tell from them what it's all about, but if there are lots of levels you might have to wait a long time. The data flow diagrams in the levels above don't seem to be much use. They're just vague pictures suggesting what someone thinks might be the shape of a system to solve a problem, and no one's saying what the problem is."
"Jane, that's offensive," said Bill. "Everyone uses data flow diagrams here, and everyone
that top-down is the right way to do things. There just isn't any other way. You have to start with the big picture and work your way down to the details."
"Perhaps," said Jane, "but the big picture isn't much use if it doesn't say anything you can understand. You're all just guessing what Fred's diagram means. It wouldn't mean anything at all to you if you didn't already have a pretty good idea of what the problem is and how to solve it."
They went to lunch after that. It was a rather uncomfortable lunch. After lunch Bill and Fred were walking together back to the office they shared. "I don't understand Jane," said Fred. "No," said Bill. "I don't think we should invite her to the next walkthrough, do you?"