Systems Requirements and JAD
Sophia B. Kuchmistaya
MSIS 488: Information Systems Analysis
November 26, 2001
TABLE OF CONTENTS
- Traditional requirements elicitation techniques
- Joint Application Design (JAD)
- Additional benefits to the requirement identification process by incorporation of JAD
- Disadvantages of JAD
- Alphabetical list of References by Author
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
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.
- Users come from the different departments of the organization, from different professional levels. They bring different agendas for what the system should be able to do (17).
- It is hard to find time for requirement elicitation from many users.
- User requirements collected are not complete or not understood by analysts (8).
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
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:
- It is hard to set convenient time for interviews with all the people able to provide insight into the problem.
- Usually many follow-ups are necessary for clarification, making the process more expensive.
- Not as many people from various parts of the company are interviewed, because of cost, so there exists high possibility for bias.
- Quality information can be gathered provided good questions in correct manner are asked. However, there is no standard procedure to make interviews more effective (1).
- Even with structuring interview questions, analysts have to do a lot of guesswork when choosing aspects most beneficial for business needs of the organization (1).
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:
- It is hard to create questionnaires that will give all possible answer options customer wants to give (7).
- There is always a high risk of question ambiguity.
- Access to emotional feedback is impossible, unless follow-up interviews are scheduled, subsequently adding to the cost.
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
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):
- Executive Sponsor - owner of the systems that is being discussed. Very often it is a person in a managerial position able to clear schedules for participants of the JAD session or resolve conflicts between participants (10, 14). He/she helps during preparation (homework) stage of JAD and introduces the problem before the group in the beginning of the session (10).
- Members of IT team that will be working on the project, mainly systems analysts, but possibly programmers, database administrators, etc.
- Business Users - people who have expertise of business operations. Users should be represented in two types: employees that will use the system in their day-to-day operations, and employees who are "responsible for standards and methodology for business functions they represent" (16, 11, 10). During JAD session users contribute their views on current processes and on what will have to be changed.
- All the information received during the discussion is recorded by a scribe. He/she is responsible for keeping track of all the activities that are going on in the session, making sure to record issues to be worked on, decisions made, and results of discussions.
- And finally, a facilitator - a person who runs the machine of requirement gathering process. It is facilitator's goal to direct and sustain discussion, make sure that goals of the session are achieved. "Good facilitators listen, recognize issues as they arise, and provide leadership and direction to help people come together" (10).
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):
Back to Top
- Project and its objectives - what is the essence of the problem that development team and workshop participants are facing.
- 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?
- 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.
- 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.
The following compelling reasons exist for the incorporation of JAD into the requirement identification process:
Back to Top
- JAD decreases time and costs associated with requirements elicitation process (14). During 2-4 weeks information not only is collected, but requirements, agreed upon by various system users, are identified. Experience with JAD allows companies to customize their systems analysis process into even more dynamic one like Helix, a methodology for mission-critical work (20).
- JAD sessions help bring experts together giving them a chance to share their views, understand views of others, and develop the sense of project ownership (3).
- The techniques of JAD implementation are well known, as it is "the first accelerated design technique available on the market and probably best known" (5), and can easily be applied by any organization.
- Easy integration of CASE tools into JAD workshops improves session productivity and provides systems analysts with discussed and ready to use models.
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:
Back to Top
- "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).
- 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).
- 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).
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
Back to Top
- 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
- 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.
- Dennis, A., Hayes, G., Daniel Jr., R. "Business Process Modeling With Group Support Systems". Journal of Management Information Systems, Spring 1999, Pages 115-142.
- Garner, Rochelle. "Why JAD Goes Bad". Computerworld, April 25, 1994. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO1472,00.html
- Gill, A. "Accelerated Design Techniques: Methods Without Madness". Best's Review - Life-Health Insurance Edition, March 1988, Volume 88, Issue 11, Page 88.
- 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.
- 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
- Hooks, Ivy F. "Why Johnny Can't Write Requirements". AIAA conference, 1990. http://www.complianceautomation.com/papers/whyjohnny.htm
- 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
- Jennerich, Bill. "Joint Application Design: Business Requirements Analysis For Successful Re-Engineering". UNISPHERE, November 1990. http://www.bee.net/bluebird/jaddoc.htm
- Karat, John. "Evolving The Scope Of User-Centered Design". Communications of the ACM, July 1997, Volume 40, Issue 7, Page 33.
- 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.
- 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
- Liou, Y., Chen, M. "Integrating Group Support Systems, Joint Application Development, And Computer-Aided Software Engineering For Requirements Specification". IEEE, 1993, Pages 4-12.
- Matthews, Joy. "JAD To The Rescue". Computerworld, December 04, 1995. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO11544,00.html
- Miller, Ed. "The Teaming of IS and Engineering". Computer-Aided Engineering, October 2001, Volume 20, Issue 10, Page 68.
- Stedman, Craig. "Gathering Their Requirements Is Key. Computerworld, June 02, 1997. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO5418,00.html
- Soltys, R., Crawford, A. "JAD for Business Plans and Designs". The Facilitator.com, 1993. http://www.thefacilitator.com/htdocs/article11.html
- 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
- Wood, Michael R. "A New Twist". CIO Magazine, September 1, 1995. http://www.cio.com/archive/090195/ins_content.html