Modern Methods for Determining System Requirements
Modern Methods for Determining System Requirements
Even though we called interviews, questionnaires, observation, and document analysis traditional methods for determining a system’s requirements, all of these methods are still used by analysts to collect important information. Today, however, additional techniques are available to collect information about the current system, the organizational area requesting the new system, and what the new system should be like. In this section, you learn about two modern information-gathering techniques for analysis: joint application design (JAD) and prototyping. These techniques can support effective information collection and structuring while reducing the amount of time required for analysis.
Joint Application Design
You were introduced to joint application design or JAD, in Chapter 1. There you learned JAD started in the late 1970s at IBM as a means to bring together the key users, managers, and systems analysts involved in the analysis of a current system. Since the 1970s, JAD has spread throughout many companies and industries. For example, it is quite popular in the insurance industry. The primary purpose of using JAD in the analysis phase is to collect systems requirements simultaneously from the key people involved with the system. The result is an intense and structured, but highly effective, process. Having all the key people
TABLE 5-4: Comparison of Observation and Document Analysis
together in one place at one time allows analysts to see the areas of agreement and the areas of conflict. Meeting with all these important people for over a week of intense sessions allows you the opportunity to resolve conflicts or at least to understand why a conflict may not be simple to resolve. JAD sessions are usually conducted in a location away from where the people involved normally work, in order to limit distractions and help participants better concentrate on systems analysis. A JAD may last anywhere from four hours to an entire week and may consist of several sessions. A JAD employs thousands of dollars of corporate resources, the most expensive of which is the time of the people involved. Other expenses include the costs associated with flying people to a remote site and putting them up in hotels and feeding them for several days.
The following is a list of typical JAD participants:
- JAD session leader: The JAD leader organizes and runs the JAD. This person has been trained in group management and facilitation as well as in systems analysis. The JAD leader sets the agenda and sees that it is met. He or she remains neutral on issues and does not contribute ideas or opinions, but rather concentrates on keeping the group on the agenda, resolving conflicts and disagreements, and soliciting all ideas.
- Users: The key users of the system under consideration are vital participants in a JAD. They are the only ones who clearly understand what it means to use the system on a daily basis.
- Managers: Managers of the work groups who use the system in question provide insight into new organizational directions, motivations for and organizational impacts of systems, and support for requirements determined during the JAD.
- Sponsor: As a major undertaking, because of its expense, a JAD must be sponsored by someone at a relatively high level in the company such as a vice president or chief executive officer. If the sponsor attends any sessions, it is usually only at the beginning or the end.
- Systems analysts: Members of the systems analysis team attend the JAD, although their actual participation may be limited. Analysts are there to learn from users and managers, not to run or dominate the process.
- Scribe: The scribe takes notes during the JAD sessions, usually on a personal computer or laptop.
- IS staff: Besides systems analysts, other IS staff, such as programmers, database analysts, IS planners, and data-center personnel, may attend the session. Their purpose is to learn from the discussion and possibly to contribute their ideas on the technical feasibility of proposed ideas or on the technical limitations of current systems.
JAD sessions are usually held in special-purpose rooms where participants sit around horseshoe-shaped tables, as in Figure 5-6. These rooms are typically equipped with whiteboards (possibly electronic, with a printer to make copies of what is written on the board). Other audiovisual tools may be used, such as magnetic symbols that can be easily rearranged on a whiteboard, flip charts, and computer-generated displays. Flip-chart paper is typically used for keeping track of issues that cannot be resolved during the JAD, or for those issues requiring additional information that can be gathered during breaks in the proceedings. Computers may be used to create and display form or report designs or to diagram existing or replacement systems. In general, however, most JADs do not benefit much from computer support. The end result of a completed JAD is a set of documents that detail the workings of the current system and the features of a replacement system. Depending on the exact purpose of the JAD, analysts may gain detailed information on what is desired of the replacement system.
FIGURE 5-6 A typical room layout for a JAD session. Source: Based on Wood and Silver, 1989
Taking Part in a JAD Imagine that you are a systems analyst taking part in your first JAD. What might participating in a JAD be like? Typically, JADs are held off-site, in comfortable conference facilities. On the first morning of the JAD, you and your fellow analysts walk into a room that looks much like the one depicted in Figure 5-6. The JAD facilitator is already there. She is finishing writing the day’s agenda on a flip chart. The scribe is seated in a corner with a laptop, preparing to take notes on the day’s activities. Users and managers begin to enter in groups and seat themselves around the U-shaped table. You and the other analysts review your notes describing what you have learned so far about the information system you are all there to discuss. The session leader opens the meeting with a welcome and a brief rundown of the agenda. The first day will be devoted to a general overview of the current system and major problems associated with it.
The next two days will be devoted to an analysis of current system screens. The last two days will be devoted to analysis of reports. The session leader introduces the corporate sponsor, who talks about the organizational unit and current system related to the systems analysis study and the importance of upgrading the current system to meet changing business conditions. He leaves and the JAD session leader takes over. She yields the floor to the senior analyst, who begins a presentation on key problems with the system, which have already been identified. After the presentation, the session leader opens the discussion to the users and managers in the room.After a few minutes of talk, a heated discussion begins between two users from different corporate locations. One user, who represents the office that served as the model for the original systems design, argues that the system’s perceived lack of flexibility is really an asset, not a problem.
The other user, who represents an office that was part of another company before a merger, argues that the current system is so inflexible as to be virtually unusable. The session leader intervenes and tries to help the users isolate particular aspects of the system that may contribute to the system’s perceived lack of flexibility. Questions arise about the intent of the original developers. The session leader asks the analysis team about their impressions of the original system design. If these questions cannot be answered during this meeting because none of the original designers are present nor are the original design documents readily available, the session leader assigns the question about intent to the “to-do” list. This question becomes the first item on a flip-chart sheet of to-do items, and the session leader gives you the assignment of finding out about the intent of the original designers. She writes your name next to the to-do item on the list and continues with the session. Before the end of the JAD, you must get an answer to this question.The JAD will continue in this manner for its duration. Analysts will make presentations, help lead discussions of form and report design, answer questions from users and managers, and take notes on what is being said. After each meeting, the analysis team will meet, usually informally, to discuss what has occurred that day and to consolidate what they have learned. Users will continue to contribute during the meetings, and the session leader will facilitate, intervening in conflicts, seeing that the group follows the agenda. When the JAD is over, the session leader and her assistants must prepare a report that documents the findings in the JAD and then circulate it among users and analysts.
Using Prototyping during Requirements Determination
You were introduced to prototyping in Chapter 1 (see Figure 1-12 for an overview of prototyping). There you learned that prototyping is a repetitive process in which analysts and users build a rudimentary version of an information system based on user feedback. You also learned that prototyping could replace the systems development life cycle or augment it. In this section, we see how prototyping can augment the requirements determination process. To establish requirements for prototyping, you still have to interview users and collect documentation. Prototyping, however, allows you to quickly convert basic requirements into a working, though limited, version of the desired information system. The user then views and tests the prototype. Typically, seeing verbal descriptions of requirements converted into a physical system prompts the user to modify existing requirements and generate new ones. For example, in the initial interviews, a user might have said he wanted all relevant utility billing information on a single computer display form, such as the client’s name and address, the service record, and payment history. Once the same user sees how crowded and confusing such a design would be in the prototype, he might change his mind and instead ask for the information to be organized on several screens but with easy transitions from one screen to another. He might also be reminded of some important requirements (data, calculations, etc.) that had not surfaced during the initial interviews. You would then redesign the prototype to incorporate the suggested changes. Once modified, users would again view and test the prototype. Once again, you would incorporate their suggestions for change. Through such a repetitive process, the chances are good that you will be able to better capture a system’s requirements. The goal with using prototyping to support requirements determination is to develop concrete specifications for the ultimate system, not to build the ultimate system.
Prototyping is most useful for requirements determination when:
- User requirements are not clear or well understood, which is often the case for totally new systems or systems that support decision making.
- One or a few users and other stakeholders are involved with the system.
- Possible designs are complex and require concrete form to evaluate fully.
- Communication problems have existed in the past between users and analysts, and both parties want to be sure that system requirements are as specific as possible.
- Tools (such as form and report generators) and data are readily available to rapidly build working systems.
Prototyping also has some drawbacks as a tool for requirements determination. They include the following:
- A tendency to avoid creating formal documentation of system requirements, which can then make the system more difficult to develop into a fully working system.
- Prototypes can become idiosyncratic to the initial user and difficult to diffuse or adapt to other potential users.
- Prototypes are often built as stand-alone systems, thus ignoring issues of sharing data and interactions with other existing systems.
- Checks in the SDLC are bypassed so that some more subtle, but still important, system requirements might be forgotten (e.g., security, some data-entry controls, or standardization of data across systems).