INCORPORATION OF JOINT APPLICATION DESIGN (JAD) IN SYSTEMS REQUIREMENT DETERMINATION

Sophia B. Kuchmistaya

MSIS 488: Information Systems Analysis
November 26, 2001

TABLE OF CONTENTS

  1. Abstract
  2. Introduction
  3. Traditional requirements elicitation techniques
  4. Joint Application Design (JAD)
  5. Additional benefits to the requirement identification process by incorporation of JAD
  6. Disadvantages of JAD
  7. Conclusion
  8. Alphabetical list of References by Author

Abstract

This paper discusses the importance of systems requirements and the advantages of using Joint Application Design (JAD), a modern requirements determination technique, in addition to traditional information gathering techniques like interviews and questionnaires. JAD, developed by IBM Corporation in late 1970's, is a requirements determination method that brings together business and IT professionals in a structured workshop in order to determine and discuss system requirements. Benefits received from adding JAD to currently used information gathering tools include savings on time and resources, and systems requirements written through cooperation of future users and IT development teams.

Back to Top

Introduction

Systems development process involves a number of stages: project identification and initiation, requirements identification and system analysis, design of the new system, installation and maintenance. Over the years of experience, it became clear that mistakes made in the beginning of the development life cycle, especially during the requirement identification stage, are the costliest (1). The systems requirements identification stage is one of the most important integral parts of the process, that can "make or break" the project. Results of reviewing industry statistics are there to prove it: "60% to 80% of errors originate in the user requirements and functional specification" stage (10).

In order to set requirements of the system that are beneficial to the organization, primary users of the system have to be involved. Therefore, good process of systems requirement identification involves elicitation of systems requirements from the people who will interact with the new system on the regular basis (11). That's where a problem of understanding comes in.

According to a Savant Institute study, 56% of errors occur because analysts that define systems requirements poorly communicate with the users of the system. Correction of these errors take up 82% of staff's time, making them the most expensive errors in systems development life cycle (6).

There are several reasons why the hardest thing for IT professionals is getting the information from various people involved and later systematizing all their desires into requirements:

In order to make this process easier, some traditional techniques for information gathering have been employed by IT professionals.

In this paper, these traditional techniques of information gathering will be compared against a more modern technique called Joint Application Design (JAD). JAD is best known in the market technique of system requirement determination through the team work of business users and IT system developers. Advantages and disadvantages of JAD will be examined in detail. Recommendation for the use of JAD versus the traditional information gathering techniques will be made.

Back to Top

Traditional requirements elicitation techniques

There are several techniques that are regularly used by system analysts for requirement collection. The most common techniques of requirement elicitation are interviews and questionnaires (1). These techniques allow IT professionals to get feedback on the processes of the organization as they are now, and get a sense of what is lacking in the current system.

For example, an interview with its one-on-one interaction helps IT professionals get answers to their questions. Good preparation for interviews with introduction questions leads interviewee to focus on the topic being discussed. Interviewer needs to prepare for the interaction, constructing at least core specifications that need to be addressed. Open-ended questions in interviews are the most effective, allowing the participant to elaborate on the point he/she is making and giving insight into his/her feeling about the problem. Therefore, interviews also give important emotional feedback to the interviewer. However, interviewing is a lengthy process and, therefore, costly.

The following disadvantages are evident:

A cheaper way to get feedback from users is a questionnaire. Questionnaires can reach a large number of users in a short period of time. They are easier to analyze than interviews, because they consist of multiple-choice and true and false questions created with an interpretation system in mind. They are not as time consuming as interviews are. However, questionnaires are not a panacea for requirement elicitation ailments due to the following reasons:

Therefore, these traditional information-gathering techniques need a counterpart or a substitute that will eliminate, at least in part, problems plaguing the analysis process. Joint Application Design (JAD) is a great addition to the usual requirement determination processes.

Back to Top

Joint Application Design (JAD)

