|
|
Abstract There are several traditional methods of requirements elicitation and business rule capture utilized by organizations when embarking on systems development projects. Although many technical based requirements can be determined through research of available technology, standards organizations, or existing systems, most functional requirements and business processes can only be learned through interaction with the intended end users of the system under development. Surveys, interviews and questionnaires can be effective, but are often time consuming methods of requirements gathering, and often miss the big picture. Using these methods often do not allow for group discussion, consensus and validation of requirements. In recent years, a more common approach is the use of Joint Application Design (JAD). The JAD method allows for collaboration of a pre-selected population of end users, managers, and analysts with the intent of reaching an accurate and timely consensus on system requirements and business rules. This paper will focus on both advantages and pitfalls of using JAD for software development projects, and provide case studies and recommendations. The overall findings conclude that JAD is an efficient, necessary method of requirements elicitation for most systems projects. Table of Contents Introduction 4 Discussion 7 JAD Session Participants 7 Preparing for JAD Sessions 11 Conducting JAD Sessions 13 Post JAD Session Activities 16 Case Study – The Boeing Company 16 Lessons Learned 20 Conclusion 21 References 23 Joint Application Design for Requirements Elicitation Introduction One of the traditional approaches to the requirements phase for systems projects is to assemble a systems analysis team responsible for conducting individual or small group interviews, and create, distribute and interpret questionnaires and surveys. Depending on the magnitude of the project, this often involves time and cost consuming travel to acquire input from the right people. Once the interview phase is complete, the analysis team typically reassembles to hash out the various user viewpoints, and coordinate back and forth with individual users to resolve perceived discrepancies. In the next step, the analysts produce a systems requirements document, usually consisting of various “shall” statements gathered during the interview process. In my experience as a systems analyst, it is not uncommon for these initial documents to be readily accepted by the end users, only to discover significant flaws down the line. A common downfall with the traditional methodology described above often occurs during the system design phase. Analysts are rarely given enough time to learn the user’s functions adequately enough to accomplish their task. After the requirements document has been accepted, analysts will often design what they believe is the user’s overall perception of the system, with little or no collaboration with them. Analysts will often use their own creativity to develop screen layouts, various reports, and processing. However, when the system design document is released, the analysis team is often faced with the rude awakening that they have not produced what the end users really want. When this occurs, projects often fall behind schedule, and the entire requirements elicitation process needs to be revisited, often with grueling, rushed, closed-door meetings with users in an attempt to recover and get it right. In contrast, Joint Application Design allows the appropriate setting to gather all key players together early in the process, and on a continual basis as necessary. There may be more time up-front needed for training and preparation of JAD sessions, which will be discussed in detail in a subsequent section, but the end result usually pays off by allowing the analysts to design the system right the first time. JAD is defined as “a process whereby highly structured group meetings or miniretreats involving system users, system owners, and analysts occur in a single room for an extended time” (Whitten, 1998, p. 663). It is a method of collaboration among system users, technical staff, managers, and systems analysts that can be useful throughout several phases of the systems development lifecycle. Originally developed by IBM in 1977, it has gone through several iterations, and currently applies across industry, application, and hardware boundaries (August, 1991). The overall intent of JAD sessions is to accomplish the front-end tasks of the systems development lifecycle. These include defining objectives, obtaining detailed system requirements, and external design (screens, data elements, reports, processing). The sessions also provide an appropriate forum to document system business rules. A business rule is defined as an established practice of an organization indirectly related to particular functions of the system. For example, a user of a medical information system attempting to log into a patient’s medical record may be denied access if an incorrect password is entered more than two times consecutively. Initially, this paper will focus on the methods for selecting the appropriate mix of participants for JAD sessions based on subject area and objectives. This involves the determination of the number of technical and functional domain experts and the role of the systems analysts and support staff. An in-depth discussion of facilitation support, techniques and qualifications will also be included. Next, the paper will focus on planning and conducting JAD sessions. This will include orientation of the analysis staff, preparing draft analysis products for JAD session discussion points, logistics considerations, orientation of end users (otherwise known as subject matter experts), the use of CASE tools, and wrap-up procedures. Throughout this discussion, examples of real-world JAD experiences will be incorporated to point out success stories and lessons learned. The paper will also provide discussion on the team-building aspects of JAD, and how established customer-based workgroups facilitate consensus and ownership of requirements. This discussion will lead directly to the advantages of JAD for the more advanced stages of the systems development lifecycle. Requirements are a moving target, and naturally evolve over time. An established workgroup can help the systems analyst manage these requirements as systems projects move into the design phase. Additionally, the JAD members can provide ongoing validation of analysis and design products as they evolve throughout the systems development lifecycle. Another section of this paper provides a case study of how the Boeing Company used the JAD philosophy during the development of the 777 aircraft in the 1990s. Although this example is a slightly different twist on the JAD methodology, the techniques used by the organization are of relevance. Finally, the paper will summarize the advantages and pitfalls of using JAD, and provide guidelines for deciding when to incorporate JAD as a method of requirements elicitation. The summary will also include detailed recommendations for using JAD, and how this methodology can be most effective throughout multiple phases of project analysis and design. Discussion JAD Session Participants Critical to the success of JAD sessions is the appropriate selection of participants. This section provides an explanation of the types of people who should be included, and what roles they play. Included are the project sponsor, users and managers, systems analysts, scribes, observers, and a facilitator. During the initial conception and proposal stages of system projects, there are usually one or more participants who stand out as sponsors, or chief proponents. If the project is internal to an organization, the sponsor is likely a high level manager. If the organization is acting on a consultant basis, then the sponsor is likely a high ranking client representative. These individuals are often directly responsible for approval of the project, releasing the necessary funding, and have a stake in its success. The sponsor is also the primary decision-maker in terms of project direction, and delegating lower level issues to other project team members for resolution. In addition, the sponsor is accountable to appointing the appropriate end users to participate in project JAD sessions. According to Jeffrey L. Whitten in Systems Analysis and Design Methods, “The role of the sponsor is to give full support to the systems project by encouraging designated users to willingly and actively participate in the JAD session(s)” (Whitten, 1998, p. 663). It is also a common practice for the project sponsor to kick off JAD sessions by presenting an overview of the project. In my experience, I have found that these opening remarks can have a crucial role in the success of the JAD session.
|
