JAR/JAD: Rejuvenation of a Requirements Capturing Concept?

Where Are We Coming From?

Way back in the 1980’s (for those of you old enough to remember that far back in time), we in the Information Technology industry spent a lot of time working out new and improved methods for helping the business community discover their needs. One of the extremely successful and powerful concepts was called JAD for “Joint Application Development” (alternatively, “Joint Application Design”), an approach developed and trademarked by a small, unknown organization named IBM.

The primary concept of a JAD session was to get a cross-functional team consisting of subject matter experts and analysts/designers/developers (depending on the focus of the session) locked into a room together with a facilitator (or, even better, facilitation team) that led the group to victory, as in the delivery of a sound, well-developed requirements definition document (a.k.a. RDD, just to throw another acronym into the soup).

The Pending Problem

In those days, JAD sessions were so successful and so popular (in some circles) that many within the IT community decided that this was finally the silver bullet for flushing out and capturing requirements. As a result, the number of JADs (and, obviously, a JAD by any other name smells the same) expanded exponentially until there were more JADs than there were suitable projects. The unfortunate result was a lot of poorly conceived, planned or executed sessions that not only failed to deliver on their promise but, eventually, ruined JAD’s good reputation and led to sessions that no one from the business side of the projects attended.

At the same time that JADs were becoming unpopular due to focusing too strongly on the technology, another minor factor called “Y2K” (for those of you young enough to remember that phase in your development) had a significant impact on the number of business development projects undertaken. Since “Y2K” was very limited in focus and ate up all of the IT departments’ resources, little time was left for gathering requirements for other projects, whether JAD was an option or not.

Reality As We Know It

In recent years, the IT industry has awakened from the doldrums of mediocrity in requirements gathering techniques and a new concept called “JAR” has emerged. As near as I can tell, JAR stands for Joint Applications Requirements Capturing (spoken with a silent “Capturing”). Two other terms that have surfaced are “JRP – Joint Requirements Planning” and “JADr (pronounced “jadder”) as in JAD for (r)equirements. Conceptually, JAR, JRP, and JADr use JAD concepts but focused strictly on business and stakeholder requirements.

“OK,” I can hear you think, “So just what is this ‘JAR/JRP/JADr’ thing and why should I care?” I’m so glad you asked or I would have nothing left to finish this post.

Common activities of a JAR/JRP/JADr session include understanding the AS IS situation, identifying current business problems, analyzing their causes, determining benefits and capturing the business requirements and/or business rules. These early project activities are often neglected in an effort to “save time”. Based on our experience (and studies too numerous to list), the time saved by skipping these activities usually leads to expensive rework or customer rejection once the system is delivered. The focus on the early project activities enables IT to deliver a quality business solution upon completion of the project.

What Else Do You Need?

There are a wide range of tools and techniques that are especially effective in a JAR/JRP/JADr setting, e.g. Business Problem Definition and Reduction, Business Process and Data Modeling, Project Scoping Techniques, Cost/Benefit Analysis, Requirements Capture, User Story Definition, Requirements Clarification, and Requirements Confirmation.

Many of the most demanding techniques related to a JAR/JRP/JADr session are those that have to do with the session itself, from figuring out whether to do one for your project to the logistics of the session and on to successful follow-up activities once the session is over. If you decide that JAR/JRP/JADr is a viable approach for your organization, we recommend finding someone who has walked that rocky road before you and can help you avoid the pitfalls we have uncovered along the way. And, before you ask, yes we can help.

Share this:

Tom has been in business analysis since long before it was called business analysis. He has over 30 years experience in the fields of information technology, methodologies, and business analysis. In his writings and lectures he strives for enlightening while entertaining. As a facilitator, he achieves results through inclusion and synergistic group-building. He has taught thousands of students business and systems analysis skills since the '80's and has facilitated hundreds of requirements discovery sessions under a variety of acronyms (JAD, ASAP, JADr, JRP, etc.).

2 Responses to “JAR/JAD: Rejuvenation of a Requirements Capturing Concept?”

I am planing to design an application for a simple medical test available from the Java
mb. phones.
Please let me know whether jar and/or jad concept should be used.
If both or one only can be used, then will the every type of Java phone accept such application
concept and how the user can find out which concept can be accepted by his phone.
I am not the IT specialist, please excuse my basic questions.

Thank you for your question. The terms JAR/JAD are basically interchangeable. The focus is on the requirements for an IT solution (e.g., app). You might use a JAR/JAD if you have a group of people who need to reach consensus on a set of requirements defining what the app should do.