The old saying - "Two heads are better than one"- gives a great basis for understanding on importance of group work. Teamwork makes one modern technique of systems requirement identification very successful (2). Joint Application Design (JAD) (developed by IBM in late 1970's) is a technique ensuring that information is gathered from all affected parties, and that requirements that are received in outcome are approved by all participants, and not only by decision of system analysts collecting the requirements (1, 18). JAD brings team approach into play gathering users from various departments and IT specialists together in 3-to-1 ratio for a structured work session (15). It allows users to share their opinions on the current system, and gives a chance through shared purpose to come to a consensus on what needs to be changed (19). In addition, JAD systematizes the systems requirement process, solving project managers dilemma of uniting disciplined approach to systems analysis with flexible user coordination (13).

Usually JAD workshops last for 3-5 days with several sessions, and require several key participants to be present (14):

During JAD workshop project owner introduces the problem to the participants. After the introduction, facilitator acquaints JAD members with schedule for workshop activities, and the discussion starts. During sessions facilitator sustains the flow of discussion, and scribe records all the pertinent information. Often premises where JAD session takes place are equipped with writing board, projectors and any other tools that can help participants to organize their thoughts. Valuable points of discussions are written out and displayed. This characteristic of JAD makes it easy, and very effective, to incorporate CASE tools into the process (14).

However, one of the key (and often overlooked) elements of JAD is pre-workshop preparation that needs to be done. During one to three weeks before workshop executive team and IS team must identify (10):

  1. Project and its objectives - what is the essence of the problem that development team and workshop participants are facing.
  2. Objectives of workshop and its deliverables - what are the points that should be clarified in the sessions? What results is project development team expecting to receive from JAD workshop?
  3. Participants that will be most beneficial to the project - people from what functional areas and from what level of professional ladder should be present to ensure versatility of JAD team.
  4. Tentative agenda of JAD sessions, and choose place, time, tools to be used. Without good preparation, without clear plan of action workshop can become a disorganized waste of resources.

Back to Top

Additional benefits to the requirement identification process by incorporation of JAD

The following compelling reasons exist for the incorporation of JAD into the requirement identification process:

Back to Top

Disadvantages of JAD

Systems analysts always have to keep in mind that none of techniques they use are a full-proof way to acquire the information, neither is JAD. Many proponents of modern systems analysis feel that JAD can be ineffective if not used correctly. They usually site several areas that need addressing before and during JAD sessions:

  1. "Do your homework". Without multifaceted preparation for JAD session valuable time of professionals can easily be wasted. Wrong problem can be addressed, wrong people can be invited to participate, inadequate resources for problem-solving can be used - all these scenarios can happen if organizers of the JAD session will not study the elements of the system being scrutinized (4).
  2. The team chosen to participate in JAD workshop should to include employees able to provide input on most, if not all, necessary parts of the problem. That's why particular attention should be paid during selecting participants. Group should consist not only of employees from various departments that will have interaction with the new system, but also from different places on the organizational ladder. This variety of thought process understanding will reflect different, sometimes even conflicting points of view, but will allow participants see a "different side of the coin". With better understanding of undercurrents of processes JAD will bring to light a better model outline (1).
  3. Facilitator as a smoothing and motivational force has to make sure that all participants, not only the most vocal ones, have a chance to offer their opinions, ideas, thoughts. All business experts on the JAD team should be encouraged to offer their input, making discussions more fruitful (14, 3).

Back to Top

Conclusion

Quality system requirements provide a foundation for success of any project. Good requirements should be verifiable and attainable, and to achieve this is impossible without user input (9, 11, 17). For many companies having traditional techniques like interviews and questionnaires in the arsenal of tools for systems gathering is beneficial. There are many times when these techniques are best ways to extract necessary information and develop systems requirements, especially in smaller scale projects (3). However, to use a cliché - "Time is money", therefore JAD as a rapid information-gathering technique, should be learned and used by systems analysis teams. JAD sessions offer organizations ability to get detailed information in a short period of time, which means it saves money and resources that could be used elsewhere. In ever-changing business environment organizations have to be prepared to make changes in their current processes to get and sustain competitive advantage, and any tool that can make organization more innovative, efficient, effective, should be used.

Back to Top

Alphabetical List of References by Author:

  1. Christel, M., Kang, K. "Issues in Requirements Elicitation". Carnegie Mellon Software Engineering Institute. http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.012.html
  2. Corbin, D. "Team Requirements Definition: Looking For A Mouse And Finding An Elephant". Journal of Systems Management, May 1991, Volume 42, Issue 5, Page 28.
  3. Dennis, A., Hayes, G., Daniel Jr., R. "Business Process Modeling With Group Support Systems". Journal of Management Information Systems, Spring 1999, Pages 115-142.
  4. Garner, Rochelle. "Why JAD Goes Bad". Computerworld, April 25, 1994. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO1472,00.html
  5. Gill, A. "Accelerated Design Techniques: Methods Without Madness". Best's Review - Life-Health Insurance Edition, March 1988, Volume 88, Issue 11, Page 88.
  6. Goodrich,V., Olfman, L. "An Experimental Evaluation Of Task And Methodology Variables For Requirements Definition Phase Success". Proceedings of the Twenty-Third Annual Hawaii International Conference on System Sciences, IEEE Computer Society, January 1990, Pages 201-209.
  7. Henderson, Lisa G. "Requirements Elicitation in Open-Source Programs". Industrial Engineering Department, Mississippi State University.http://www.stsc.hill.af.mil/crosstalk/2000/jul/henderson.asp
  8. Hooks, Ivy F. "Why Johnny Can't Write Requirements". AIAA conference, 1990. http://www.complianceautomation.com/papers/whyjohnny.htm
  9. Hooks, Ivy F. "Writing Good Requirements". Proceeding of the Third International Symposium of the INCOSE, Volume 2, 1993. http://www.complianceautomation.com/papers/writingreqs.htm
  10. Jennerich, Bill. "Joint Application Design: Business Requirements Analysis For Successful Re-Engineering". UNISPHERE, November 1990. http://www.bee.net/bluebird/jaddoc.htm
  11. Karat, John. "Evolving The Scope Of User-Centered Design". Communications of the ACM, July 1997, Volume 40, Issue 7, Page 33.
  12. Kataoka, N., Koizumi, H., Takasaki, K., Shiratori, N. "Remote Joint Application Design Process Using Package Software". Proceedings of the 13th International Conference on Information Networking (ICOIN '98), IEEE Computer Society, January 1998.
  13. Keen, Peter G. "Let's Put Project Management Out Of Its Misery". Computerworld, December 07, 1998. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO34677,00.html
  14. Liou, Y., Chen, M. "Integrating Group Support Systems, Joint Application Development, And Computer-Aided Software Engineering For Requirements Specification". IEEE, 1993, Pages 4-12.
  15. Matthews, Joy. "JAD To The Rescue". Computerworld, December 04, 1995. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO11544,00.html
  16. Miller, Ed. "The Teaming of IS and Engineering". Computer-Aided Engineering, October 2001, Volume 20, Issue 10, Page 68.
  17. Stedman, Craig. "Gathering Their Requirements Is Key. Computerworld, June 02, 1997. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO5418,00.html
  18. Soltys, R., Crawford, A. "JAD for Business Plans and Designs". The Facilitator.com, 1993. http://www.thefacilitator.com/htdocs/article11.html
  19. Ulrich, William M. "Getting System Specs Right For The 'E' Era". Computerworld, March 19, 2001. http://www.computerworld.com/storyba/0,4125,NAV47_STO58692,00.html
  20. Wood, Michael R. "A New Twist". CIO Magazine, September 1, 1995. http://www.cio.com/archive/090195/ins_content.html
Back to Top