HarvardBiz and Use Cases?!? Yes, Seriously … And Seriously Misguided!
Tags: business strategy, HBR, IT methodologies, requirements, strategy, use cases
Written by Ronald G. Ross on . Posted in Business Analysis, Requirements, Strategy
Tags: business strategy, HBR, IT methodologies, requirements, strategy, use cases
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”
Jeanine Bradley – Railinc
“Sessions flow together well and build upon the concepts for the series which makes the learning easy and better retention.
The instructor is knowledgeable and very attentive to the audience given the range of attendees skill and knowledge of the subject at hand. I enjoy her training sessions.”
Deborah – American Family Insurance
“Your work has been one of the foundations of my success in our shared passion for data integration. It has had a huge impact on innumerable people!”
Rand Losey – Knowledge Engineers Limited, LLP
“I found the course interesting and will be helpful.
I like the pragmatic reality you discuss, while a rule tool would be great, recognizing many people will use Word/Excel to capture them helps. We can’t jump from crazy to perfect in one leap!
Use of the polls is also great. Helps see how everyone else is doing (we are not alone), and helps us think about our current state.”
Trevor – Investors Group
“Instructors were very knowledgeable and could clearly explain concepts and convey importance of strategy and architecture.
It was a more comprehensive, holistic approach to the subject than other training. Emphasis on understanding the business prior to technology considerations was reassuring to business stakeholders.”
Bernard – Government of Canada
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
Putcha V. Narasimham
| #
Ron:
Your analyses and assessments are well reasoned and helpful but your impression of what a Use Case is or should be is off the mark, if I may say so. I know the importance you place on BIG Picture— business mission and strategy and the like but equally important are the contributing objectives, goals, sub-goals etc.
Though the UML definition of Use case is not sufficiently precise, it is quite clear that Use Case Diagram identifies all the Services System has to offer to its primary users. So each service, called Use Case, is associated with an Actor (user) and each Service has a Business Goal of value to the Actor. This is the Big Picture of the Business Served by the System showing the Business Goals of all its Actors individually (their interdependence and the means to serve them are NOT known at this stage). Clarity of Business Goals and the Dialogs Actors need to have with the System give shape & definition to the internal objects, their operations and interactions. All of them flow from the dialog data—Use Case Description. At this stage the UI is NOT taken up but all the Forms or Dialog Boxes, Fields within the forms, the nature of entries in those fields are all thought of and defined.
This is very systematic and elegant though all software developers do not appreciate and take advantage of this method. It is great someone NOT within IT has grasped the essence and glorified the concept and use of Use Case not only for IT but for non-IT applications. It is indeed very imaginative and profound.
Ronald G. Ross
| #
Putcha – You said “Though the UML definition of Use case is not sufficiently precise, it is quite clear that Use Case Diagram identifies all the Services System has to offer to its primary users”.
>>You’re exactly right — *system* services. But system services are not business solutions to business problems, and a user’s individual goals are not the business goals of the business. It’s a very big difference.
Milan Kratochvil
| #
I agree Ivar Jacobson’s approach gained its world-wide popularity mostly through system Use Cases, due to their benefits in specifying interactive products/appls. However, he also pushed business Use Cases, both during his years at IBM/Rational and earlier,
http://www.amazon.co.uk/Object-Advantage-Business-Re-engineering-Technology/dp/0201422891/ref=sr_1_3?ie=UTF8&qid=1315467663&sr=8-3
I’ve used the latter as a graphical index of BPs, instead of a traditional top-down process hierarchy diagram; it offered more expressive power in “interactive”, client-facing, parts of the business (front office, e-shops etc.).
That said, I doubt it will ever come near the popularity of system Use Cases; standards that approach the mix of text and diagrams from the rule angle (like OMG’s SBVR) are more likely to fit frames of reference of managers, and fit business automation tools like rule engines.
In my exp. it’s vital to be precise, ahead of every UC workshop, about the level of the UC agenda (Biz UCs – or System UCs). Businesses are increasingly good in distinguishing B(P)Models from system specs., except for (paradoxically) in Use Cases – those work as a two-way bridge between business and systems, which bring about both an efficient to-the-point communication, and a risk of blurring the roles and responsibilities involved.
John Russell
| #
“Use cases are about designing systems, not developing business solutions for business problems.”
I don’t understand this line of thought. The only reason a system is designed and built is to solve one or more business problems. Use Cases are currently the best way of describing the users experience (or point of view) in carrying out some meaningful (to them) piece of work – accomplishing some goal on the system.
If that goal does not contribute in some way to the mission of the business (organisation) then I would suggest that the issue is with the requirements themselves, not the method used to communicate them (use cases).
Ronald G. Ross
| #
@John – The question is not about use cases per se, or even requirements. The issue is how you create and model a busines solution to a business problem that can be used as a *starting point* for developing good requirements and well-aligned use cases. The business is in business to do business the best way possible, and then and only then to design systems. We’ve been looking at the problem the wrong way.