Requirements and the Beast of Complexity

Part 2 – The solution

Elements of the solution

In order to address the weaknesses identified in Part 1, our solution to the requirements dilemma will need to make a few changes to the traditional requirements approach:

At first glance this might look like a prescription for an SDLC – it is not. The above activities will not:

• Produce an orchestrated set of processes.

• Interface to existing processes, people, or devices.

• Acquire and/or persist any artifact

These excluded outcomes are the key – they are the elements of traditional requirements that bind the requirements to both technology and platform. Because these are explicitly NOT present, we can deal with the requirements in a technology agnostic manner. In other words, these requirements represent purely business rather than systems intent. Of course, it also means that we cannot produce a complete system directly from the requirements that are defined in this manner.

In which case you might ask – is it worth doing? The answer is an emphatic yes! We will expand on the benefits shortly.

All requirements are equal, but some are more equal than others

Obviously businesses planning documents are not going to help us determine the preferred activities and sequence of some low level process, or the existence of fields on a screen, or the layout of a document, or any other of a myriad of low level details that often fall under the requirements umbrella.

But we can infer, if they are not already explicitly defined, the core value transformations that the business anticipates as part of its strategic intent. An insurance company will define what risks it wants to cover, what market segments it will solicit, what terms and conditions it will offer and at what price. This will be done at a business planning level, and it is not dependent on a systems development project (although it might give rise to one). Similarly, a hospital will determine what treatment specialties it will offer, with what levels of pre and post care, to what customer/patient types, and at what cost. In fact, all organizations are predicated on their own declared premise that they will act upon, and most importantly, add value to their target entities.

Given the fundamental nature of this assertion, we can say that capturing the details of how an organization proposes to add value to these core entities is the essence of its value proposition, and provided that this information is captured correctly, it is correct by definition. In fact, if we can capture this value proposition in a testable form then we might even be able to assist the business to clarify and confirm its strategic intent.

Furthermore, if we capture the value proposition using a pre-defined ‘idiom’ – in this case, a language that is locally defined by and for the business value proposition itself – and we are able to empirically test and prove the proposition, then we have produced an artifact that can underpin an SDLC without the cost of transformation.

So we have two levels of requirements in play:

• those that are business strategy driven, and which must by definition be addressed by any solution that is used by the business; and

• those that are solution specific and subservient to the strategic requirements, adding detail in the context of a specific solution but never altering the strategic intent.

In fact, we argue that these two types of requirements represent quite different concepts. The former arise from business planning independently of any IT driven SDLC, and the latter can be bundled into technical design phases within the SDLC as design detail. We will now refer to these as business requirements and design requirements respectively. Together they more or less replace the traditional project requirements phase, whose primary remaining task is to define the scope of any specific SDLC project. The design requirements we will now ignore – they cannot by definition validly change or conflict with the business requirements, and can be easily obtained within the downstream technical design phase through RAD or traditional development approaches.

Benefits of business requirements living outside of the SDLC

By focusing on the business requirements exclusively and independently of any SDLC as proposed, we can realize many benefits:

• Provide a living and persistent domain specific idiom that is business aligned and at the same time understandable by IT;

• Provide provably relevant business requirements to scope and de-risk all downstream effort, particularly systems development projects;

• Detaching business requirements from systems development projects allows for an independent existence and strategic continuity of the requirements – the business requirement does not change unless the business does (by definition), but the systems supporting that requirement may change with every new technology generation, and/or with multiple simultaneous deployment options and strategies;

• Reducing the size and increasing the business focus of the study area offers significant (and potentially exponential, given the network effect) reduction in cost, time, and risk for the equivalent analysis done as part of a larger systems project;

• Ensure the alignment of all downstream activities that derive from the business requirements.

In addition, the business itself can now use the business requirements phase to clarify, confirm, and prove the assumptions underlying the business intent.

Capturing the business requirements

The proposed approach implies a significant makeover of the traditional requirements process.

