Brown-Field Requirements
One view of requirements engineering is that its purpose is to produce a complete and coherent statement of what some system-of-systems is required to do – in other words, its behaviour in the broadest sense, including “functional”, “non-functional” and “commercial” requirements.
In a “Green-Field” scenario, we might imagine that this statement of requirements would result in the procurement and installation of a system of systems meeting the stated requirement. Requirements engineering is focused on understanding exactly what is required, and specifying it in an unambiguous and testable form.
But in almost all engineering projects, some system of systems – technical or sociotechnical – already exists, and the practical purpose is to make some planned changes to it. So people in the RE community are starting to talk more about “Brown-Field” requirements.
(RESG Event: Managing Brownfield Project Requirements, London, October 12th 2010)
Gap Analysis
An obvious starting point for brownfield requirements analysis would seem to be the identification of a gap between desire and reality. People often produce two models – an AS-IS model that describes the existing system, and a TO-BE model that describes its future replacement. The engineering requirements are then derived from the differences between the AS-IS model and the TO-BE model. This will typically result in a solution, possibly involving rebuilding some of the subsystems, replacing or upgrading some of the component parts, adding some new stuff or stripping out old stuff, rewiring the network, retraining the people, resetting system policies and parameters, and so on. In addition to a solution blueprint, showing how all these elements are to be configured, there will also be a transition strategy, indicating how (and in what sequence) all these changes will be installed. There are usually operational constraints – for example, a requirement to keep critical business processes running at an acceptable level during the transition period.
Imagine you want to rebuild your kitchen. You have to think about fitting new units into the existing space, or possibly moving a wall to give yourself more space. You have to decide whether you are going to keep the existing fridge (which you only bought last year) or buy a new one. And you have to think about how long you can manage without being able to cook. Moving the wall, or deciding to keep the old fridge, belong to the solution domain. But if you are going to do requirements analysis properly, there needs to be something in the statement of requirements that helps you determine these aspects of the solution.
In all but the smallest and most simple projects, there will be many solution variants. The decision to retain or replace a particular component may be based on a technical calculation of its likely performance and capacity within the new configuration, or may be based on a political calculation as to the most convenient budget from which to fund the replacement (in other words, preferably someone else’s budget, if we can get away with not replacing it now).
Ten years ago this month, I wrote a piece about this in relation to Component-Based Software Engineering. Supply and Fit (CBDI Journal, September 2000).
But there is a more fundamental reason why there are many possible solutions – because making sustainable changes to complex systems is a tough challenge. Large and complicated change programmes aren’t always the most effective; a small intelligent fix is often far better (and less risky) than any amount of optimistic meddle.
So before we can get to a solution blueprint and a transition strategy, we need an intervention strategy. This takes us out of the comfort zone of requirements engineering into general systems thinking.
Leverage Points
Donella Meadows identified twelve leverage points for making changes in complex systems, and suggested that these could be ranked according to their power. See original paper by Donella Meadows. A version is included in her posthumously published book Thinking in Systems (2008).
If the intervention strategy can be expressed as a combination of leverage points, then this raises the question for requirements engineering – how do we work through the requirements of changing a complex adaptive system in a way that could produce this kind of intervention strategy?
Zero Based Procurement
Finally, I wanted to make a comment about one of the (many) dysfunctional aspects of prevailing procurement practices. In his blogpost Was this NHS IT tender a stitch-up? (Computer World, September 2010), Tony Collins talks about the difficulties of referencing a specific product or system in a tender document. “If a user organisation has a system it’s happy with, and wants to keep and enhance, why would it want to go through the needless expense of an EC tendering, rather than simply renew the contract?”
Procurement rules may have been designed to prevent cosy and uncompetitive relationships between public sector organizations and their suppliers. They appear to have the effect of forcing each procurement to be treated as a separate exercise, starting each time from a blank sheet of paper, so that there is at least the theoretical possibility of giving new suppliers a chance. (This is similar to the principle of Zero-Based Budgeting.) Many people doubt that these mechanisms actually have any real effect on competition or value-for-money; but meanwhile, these mechanisms appear to have a strongly negative impact on through-life capability management. How can brownfield requirements engineering be done properly under these constraints?
BizTalk
BizTalk Server 2009
biztalk
biztalk server 2010
