The Regenerate Web

Have you ever been part of a requirements process that stalled?  Sometimes this happens because the requester or delegate parties responsible for providing requirements were unable to provide complete sets of what ultimately would become the business rules that your solution would need to contemplate.  Perhaps it is because the policies are in the process of changing, and are not defined today.  Perhaps the request is dependent on other changes that are being made in related business processes which also are not finalized.  Perhaps it is because there are too many cooks in the kitchen.  At the end of the day, it just doesn't matter why, in order to complete the project, you have to have adequate requirements that intelligently contemplate the business rules.  

If features and functions are the soul of solution proposal, informing us of what will be delivered, business rules are the soul of detailed software requirements, informing us of how the features and functions will work.  They drive our ability to deliver work flow, data and process validation, integration, process risk mitigation, in general all of the key benefits of automation.   While it is certainly true that we cannot complete a software delivery project without contemplating detailed business rules, must the inability of the customer to deliver detailed business rules impede our ability to start design and construction of the software?  

To restate the question, can we design such that final business rules decisions can be deferred until some time during the construction process, without unnecessary risk of major obsolescence of the product?  Let's examine the reasons why we probably should design in this way to begin with, and see if we can't understand why this is a best practice, rather than a necessary evil.

Reasons for designing to defer requirements

1. Rules are malleable! - If policies, processes, or leadership is shifting on the customer side, what is the likelihood that it will continue to shift and change after our product is released?  We should remember that we are not dealing with the "immutable" laws of the physical universe.
2. Indecision is not uncommon! - If our customer changes his or her mind, why should it turn the project upside down?  If we know that the customer is having trouble reaching decisions around rules, we should build our plan to contemplate this problem.  While this might increase the cost of the project, we should clearly communicate this to our customer, because it will likely be a pattern that repeats in the customer enterprise.
3. Business means change! - Just because it is convenient for our idiom to fix (make them appear to be static) rules so that we can deliver software, business is constantly changing.  Regardless of the business your customer is in, or how stodgy or stagnant their business model is, the world around them is changing and they will need to adapt.  Markets, government regulations, technology, and staff turnover are all drivers of change into an organization.  If you think that your design doesn't need to contemplate change, then you are missing the point.  

Modeling change in requirements

Rather than reacting to changes in requirements, why can't we simply incorporate the need to contemplate change into the requirements.  Software engineers have devised design strategies like "data driven", and "object oriented" specifically to deal with this problem, yet we, as analysts, have not understood that we can leverage these strategies.  We continue to develop requirements as if we are part of a physical hardware, construction, engineering, project.  That is, we start with an assumption that when the project is completed, no change will happen.  We don't recognize that software can and does change with the business that we deploy it for.  We gather requirements casting phased delivery as static targets, rather than points along a continuum.  

I have heard in recent discussions about various approaches to making decisions about software design.  One approach that intrigued me involves taking out "options" to hedge against change.  In this approach "options" involve a more generalized design model that costs more to deliver, but will support a greater range of motion within the solution around a specific axis.  In requirements engineering, in order to enable the design team to contemplate these options, we need to deliver requirements that contemplate the possibility and probability of changes to the solution along specific axes within the problem space.  If the requirements cannot predict the probability of change, then the design cannot accommodate it.

What if when we were gathering requirements, we contemplated probable change within the business.  Of course we don't want to assume or predict what will happen, but we certainly know what might happen. If we required a software product to be designed to support a range of possibilities, we could allow the designers to model the change into the software, rather than merely reacting to it.  Of course, there is some cost to model software this way.  We could simply compare the cost of building to model changeability versus the cost of static design, plus subsequent reaction to changes.  This is definitely a pay me now or pay me later proposition, where the cost of pay me later can be ten times the cost of pay me now.

Business rules as a target for modeling change

Business rules provide a great opportunity to model change.  Business rules are fairly granular, that is they can reveal significant detail.  When final rules cannot be agreed upon, we can propose some interim or prototype rules, to express the underlying concepts that rules should be able to contemplate.  Typically systems use different "classes" of rules to solve different business problems, so a purpose-based rule taxonomy is a good starting point for rule modeling.  Each rule class can be modeled based on the data elements that must be contemplated to execute the rules.  Rule classes can also be modeled in terms of the range of "possible actions" that can be driven as the rules "fire".  If contemplated data and possible actions for a given rule class are not likely to change, even when the rules (specific conditions under which actions are fired) are allowed to change dramatically, then the final requirements can be deferred well into the construction phase of the software development process.  In fact, sample rules that test the contemplation of each data element and fire each of the actions can be developed, until the final rules are agreed.  

So how can we model change when the data contemplated by the rule class has a high probability of change?  In my experience, this is often driven by a need to acquire or cleanse data so that it is both available and suitable for contemplation by rules.  Sometimes, new business strategies place greater emphasis on different data elements.  I am asking you to model the business requirements - that is, it is not our job to design the solution, only to describe the problem - if the problem has strong future state probabilities where business rules would change then we should model that change in the requirements.

This would allow the solution proposal to include an option to hedge against that change.