There is an existing link between the traditional view of requirements as outlined in Part 1 and the elements of a new requirements approach identified above – the concepts of business purpose and value. It is intuitively appealing to use these as a basis for a requirements approach makeover, and these shared fundamentals would also no doubt be reassuring to the business leadership – the alignment of systems with business strategy regularly features as a priority in executive polling. We will now describe a requirements process that derives directly from analysis of these business fundamentals.

We can identify two core elements needed for the proposed requirements approach:

• A description of the relevant subject entities using prescribed terms and a model of the relationships between the terms (to form the basis of the glossary); and

• A description of the activities that modify those terms in order to give effect to the business value proposition, and a model of the relationships between those activities.

We will refer to these two sets of descriptions/models as the Fact Model and the Decision Model respectively. Let’s look a bit closer at these terms and what they mean, as their usage within this approach may vary from traditional concepts.

The Fact Model (a term attributed to Tony Morgan[7] ) is a form of data model. Note that the while the Fact Model will eventually be a localized view of the domain model, it should NOT be simply extracted unquestioned from an existing domain model – it is important that the content and structure of the Fact Model be driven by the adjacent Decision Model requirements in the first instance. Of course the Fact Model must be derivable from the eventual implemented domain model otherwise the business cannot support its decisions by definition. But if it is developed as proposed in response to decision analysis then it can be used to either help derive a new domain model, or validate an existing domain model; whereas if it is extracted from the domain model on an assumption that the domain model is already correct (in which case, how was this assumption validated?), then this ability to drive domain model derivation or validation is compromised and we lose a major benefit of the proposed approach.

The Fact Model is in fact a transactional view of the required data, and any modeling technique used should acknowledge the need for a transactional context i.e. a root. For this reason the W3C Schema standard (.xsd) is a particularly suitable documentation standard and this article will assume that the Fact Model is represented by one or more XML schemas.

The Decision Model is likely to be a less familiar concept. This article proposes the term ‘decision’ to describe the activity component of the business requirement because a business activity that adds value to this business always involves some discretionary consideration by the business – this implies that a decision must be made. If a value change is not discretionary in any way then we are simply capturing the new value, and by definition, the value change is not derived from the business value proposition. For instance, capturing the change in price of a commodity is not discretionary and does not create new business value; whereas revaluing a portfolio or selling a quantity of the commodity because of the change in price is discretionary and creates value for the business. Of course non-discretionary or ‘decision-less’ activities may still be valid requirements, for instance regulatory or market practice requirements, but they represent cost rather than value creating activities of the organization and can be relegated to SDLC level analysis whenever a project addresses the relevant domain. In an ideal world, they might even be (software) commodities themselves.

While a range of standard methods exist for declaring decision logic, we must be careful that the method used meets the following ‘decision centric’ guidelines if it is to be useful to the proposed approach:

• The Decision Model must fully address the act of creating value as defined by the business, where value is defined as a forward looking change in the state of an entity that assists the business to achieve its objectives – there is no point in making half a decision!

• The Decision Model must interface directly to the Fact Model to deposit the results of the decisions made, and to acquire data as required by the decision logic.

• The Decision Model must only use the terms defined by the Fact Model in its descriptions.

• The structure of the Fact Model and the structure of the Decision Model must be in harmony with regards to transactional context.

• The Decision Model must be testable. If the validity of the Decision Model (and by inference the associated Fact Model) cannot be empirically demonstrated, then by definition it cannot be asserted to be a valid model of the business intent.

• A precisely defined and provably valid set of requirements as defined by the Fact and Decision Models must by definition be able to be transformed into computer code without human intervention – whether this actually occurs is less important, but it must be conceptually possible otherwise the requirements cannot be implemented and are invalid as presented.

The relationships between the various components of the approach are shown in Figure 2.

Figure 2.

Using Fact and Decision Models as proposed above to capture business requirements will allow us to harvest all of the benefits asserted in this article, including dramatic improvements in business and project outcomes. Part 3 will outline the actual approach for what we will now call Decision Centric Analysis.