Function Definition

This technique is all about processing from the users' perspective. Do you remember reading in the Dataflow Modelling section that the DFD's structure and levelling is rather subjective? I said that three different business analysts could come up with three different versions. Actually with the same business analysts but a different set of users being interviewed, the same can happen.

Well, it's ok as the DFD has served its purpose in this respect, it identified the lowest level processes irrespective of sequence, and their inputs and outputs.

Now its up to the users to string these elementary processes together or split parts of them off and group with others to suit how they see the processing actually going. It's the first time that the business analyst and users consider sequence.

The way you and they do this is to take a each lowest level DFD in turn, pick a triggering event, and follow it through the various elementary processes on this and possibly other lowest level DFDs until the user indicates that this event has fully been handled. It can be a bit difficult to know when an event has been "fully handled". Well, it's down to the users to make this decision.

When they're doing it they'll be thinking something like:

"hmmm.. I need to do this with it immediately, and it makes sense to do this at the same time, and these common exceptions may need to be sorted as well. Oh, and rather than Eric over in stores doing the next bit - I can do it at the same time, 'cos I'll have all that I need right in front of me - better check with him and the rest of them over in stores. I don't know why the business analyst thought they were separate processes when doing the DFD, it makes sense, now that I think about it, to group them like I'm thinking. I'll then get a set of screens, all just a click away, with all the fields possible, pre-filled in, to let me handle that piece of work. I'll whiz through it! No more late nights - hooray! Then it's over to Mary in Accounts to do the billing - but she'll get that in her work queue, so that's cool."

A quick note on sequence. In the environments where a supplier is involved, as for this briefing study, entity life histories (another technique to have in your toolkit) are not proposed. What the technique would normally address (sequence and business rules) is so closely coupled with suppliers' needs to be intimately involved with analysis of detailed requirements, they will have their own method and will be responsible for the technique actually used.

As functions are identified, they are classified and grouped according to batch / online, user / system initiated, enquiry / update.

For example, in PhotoReady, if someone places an order by buying through PayPal (rather than them sending me an order via ordinary email) I receive an email summary from PayPal telling me that someone has just paid for their shopping basket. PayPal gives me a transaction id and a brief summary of the transaction. I treat this as notification of an order and when I reply to it, the reply is automatically addressed to the email address of the purchaser. I attach the high resolution versions of the photos ordered and send the email (in my reply I also ask if they need a VAT receipt). Later, I log onto my account on PayPal's web site and view the details of the transaction. I copy these and paste them into an email to my book-keeper as it gives all the order details for her to enter onto the system. If I later receive a reply from the customer saying that s/he needs a VAT invoice, I forward that request onto my book-keeper, cc'ing the customer.

So the question is, when have I followed the triggering event all the way through the processes until it is completely handled?

With my business analyst hat on, I can see three functions. The first deals with the order receipt and supply of photos. The second is the book-keeper recording the order details on the accounting system and the third is the book-keeper supplying a VAT invoice when a request is made.

When I switch roles and put on my user hat, I know that the one covering order receipt and supply of photos really needs to be split into two. Yes, for the most part having one to cover both is ok, however, I know that on occasion there is something special about an order that means I cant do both together. In such special cases I have to acknowledge receipt of the order and payment but I can't supply the photos immediately - perhaps they are to be modified in some way first or I have to get them printed and sent through the post instead. In other words there is a separation in time between doing the first part and then the second. This leaves the opportunity for a cancelled order and I choose not to pass on orders to my book-keeper, for recording on the accounts system, until they are done and dusted.

The above is a good example of why the users must do the function grouping - only they have the on-the-ground experience to know what is practical.

A question for you - what would you need to take into account with the user when classifying the implied functions above into user / system initiated, enquiry / update, and batch / online?

If you are still having trouble with functions, it may help to think of a Windows application that has been purpose built for PhotoReady. Imagine the drop down menus across the top of the main window. There'd be main menus including Customer Maintenance, Order Management, Book-keeping, Photo Library Maintenance and so on. In each of the drop down menus there'd be options followed by" …" and these would take you to a screen. Well that screen, perhaps with sub-screens accessible from it (e.g. with "more…" buttons), equates to a (user initiated) function. An options screen where you might set how frequently to collect email or when to take a backup, implies a system initiated function.