Finding the Requirements Tree

Michael Wood

October 17, 2006

In 1981, ComputerWorld published my in-depth article called “System Design--A Model Based Approach”. In that article, I suggested that there was a missing phase to the traditional System Development Life Cycle (SDLC): requirements discovery. Today, over 30 years later as I talk with IT executives and business application developers, the No. 1 issue they seem to struggle with most is how to divine requirements from users. The lament is always the same

“How can users provide requirements when they don’t know what they want?”

Perhaps it’s a matter of approach and tools that exasperate them in their elusive quest to find the requirements tree and to harvest its bounty.

The good news is that the industry is plentiful with requirements discovery tools. The bad news is that many are steeped in complex syntax, unwieldy models, strange jargon and obtuse tools that make the discovery process difficult, frustrating and painful.

The secret to rapidly capturing requirements lays in understanding the business processes that the application is suppose to leverage and support. It requires a fast and easy-to-understand set of tools and techniques that can be used with cross-functional workgroups to identify process defects, process improvement opportunities, map out existing workflows and conceptualize alternative workflows against which improvement concepts can be validated. The goal of the discovery process is to create the models and framework needed to:

Identify Value Gaps -- Misalignments between the business objectives and the outcomes each business process produces down to the procedure level
Identify & Model Workflows and Phases -- Maps of every core workflow both existing and proposed
Correlate Value Gap to Workflow Intersections -- Map value gaps to existing workflows and value improvement opportunities to proposed workflows validating solution alignment
Identify & Define IPOs -- Every input, process and output (IPOs) needed to support the improved business process
Identify & Define Object Transformations -- Every explicit and implicit transformation of data objects for each IPO (down to the logical data table level)
Identify & Define Action Triggers -- Every trigger that sparks people and systems to take action
Identify & Define Process Failures -- Potential process failures and remedies (prevention, advance warning and rapid detection & resolution)
Identify & Model Natural Data Model -- The underlying “Natural” data model needed to support and reflect the nature of the business (independent of current policies and practices).

In essence, the Requirements Discovery Phase yields a macro level specification that drives the rest of the development lifecycle. By modeling the business first the underlying business application requirements are revealed.

Armed with this knowledge, the application development team can quickly develop the following:

Business Case with Change Concepts and ROI for each deliverable
Statement of Work documents
Phasing & Release Strategies
Package Evaluation Requirements for assessing buy vs. build decisions
Requirements and Design specifications that can be mapped, tested and validated against the macro level specifications developed during the discovery process.
When done correctly the discovery process also yields the following benefits:
Identification of all critical stakeholders
Stakeholder and user buy-in to the improvements defined\user ownership of the solution
Projects that are alignment with business goals and strategies
More complete and resilient scope
Criteria for the development of business performance scorecards
Measurable criteria for determining that can be achieved by the initiative

There are a plethora of workshops, books and even university level courses dedicated to requirements discovery. Well-known frameworks and methods like Six Sigma, The Helix Methodology, Volere, RUP (Rationale Unified Process) and RapidTrak have been around for years, some dating back to the late 1970s. Yet it has only been in the last few years, since the arrival of Business Process Improvement and Management, that discovery has become recognized as the single most critical factor in delivering aligned IT value in the workplace.

Even SOA exalts the need to map out core business processes as a starting point in any SOA initiative. To the informed reader, there can be little doubt that the Requirements Tree of Knowledge has its roots established in modeling the cross-functional business processes in context to business strategies and goals of the enterprise. It is in the gap between how things work today and how they need to work to achieve core business objectives that the fruit of the requirements tree can be harvested.

However, with an abundance of methods ranging from the pragmatic to the theoretical comes confusion wrapped in a murky mud of hype and hyperbole. Which methods work best? Which methods are field tested and proven? Which modeling tools work best? Which techniques yield the fastest, quickest and best results? The questions become endless, and for good reason. Consider the following list of diagramming techniques that all purport to do map workflow processes:

Data Flow Diagrams
Swim Lane Charts
State Diagrams
Workflow Diagrams
Traditional Flow Charts
Cross Functional Flow Charts
Value Stream Maps
ITIL Diagrams
TQM Diagrams
UML Model Diagrams

…and the list goes on.

Is there any wonder why application developers are confused, frustrated and capitulate to old and outdated approaches? Add the need to be expert in facilitation techniques, data modeling, failure analysis, SIPOC, DMAIC, DMADV, GAP Analysis, etc. and in terms like artifacts, actors, closed-loop systems and triggers, and the mud gets thick and deep fast.

As in the evolution of any body of knowledge, each inventor of a method creates their own language, models and syntax to describe it. Over time a common language emerges, standards are set and universality is achieved. But until that time we only have principles, track records and consistency of outcomes achieved as evaluation tools. We therefore must become students of the subject in order to insure that what we adopt as our company’s standard is appropriate.

The eight key outcomes presented earlier can be used to assist you in evaluating requirements discovery methods and tools. A quality tool set (models, forms, techniques, etc.) should deliver the eight key outcomes needed for a complete requirements discovery solution. If your approach falls short, then it should be either augmented or replaced. Let’s take a closer look at each of these outcomes.

Identify Value Gaps
In context to discovering information system requirements, a GAP Analysis identifies areas within a current business process where improvements can be made. This is done by contrasting the current situation (or state) of components of a process to more preferred “future” state (or goal).

Wikipedia defines a GAP Analysis as:

“A business assessment tool enabling a company to compare its actual performance with its potential performance. This provides the company with insight to areas which have room for improvement. The process involves determining, documenting and approving the variance between business requirements and current capabilities. Gap analysis naturally flows from benchmarking or other assessments.”

The secrets to a good GAP Analysis are as follows:

Create a context for the GAP Analysis by framing it within the confines of achieving specific, operationally measurable business goals and objectives.
Collect the initial GAP data via the facilitating of cross-functional focus groups (knowledgeable representatives from each organization involved in performing the business process in question).
Quantify each current and future state in terms of frequency, defects, cost / revenue benefits, competitive advantage, customer service level improvement, etc.
Evaluate each future state’s feasibility in terms of controllable vs. uncontrollable variables, imposed organizational constraints and windows of opportunity.

When a GAP Analysis is collected interactively in cross-functional work sessions, the outcome is a consensus on what changes need to be made to current business processes and practices in order to move the enterprise closer to achieving its business goals and objectives.

In Part 2 of this two-part series, we will look at the rest of the key outcomes.

The URL for this article is:
https://www.projectmanagement.com/articles/233550/finding-the-requirements-tree