I am working on some tutorial material for business analysts tasked with eliciting and harvesting rules using some commercial business rules management systems (BRMS). The knowledgeable consumers of this material intuitively agree that capturing business rules should be performed by business analysts who also capture requirements. They understand that the clarity of rules is just as critical to successful application of BRMS as the clarity of requirements is to “whirlpool” development.[1] But they are frustrated by the distinct training for requirements versus rules. They believe, and I agree, that unification of requirements and rules management is needed.
Consider these words from Forrester:
One might argue that Word documents, email, phone calls, and stakeholder meetings alone are adequate for managing rules. In fact, that is the methodology currently used for most projects in a large number of IT shops. However, this informal, ad hoc approach doesn’t ensure rigorous rules definition that is communicated and understood by all parties. More importantly, it doesn’t lend itself to managing the inevitable rules changes that will occur throughout the life of the project. The goal must be to embrace and manage change, not to prevent it. [2]
But note that Forrester used the word “requirements” everywhere I used “rules” above!
The fact is, BRMS vendors target business analysts, promising that they can capture and maintain rules externalized from application infrastructure. But BRMS vendors do not support capturing and maintaining requirements.
A better vision would unify rules with requirements in a single framework of understanding and within a single management tool. Otherwise, rules will remain downstream from functional requirements and use cases in the development process. Consequently, business rule management systems (BRMS) would always be at least one step removed from business analysis – and, therefore, end users.[3]
Until BRMS vendors do support requirements, business analysts will continue to use word processors, spreadsheets, or requirements management software. And for the most part, they will do so instead of – rather than in addition to – using a BRMS.
There are many thoughts on how to elicit business rules and requirements.[4][5][6][7][8]
Surprisingly, there is substantial confusion on the relationships between rules and requirements.
For example, some have written: [9]
- rules are not requirements[10]
- rules cannot be managed using requirements tools
- rules must reference requirements which must not reference rules
A distinction should be made between functional and non-functional requirements (as in ISO 9126[11] and according to NASA[12]). When we use rules we are most concerned with functional requirements.[13] The positions stated above seem to reflect a perspective: that rules are an implementation of functional requirements.[14] For example, that rules exist to clarify how to comply with requirements or how to behave when requirements are not satisfied (e.g., during a business process[15]).
In order to realize their marketing promise, BRMS need to advance to include direct support for functional requirements. Ideally, this support will eliminate the need to translate such requirements into rules. At a minimum it should support mapping back and forth between related rules and requirements, perhaps by supporting the OMG mappings between concepts like means (e.g., directives, including policies and rules) and ends (e.g., objectives), as in the Business Motivation Model.[16]
Supporting relationships between rules and requirements should not require relationships between them, however. Sometimes a policy may exist without a clear underlying requirement. Although theoretically, perhaps, there should be some underlying requirement for every rule, uncovering it may not be productive. Moreover, as discussed below, the distinction between rules and requirements is artificial in many cases.
When integrating rules and requirements into a single framework, care should be taken to support all the natural results of business analysis. In addition to rules and requirements, business analysts also uncover definitions of vocabulary and underlying concepts.
Vocabulary definitions are mostly ontological[17], such as mapping nouns onto taxonomic concepts or defining what it means when an adjective is used with a noun. This is why I designed Haley Systems’ Authority to manage such vocabulary and ontologies. Regrettably, the software did not yet eliminate the need to translate requirements into rules before it was acquired by Ruleburst. With it, Ruleburst is ahead of other vendors who do not manage ontologies and vocabularies explicitly, but there is still a problem.[18]
Current BRMS technology is not able to implement requirements directly. Current BRMS need a human to analyze a requirement and translate it into sometimes many rules that use the words “if” and “then” instead of words like “must” that are so common in requirements. This leads rule technologists to say things like, “a rule may reference a requirement” but “a requirement is not a rule”, as cited above.
One would think that OMG standards in rules could be supported by the BRMS vendors who contributed to them. Surprisingly, what SBVR[19]calls a rule is beyond the capabilities of current BRMS (as also discussed here). For example, most rules technologists would have trouble “coding” the SBVR rule: “each rental car always has exactly one vehicle identification number”. The rules technologist might say that this was a definition, not a rule or requirement.
Business analysts, such as those involved at OMG, are alienated by such discrimination.
And they are right to be alienated. What if a service request provides two VINs? Or zero? Does the statement change from a definition to a requirement or some rules?
Vendor support for requirements (or simply SBVR) rather than just rules involves – at a minimum – generating rules that invoke an exception mechanism when a requirement is violated (as also discussed here). Generating rules that avoid premature exceptions is a significant challenge, however, particularly when information may be missing (including when it is accumulated over time, such as across multiple submissions of web forms).
For example, given the requirement that “an ad on the back page of the New York Times Magazine must be full-page color”, it may be preferable to deduce the (permitted) color or size of a back page ad rather than indicate an exception if the size or color is unspecified. Today’s BRMS do not assist users with such rules nor do they relate them to such requirements. All such translations and any such mappings are strictly manual.
The looming battle in RMS involves the clarification and automated implementation of requirements and less codification of rules.
As you might surmise, I find this area presents some very interesting opportunity…
The line between requirements and rules needs to be clarified. Perhaps it needs to be erased. Consider that not every requirement must use the word “must”. During analysis, for example, a business concept might be similar to the concept of an orphan. A business analyst could capture this as any of “an orphan has no parents”, “a person without parents is an orphan”, “if a person has no parents then the person is an orphan”, “a person is an orphan if the person has no parents”, or “an orphan must have no parents”, among other alternatives. Some of these appear to be definitions, some requirements, and some rules. Yet they are all the same from the standpoint of stakeholders and less technical analysts.
Should software help clarify and unify such typical results of business analysis or should the burden be borne by humans in a waterfall process that distances natural expression of “requirements” from technical definitions and implementing “rules”?
Obviously, I believe the former.
In addition to previous recommendations to manage rules in a BRE-independent manner, I hope the following provides additional help in planning for the integration of requirements, definitions, and rules as the market evolves:
- Contemplate the extent to which your rule analysts are distinct from your requirements analysts and discern why if that difference is significant.
- Adopt methodologies that are consistent with best practices in requirements capture, analysis, and management rather than over-emphasizing rule-specific approaches.
- Understand where rule/requirement convergence and vendor independence is headed. Specifically consider SBVR (e.g., look at the video or document here). To a lesser degree consider PRR and semantic web activity.
- Consider managing rules and requirements outside a BRMS using requirements management software or as discussed here. Also consider the functionality of requirements management software (e.g., Rational) or BRMS that is not provided by an unassisted word processor or spreadsheet (e.g., as Ruleburst still presents here).
[1] i.e., any form of waterfall development (e.g., iterative or spiral) where implementation is required after rules or requirements are captured or modified
[2] Achieving ROI with Rational Requirements Management Tools
[3]Note that the limitations of BRMS discussed here are even worse for Complex Event Processing vendors since ease of authoring is much less advanced in the CEP market.
[4] Classification and Representation of Business Rules
[5] Methods for Managing Business Rules with Haley Authority
[6] A roadmap for the elicitation of business rules in information systems projects
[7] Elicitation Techniques for Processes, Rules, and Requirements
[8] The Unified Process Inception Phase: Best Practices in Implementing the UP (page 99 and here)
[9] Blinded by Requirements – Don’t Miss those Business Rules
[10] 1 MORE thing CIOs should know about requirements
[11] ISO 9126 re Functionality, Reliability, Usability, Efficiency, Maintainability, and Portability
[12] ISO 9126 plus Flexibility, Clarity, Resilience, Generality, Reusability and Economy
[13] Functional Requirements and Use Cases
[14] Requirements vs Process and Rules
[15] Requirements, business process and business rules
[16]OMG’s Business Motivation Model (BMM).
[17] as in the Web Ontology Language (OWL)
[18]Note that OWL and SBVR address some of these issues but not vocabulary. Ruleburst does not address the issues discussed here.
[19]OMG’s Semantics of Business Vocabulary and Rules (SBVR)>
One Reply to “When Rules Meet Requirements”
Comments are closed.