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
“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
We define a business model as follows
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.
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.
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.
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