Words, Words, Words
I have spent an inordinate amount of time lately talking about the benefits of language—something you might appreciate since your are currently reading this blog AND understanding it. Language is a sort of human-level contract we have with each other and by using it we can find our way to understandings—flawed as that may be at times. In fact, some people have developed a discipline of double checking their language and stop to ask questions—feedback to make sure the intended receiver understood the implications of the message (and no, I am not going to talk about TCP/IP).
The requirements process depends upon language to discover critical business features and those that use it will eventually attempt to describe what they learned to developers. However, the understandings (requirements) themselves undergo a transformative process, probably not unlike a Kantian meat grinder in the mind of the business analyst—inputs transforming into logical outputs on the other side. However, even such a rigorous empiricist like Kant expected that new knowledge had to under go the test of common sense. This provided the critical feedback loop to make sure that a proposition was worth its value–so much for a priori knowledge. At this point, one has to ponder the following question: “If the empiricists cannot establish a rational basis for a solid requirement that can stand the test of time then who can?” This is the equivalent of asserting that at any give moment one may be 50% certain about the requirements but if any assumptions change all bets are off—and this includes any assumptions not imagined at the time the requirements were written.
All of this boils down to uncertainty that cannot be eluded in the requirements process because it is conducted by humans and assumptions change. Managing change and embracing it is fundamental to human experience and needs tooling.
Change and ambiguity are closely related. While working in the financial services space I discovered that for a bank, there is no single balance to an account. The concept of “Account Balance” is understood at all levels of the organization, but this concept often translated into 30 or more concrete variants. All of these had to be understood to support the requirements process. In talking about the fields, the developers did not always share nomenclature. They also used odd-prefixes and suffixes in class names common to their language and they were prone to using synonyms introducing confusion along the way. To avoid this, the business analysts kept a glossary of terms to track the differences and help remove the ambiguities.
Using the vocabulary of a BRMS binds the language of business to the concrete and executable model of the code. This solves several problems:
1. Removes ambiguity by mapping terms to concrete equivalents.
2. Offers levels of validation that non-executable requirements cannot—completeness, regression, versioning, difference and many more.
3. Developers enjoy receiving something that they can use—saving time without waiting to till GUI is available for testing.
4. Concepts or content that don’t belong in a rule can remain affixed to the rule in the form of a description—why is this rule important to the business and what might happen if it did not exist.
5. Requirements expressed as rules can be kept current and eliminate the tendency for them to become stale.
6. Changes can be deployed without shutting down production systems.
It’s true that you can’t express everything as a rule—let’s not fall into myopia. Nor will a BRMS solve all requirements pitfalls; but it is tooling that helps organizations scale by helping us use our language better. In the end, it’s all about words and what they can do…not software.
CCB
