A Requirements Determination Skills Deficit

A Requirements Determination Skills Deficit

According to a recent Gartner Group paper, "expertise in requirements gathering has declined as the use of JAD sessions fell out of favor in the late 1990s"¹. What caused this decline in the use of Joint Application Development (JAD)? This month we explore the possible causes and suggest why the time is right to bring the JAD approach back into common use.

The decline was caused by a combination of three factors. The first was the Y2K event that put new development on the shelf for two to four years. JAD sessions were not really applicable to the Y2K process because most of the requirements were definable by IT personnel and the need for interaction with the business community declined. Ergo, the exercise of JAD skills atrophied. The second was the "trimming" of the business community. Downsized business units no longer had the resources to devote the time needed for JAD sessions. The third factor was the pent-up demand for software development. The backlog that has existed since IT’s infancy was exacerbated by the necessity for focus on Y2K fixes.

Agile Outsourcing

"Outsourcing" evolved as a potential solution. A seemingly unlimited pool of external resources can be tasked with development work while the IT department keeps things running on the home front. Unfortunately, for outsourcing to be successful, the requirements have to be much more clearly and rigorously defined then ever before. The increase in clarity and rigor is necessary to ensure the quality and the timeliness of the deliverable. To solve this dilemma, some organizations decided to eliminate their IT department’s involvement and have the outsourcing company determine the requirements themselves. This capitulation of responsibility is the IT industry’s version of the "fox in the henhouse" fable.

Along came "Agile", an iterative and incremental development approach. Although very powerful, one of its weaknesses is that future, incremental releases can require a considerable amount of "refactoring" or rewriting of production code. This can only be avoided if the business requirements are clearly defined in the beginning of the project. If not, you are solving today’s problems by spending tomorrow’s resources.

The Current Reality

Both solutions fail without effective business system requirements and the only reliable source of these is an informed, empowered subject matter expert (SME). SMEs have to be involved early in getting the requirements as right as possible (note that that we did not say perfect or complete). The alternatives are to involve them more often in creating the system via iterations (acceptable but not efficient) or in maintenance and change requests on the fly (a proven road to failure).

The Now and Future JAD

To get the SME’s involved at the right time in our projects, we need to rebuild our requirements determination expertise and we need to make the most efficient use of the SMEs’ limited time. A JAR (Joint Application Requirements) is a JAD approach that focuses on business system requirements² . The key success factors in a JAR are the facilitation team’s command of a complete set of requirements determination methods combined with the ability to plan and facilitate short, directed, time boxed sessions. This is what we need to meet the conflicting demands placed on the business community and the IT resource.

Many organizations are realizing better business satisfaction with delivered information technology by recapturing the art and science of requirements determination. JAR sessions deliver the right requirements. Better business requirements early in the project create a richer, more comprehensive base to draw upon for the iterative process that is at the core of the Agile movement. Outsourcing can also be a very lucrative alternative if the right business system requirements are defined up front.

¹ Gartner # G00126310

² The JAR approach is described in great detail in our JAD white paper that can be downloaded at http://www.requirementssolutions.com/JADWhitePaperForm.html.

Note from the Editors

We had announced in the previous edition an article on "Automation for Testing the Language Used in Textual Requirements". We were evaluating a governmental tool that is available in the public domain for this purpose. Our initial evaluation, however, showed us that the complexity of the tool and its restrictive use precluded an article of any value at this time. As a result, we returned to a position we staunchly defend, the need for better business system requirements. We trust you will find this article just as informative and stimulating. We don’t know whether or not the article on testing textual requirements will ever be written, but if it does, you’ll see it here.

Dan Myers and Tom Hathaway
Managing Partners

Tom Hathaway and Dan Myers
Managing Partners

Future Feature: "The E-Volution of Requirements Training"