Finding the Requirements Tree

Michael R. Wood is a Business Process Improvement & IT Strategist Independent Consultant. Michael is creator of the business process-improvement methodology called HELIX and founder of The Natural Intelligence Group, a strategy, process improvement, and technology consulting company. He is also a CPA, has served as an Adjunct Professor in Pepperdine's Management MBA program, an Associate Professor at California Lutheran University, and on the boards of numerous professional organizations. Mr. Wood is a sought after presenter of HELIX workshops and seminars in both the U.S. and Europe.

ADVERTISEMENT

Trending Articles

Portfolio Processes for Project Managers

by Kenneth Darter, PMP

Managing a portfolio can involve processes that are very different than project management processes. Project managers need to be prepared--understanding these three areas will lead to a better performing organization.

The World as a Project: How We Can Help Others Far Away

by Mike Donoghue

Not all Good Samaritan work requires our physical presence. Many groups also need our minds to help create proposals, share knowledge, come up with contribution and support ideas, and other tasks that extend help to communities and even nations. The online world has made this possible, and it is through its expansive reach that many more projects are and can be accomplished.

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.

Related Content

comments

Network:3



Excellent points about GAP analysis.The truth of the matter is inspite of all these wonderful tools,there will always be some gaps in collecting requirements. The users in many instances expect the developers to explain to them what they want instead of vice versa. This starts a vicious cycle that never ends.Here's where a good PM negotiates and convinces the users that what the project will deliver will be the best under the circumstances.

Network:9



Really Nice article about requirements. We do the GAP analysis based on functional requirement point of view, but won't quantify the GAP analysis in terms of frequency, defects, cost / revenue benefits, competitive advantage, customer service level improvement, etc that leads to misalignment of Business Objective. - Anurag

Network:5



Thank you for highlighting that requirements must be discovered, which jives with the title of my recent book, Discovering REAL Business Requirements for Software Project Success. The REAL, business requirements are _whats_ that exist within the business environment and therefore must be disvcovered. However, product/system/software/functional requirements/specifications are human-defined presumed ways _how_ to accomplish the presumed business requirements and therefore are specified not discovered. Confusing these two different types of requirements causes much of the creep that in turn causes projects to be late, overbudget, and not what is needed. --Robin Goldsmith, Go Pro Management, Inc.

ADVERTISEMENTS

If you can't convince them, confuse them.

- Harry Truman

ADVERTISEMENT

Sponsors