Community,

I have a semantic related question that I am struggling with.

I'm writing a high level series of lectures to help explain the totality of what we do. I'm at 700 pages so far covering ...

1. Preambles on the business, guiding principles integrated delivery and requirements and change management
2. Understand an iterative rational approach
3. Understand the Business Analyst’s role in building requirements within a business model
4. Understand the basic process of business analysis
5. Understand different levels of requirements and how they feed into testing
6. Understand the components of a business requirements document
7. Understand how to gather requirements
8. Understand how to write structured requirements
9. Understand Business Process Modeling and its concepts
10. Understand Object Oriented Modeling and its concepts
11. Understand how to create the models as requirements
12. Understand how to package the BRD
13. Understand how to transition to the development process

I'm in the middle of covering use cases within the UML key concepts framework. I am writing about the components needed for a use case. I'm on business events.

I am stating that only ONE business event (trigger) per use case. Do you agree? Assuming that is an accurate statement here is my dilemma

In the example of RENT VIDEO

You may have a trigger that reads “This use case starts when the customer approaches a video counter and presents a video to a client service representative”

This does not allow for other ways to rent a video such as on-line or at a kiosk. If I alter the business event to read ....

“This use case starts then the customer either approaches a video counter and presents a video to a client service representative, logs into their online account and selects a rent video option or inserts a credit card into a kiosk and selects a rent video option."

To me this breaks the one event rule even though it is written as a single sentence. Do you agree?

If so ..... would you agree that to solve the problem we would have to abstract the RENT VIDEO use case and create specialized use cases to handle the other options?

If so how .... how might that business event be written because it's still an OR option but in this case takes you to 1 of 3 other use cases.

what are your thoughts community? this all hinges on if you agree that there should only be one trigger / business event per use case.

its all semantics I know but I'm trying to establish a best practice to teach here at my current contract. I also plan to post my writings on my site and here as well.

any thoughts you have would be really helpful

Have you looked at the Business Analysis Body of Knowledge at www.iiba.com ? It addresses many of the general things you have in your list, but it does not attempt to be specific about how to use  techniques like Use Cases, with good reason.

In your specific example, I am reminded of Martin/Finklestein's Information Engineering, where lowest level business functions were defined, such as the data input, processing and storage to support something like Rent Video; around that, however, it defined one or more physical procedures that would make use of the function, allowing it to be invoked in different ways without its common processing needing to be replicated.

Overall, I think Use Cases are so popular because they can be used many different ways,  but that does not bode well for their use in a rigorous approach such as I think you are working on.  In fact, IE is the only methodology I have seen over the decades that achieved any level of rigor, with its models that could then be used to generate code... and most people hated it because it was too 'restrictive', and it got dragged down with the implosion of AD-Cycle. Ah well, perhaps we will get there again at some point.

Respondents et al,

Thanks for the comments folks. No question that UCs are deceptively simple. The place that I am at now tried UCs before and nearly ended a multi-year project b/c of disagreements. They brought me in to establish best practices for everything that I have listed above. It's been fun writing the series ... I am for sure going through my heard and pulling out all I've learned, not to mention all of my text books, school books (including the BABOK and PMBOK).

sooooo much to cover eh. We really do-do a lot in our industry - jack of all master ....

Anyway to avoid argument I am staking it in the sand and saying 'whenever possible, stick to one trigger' - be they system or business use cases. At the end of the day – the use case should allow for design without constraining that design. I want to avoid a lazy atmosphere where a BA writes one use case with a 1000 do-whiles and if-else-thans set up as triggers .. can you imagine.

Now there is an easy back out if ever I've written one. LOL