Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘use cases’

Your Current Requirements Approach: A Very Big Question Mark

Each business rule usually produces multiple flash points.  Don’t know what a flash point is? I think you should! See a brief explanation: http://goo.gl/pl9sT. Why is this insight so important?  The two or more events where any given business rule needs to be evaluated are almost certain to occur within at least two, and possibly many, different processes, procedures, or use cases.  Yet for all these different processes, procedures, and use cases there is only a single business rule. Now ask yourself this (the very big question): 

What in your current IT requirements methodology ensures you will get consistent results for each business rule across all these processes, procedures, and use cases?

Unfortunately, the answer today is almost always nothing In the past, business rules have seldom been treated as a first-class citizen.  No wonder legacy systems often act in such unexpected and inconsistent ways(!).  Organizations today need business operation systems where business governance, not simply information, is the central concern. Business rules should be seen as one of the starting points for creating system models – not something designers eventually work down to in use cases.  That’s the tail wagging the dog. By unifying each business rule (single-sourcing), and faithfully supporting all its flash points wherever they occur, Business Analysts can ensure consistent results across all processes, procedures, and use cases.  Is there really any other way?! ~~~~~~~~~~~~~~~~~~~ Excerpted from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp,http://www.brsolutions.com/bbs  

Continue Reading

What’s the Difference Between Business Requirements and Functional Requirements?


We’re teaching our online training course next week: Business Analysis with Business Rules: From Strategy to Requirements. http://goo.gl/Vnko3 Hope to see you there! Naturally, we’ll be talking a lot about business requirements. Are business requirements the same as functional requirements? No! Functional Requirement vs. Business Requirement Wikipedia describes a functional requirement as … “a requirement that defines a function of a software system … what a system is supposed to accomplish” [emphasis added] We define a business requirement as … “something called for or demanded by a business model that a system model must support” That’s a big difference! Appreciating the importance of the difference, however, requires clear understanding of the distinction between business model and system model. Business Model  We define a business model as follows[1]a blueprint for a business capability based directly on real-world things and ideas strictly named and represented using words natural to business people We stress that business people talk about real-world things! And why should we ask them to do any differently?! A business model enables business people and Business Analysts to engage in discussion about what needs to be created, managed, operated, changed, and discontinued in the business in business terms.  Developing a business solution using a to-be business model does not necessarily imply software development, but if software development does ensue (as it usually does) the business model provides a solid grounding. Examples of business models include strategies for business solutions (Policy Charters), business process models, structured business vocabulary (concept models), business milestone models, and Q-Charts (for decision analysis). Any business model is always subject both individually and collectively to the business rules specified for it(!) We believe business rules are key to creating effective business requirements. System Model We define a system model as follows … a model that provides a design for an automatable system that is computationally competent For many years John Zachman, creator of the Zachman Architecture Framework, has explained that a business model is always about real-world things.  These real-world things are as the business leads see or define them.  That idea is actually his, not ours. Zachman describes a system model, in contrast to a business model, as comprising “… surrogates for the real-world things so that the real-world things can be managed on a scale and at a distance that is not possible in the real world.”  Surrogates include …
  • data entities or business objects in place of real-world things.
  • GUIs and use cases in place of face-to-face, real-world communication.
  • network nodes in place of real-world locations.
  • system events rather than operational business events.
  • etc.
If you are developing ‘requirements’ using use cases, you are actually designing a system (creating a system model), not defining business requirements(!). We believe a focus on use cases with no prior business model puts your project at grave risk.
[1]Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, 2011, 304 pp.http://www.brsolutions.com/bbs
 

Continue Reading

HarvardBiz and Use Cases?!? Yes, Seriously … And Seriously Misguided!

HarvardBiz  The Case for Starting a Design Revolution http://s.hbr.org/nXsdOk
 
This article is fundamentally misguided. I’m surprised to find such an article associated with HBR. Use cases are about designing systems, not developing business solutions for business problems.
 
All change initiatives should start with a clear, structured view of business goals and business risks, and what business policies and business tactics will best solve the business business problem. I’m talking, of course, about business strategy. That’s the conversation that business leads want to have. Get them engaged in a discussion of system interaction and GUIs and you’ll inevitably miss the big picture.
 
What if your business *is* about eCommerce? No matter, you still need thought first given to business strategy — the goals, risks and policies needed for a winning business solution. Good requirements will flow naturally from that base. This have always been a notoriously weak area of IT requirements methodologies. Just don’t believe IT professionals who say use cases will solve your business problems. Design attractive systems, yes (done correctly). Guarantee business success? You’re counting on nothing more than good luck.

Continue Reading 5 Comments