Business events/BUC/PUC
Jack
I was just wondering if we could get some clarity or advice on the
relationship between Business Events/Business Use Cases (BUC) and
Product Use Cases (PUC).
I believe we have a very good understanding here of what each of these
is. We are just trying to get a better idea of how many BUCs and PUC's
to use.
Is there generally only one BUC per Business event?
We generally use multiple PUC for a BUC. Is this correct?
How do you recommend we break down PUC's. By functional area? By
department?
Here is the project we are working with. (I think I have wrtien about
this before)
Processing applications on line-
One business event will be 'Person fills in application form online'
The Business Use Case will be something like 'Process Application'
form
This is where thins get a little bit murky for us. The application
form will be passed from one department to another.
Is it a separate business event for each time the application form is
passed from department on or is it still under the one business event
(Person fills in application form online)
Thanks
Jack
PS This group has been very helpful for us!
Robrecht David
I think it might be beneficial to make the event a bit more abstract.
"person applies for membership" as a first cut scope. Depending on the project goal this can then be refined as "Person applies for membership online".
The first description has the advantage that you can then define the output(s) of the process that has been triggered by this event independent from the way the application was done: at a branch, online, through a call centre,....
The second ensures that you don't have multiple BUC depending on the medium.
Your project scope will dictate this.
Compare:"We need to automate our application procedures" to "We need to offer our potential members a means to submit their application details online". The second can result in a very small project where the output is a printout in the back office of the online form"
The business use case can be "Process application form" or "investigate new application". There is a chance that the steps involved in investigating a new application are the same no matter how the application was made.
Now my advice is that as long as the process is under some centralized control, there is only one event. If the departments involved are very independent you can consider a model one level deeper, where each handover is modeled as a new event. The first will probably give you multiple PUC for one process ('Person fills in application form online' being one of them) The second could lead to one BUC one PUC. This last approach has the disadvantage that people will question the added value of modeling the same thing twice, it does have the advantage of thinking through the necessary business steps first, before designing the PUC. If the scope of the PUC is different than the BUC you have no choice.
The question is this: is the passing of the form the equivalent of a control signal? The receiving department MUST proceed in this or that way. Compare with returning some questionnaire to the applicant. This will end your process, the return of the questionnaire is out of your control and will be a new event.
Met vriendelijke groet
Robrecht David
robrech...@advalvas.be
Eenmeilaan 7
3010 Kessel-lo
-----Original Message-----
From: vol...@googlegroups.com [mailto:vol...@googlegroups.com] On Behalf Of Jack
Sent: woensdag 16 september 2009 01:21
To: Volere Requirements
Subject: Business events/BUC/PUC
Hi,
I was just wondering if we could get some clarity or advice on the
relationship between Business Events/Business Use Cases (BUC) and
Product Use Cases (PUC).
I believe we have a very good understanding here of what each of these
is. We are just trying to get a better idea of how many BUCs and PUC's
to use.
Is there generally only one BUC per Business event?
We generally use multiple PUC for a BUC. Is this correct?
How do you recommend we break down PUC's. By functional area? By
department?
George Brooke
Hi Jack,
I hope you don't mind if I give you my take on this. I have copied your questions into my email and attached answers.
1. Is there generally only one BUC per Business event?
· Generally true, but not necessarily. I could imagine a BUC being joined midway for example, by a higher-level Business Event occurring, so a BUC with multiple entry points. Similarly, a BUC could be triggered by several Business Events. However, when you see such things it is an opportunity to questions and perhaps redesign at the Business level and gain even more benefits, by problem simplification.
2. We generally use multiple PUC for a BUC. Is this correct?
· Absolutely.. it is quite normal to see sequences of manual and automated process. An important point here is to recognise opportunities for re-use of PUC and possible process simplification.
·
3. How do you recommend we break down PUC's. By functional area? By department?
· A PUC will have a Primary Actor who (usually) initiates the “conversation”. That Actor would come from a department and will need to have a recognisable title from your organisation. A PUC spread over multiple departments sounds a little suspicious to me and I guess I would need to see the detail before commenting further. I would not rule it out, but it could reflect a conflict between the BUC and PUC structure.
4. Here is the project we are working with. (I think I have written about this before)
5. Processing applications on line-
6. One business event will be 'Person fills in application form online'
a. OK with that
7. The Business Use Case will be something like 'Process Application' form
a. Ok again
8. This is where things get a little bit murky for us. The application form will be passed from one department to another.
a. If in the passing there is a manual intervention, for example a document is printed out and then goes for approval before going into the PUC, then this would imply 2 or more PUCs. Alternatively, one PUC could do it, if it maintained a State about the document… as in “Stage 1 OK”, “Stage 2 OK”, “Stage 3 pending”, meaning that the document if reopened in the PUC, would start with Stage 3 processing. However, this could get complex and it is a trade off between fewer PUC and flexibility. Personally I would go for separate PUCs and anchor them off one higher level window, so that the user does not get to see that there are different PUCs in use.
9. Is it a separate business event for each time the application form is passed from department on or is it still under the one business event
a. I see this as a hierarchy of Business Events. The first one can trigger one or more subsequent events. This concept allows easy tracking of events and process. You can sometimes handle this by naming conventions. If the top level BE is BE1, then the subsequent BEs are BE1.1, BE1.2 and so on. This can get messy though if BE1.1 might also be used by another BE process say BE2.
b. Each BE triggers a BUC and then one or more PUC. It would be sensible to keep a spreadsheet view of all of this. As James knows I am not a proponent of diagrams because, although they present concepts well, they do not allow you easily to track (significant) changes or analyse. A simple table of BUC against PUC does. It is terse and easy to manage.
10.(Person fills in application form online)
a. Which them presumably goes back into the PUC and then into the containing BUC , which may or may not trigger the PUC to issue and acceptance or whatever.
I hope this helps. Please feel free to contact me again
Best regards
George Brooke
Oak Lodge Consulting Ltd
20 Back Road
Linton, Cambridge
CB21 4JF
Tel: 01223-890390; Fax: 0870-7063077
Mbl: 07710-325818
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
-----Original Message-----
From: vol...@googlegroups.com [mailto:vol...@googlegroups.com] On Behalf Of Jack
Sent: 16 September 2009 00:21
To: Volere Requirements
Subject: Business events/BUC/PUC
Hi,
Jack
are doing things mostly right.
I would just like to discuss a couple more points.
Continuing with the work in question which is Processing Applications
on line.
I think what you are saying is that each time an application form gets
passed from one department to another it is a separate business event
and therefore separate BUC.
For example, Department A initially receives the application. The
business use case is something like Begin Processing Application Form.
When Department A has finished there part of the processing they will
pass it on to department B (who may for example handle the medical
part of the application).
In this case the business event is something like 'Department A has
entered prospect data'. The business use cases for department B will
be something like 'Add Medical data to Application form' Is this the
best way to use BUC's?
Finally. When doing PUC's how do we handle duplication of
requirements. Again using the example above-
Department A has requirement to update a status field and Department B
have the exactly the same requirement. Do we repeat same the
requirement for each PUC? (They will be separate because the are
separate BUC's)
Thanks again
Jack
On Sep 17, 8:47 pm, "George Brooke" <geo...@oaklodgeconsulting.co.uk>
wrote:
>
> I hope you don't mind if I give you my take on this. I have copied your
> questions into my email and attached answers.
>
> 1. Is there generally only one BUC per Business event?
>
> BUC with multiple entry points. Similarly, a BUC could be triggered by
> several Business Events. However, when you see such things it is an
> opportunity to questions and perhaps redesign at the Business level and gain
> even more benefits, by problem simplification.
>
> 2. We generally use multiple PUC for a BUC. Is this correct?
>
> re-use of PUC and possible process simplification.
>
> 3. How do you recommend we break down PUC's. By functional area? By
> department?
>
> have a recognisable title from your organisation. A PUC spread over multiple
> departments sounds a little suspicious to me and I guess I would need to see
> the detail before commenting further. I would not rule it out, but it could
> reflect a conflict between the BUC and PUC structure.
>
> 4. Here is the project we are working with. (I think I have written
> about this before)
>
> 5. Processing applications on line-
>
> 6. One business event will be 'Person fills in application form online'
>
> a. OK with that
>
> 7. The Business Use Case will be something like 'Process Application'
> form
>
> a. Ok again
>
> 8. This is where things get a little bit murky for us. The application
> form will be passed from one department to another.
>
> a. If in the passing there is a manual intervention, for example a
> document is printed out and then goes for approval before going into the
> PUC, then this would imply 2 or more PUCs. Alternatively, one PUC could do
>
> - Show quoted text -
Suzanne Robertson
The start of a business event is governed by the work scope that you have
declared for your project. A business event takes place in an adjacent
system. The response to the business event (the BUC) is everything that
happens within the work scope - usually defined using a work context
diagram.
If the business event is "Client wants to apply for Medical Aid" then the
BUC is everything that the part of the business bounded by the work scope
does in order to respond to the business event.
In your example part of the BUC is carried out by Department A (do initial
processing) and part by Department B (do medical processing). You can model
this using a process model or linked scenarios or whatever other modelling
technique you prefer. The response to the business event (the BUC) ceases
when every ripple caused by the business event has resulted in either stored
data or a flow of data going to an adjacent system.
The PUC/s is/are the part/s of the BUC that you decide will be carried out
by the product that you will build.
Steve McMenamin and John Palmer were the people who formalised the use of
business events for helping to organise the analysis of a business problem.
Thanks for your interesting questions and keep talking.
Regards
Suzanne
The 2009 Business Analysis Conference will be held in London 28-30
September. There will be an exciting mixture of talks and workshops
featuring sociological and technological aspects of Business Analysis.
James Robertson, Suzanne Robertson and Neil Maiden will present a workshop
on ³How Business Analysts can be Innovative when Gathering Requirements².
For details of all the talks have a look at
http://www.irmuk.co.uk/ba2009/
Suzanne Robertson The Atlantic Systems Guild Ltd.
11 St. Mary's Terrace London
W2 1SU UK
mail: suz...@systemsguild.com
phone: +44(0)20 7262 3395
http://www.systemsguild.com
==============================================================
James Robertson
the point of the BUC is that it shows *all* that the *business* does
in response to a business event. I suggest that you think of the BUC
as the combination of what departments A, B and C do whenever the
application is submitted from outside the organisation.
The reason for this is in your answer -- there is almost always some
duplication between departments. By disregarding the departmental
boundaries you get the true business view, and it is this you base
your future implementation upon.
I hope this helps.
James
James Robertson
the Atlantic Systems Guild
ja...@systemsguild.net
http://www.systemsguild.com
http://www.volere.co.uk
Twitter: VolereResources
Facebook: facebook.com/JamesStruanRobertson
Our new book: 'Adrenaline Junkies and Template Zombies' has won a Jolt
Award
Amazon: http://bit.ly/TKIoR
Dorset House: http://bit.ly/teqZR
Jack
I think part of the issue is that we are thinking in terms of process
and are breaking down the adjacent systems to much.
Regarding the work discussed (applying for an application online) we
have several departments (each for processing a part of the
application) as adjacent systems. I think what you are saying is that
these departments should be one adjacent system. So rather than
viewing what work each department has to do, view it as what has to be
done to get the work done. So our new context model (in a very
simplistic way) would be something like
Adjacent System = Person
Business Event = Person wants to apply to get health insurance
Input = Personal Data (coming into the work)
BUC = Collect data from person
PUC = The automatic part of the BUC
Adjacent System = Our Organisation (which will include all
departments)
Business Event = Person has provided data to become a member
Output = Personal Data coming from the work)
BUC = Process application form
PUC = The automatic part of the BUC
Once again thank you.
> Facebook: facebook.com/JamesStruanRobertson
>
> Our new book: 'Adrenaline Junkies and Template Zombies' has won a Jolt
> Award
> Amazon:http://bit.ly/TKIoR
James Robertson
I mean that you consider all of your organisation to be inside the
context bubble. Your customer is outside, and any department that is
definitely off limits is outside (that is, an adjacent system).
Otherwise, the wider the scope of your context the better the business
result you get.
James