Volere Requirements Google Group

New Group

suza...@systemsguild.net (Suzanne Robertson) — Wed, 11 Nov 2009 03:23:43 UT

Dear Group Members,

This is to let you know that we have started a new Volere Requirements
group on LinkedIn. The reason for this is that the medium is more
interactive and you will find it easier to have conversations about
your use of the Volere techniques. If you would like to join the group

Re: Business events/BUC/PUC

ja...@systemsguild.net (James Robertson) — Fri, 09 Sep 2009 14:52:07 UT

Jack,

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.

Re: Business events/BUC/PUC

jack...@yahoo.com (Jack) — Fri, 09 Sep 2009 02:34:56 UT

Thank you so much again. This is giving us far better clarity.

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

Re: Business events/BUC/PUC

ja...@systemsguild.net (James Robertson) — Thu, 09 Sep 2009 17:48:34 UT

Jack,

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

Re: Business events/BUC/PUC

suza...@systemsguild.net (Suzanne Robertson) — Thu, 09 Sep 2009 17:53:37 UT

Dear Jack,

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

Re: Business events/BUC/PUC

jack...@yahoo.com (Jack) — Wed, 09 Sep 2009 05:06:05 UT

Firstly, thank you very much for your help. You have confirmed that we
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

RE: Business events/BUC/PUC

geo...@oaklodgeconsulting.co.uk (George Brooke) — Thu, 09 Sep 2009 08:47:03 UT

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

RE: Business events/BUC/PUC

robrecht.da...@ae.be (Robrecht David) — Thu, 09 Sep 2009 08:58:50 UT

Jack

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,....

Business events/BUC/PUC

jack...@yahoo.com (Jack) — Tue, 09 Sep 2009 23:20:47 UT

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

Re: Context Diagrams for extremely large projects

n.mor...@xtra.co.nz (Nathan) — Thu, 09 Sep 2009 21:44:44 UT

Hello everyone, and Megan in particular.

I posted a similar topic a while back and received some useful
guidance from both of the Robertsons about discovering the processes.
A couple of observations / considerations:

1. You or your team will have to know the specific business processes
in place at the moment, to be supported by the future product.

Volere & Personify Teamspec

ke...@paym8.co.za (kerryP) — Wed, 09 Sep 2009 09:40:29 UT

Teamspec (aka Personify) provides for Requirements described in a Word
document to be taken into Microsoft Visual Studio as Work Items.
Does anybody have experience of producing Visual Studio Work Items
from a Volere Word document?

Re: Context Diagrams for extremely large projects

roberts...@gmail.com (Rob) — Thu, 09 Sep 2009 11:51:09 UT

Megan:

A couple of comments on you overall project.

It is very hard to "replicate" a "very large" system. You may
understand the features (use cases), but it is likely you don't
understand how those features are used (scenarios). Users are often
very innovative about using features for "non-intended" purposes. If

Re: Context Diagrams for extremely large projects

m...@cox.net (Mark Wallace (Los Angeles)) — Sun, 08 Aug 2009 20:10:05 UT

The two biggest risks that I can see are:

1. A hint of contradiction in the orders coming down from OrgB
management. On the one hand, the "mandate is to replicate the system
exactly" from OrgA into OrgB. On the other hand, "once OrgA has
documented what is required, OrgB may then decide to not do some bits

Volere for an Undergraduate Class

roberts...@gmail.com (Rob) — Sat, 08 Aug 2009 13:00:52 UT

I’ve just been assigned to teach a sophomore-level Software
Engineering class on Requirements. Our text is Robertson and
Roberson, “Mastering the Requirements Process” with Volere. The first
class is a week away.
Does anyone have resources they would share with me? Examples would
be:
-Small homework assignments to reinforce lessons from a chapter

Re: Context Diagrams for extremely large projects

gbridge...@gmail.com (Gb2009) — Fri, 08 Aug 2009 14:49:01 UT

Hi Megan,

I agree with George Brooke. The context diagram is a good
communication tool to help you and the stakeholder understand the
system/work boundaries.(scope)

George