Analysis Phase of Textbook - PDF

The Analysis Phase 83 structure of a textbook requires that these topics are presented sequentially, in practice, the systems analyst uses all of the tools and techniques discussed in Chapters 3 through 6 through- out the analysis phase to define, clarify, and...

The Analysis Phase 83 structure of a textbook requires that these topics are presented sequentially, in practice, the systems analyst uses all of the tools and techniques discussed in Chapters 3 through 6 through- out the analysis phase to define, clarify, and document the requirements for the new system. THE ANALYSIS PHASE The analysis phase is so named because the term analysis refers to breaking a whole into its parts with the intent of understanding the parts’ nature, function, and interrelationships. In the context of the SDLC, the outputs of the planning phase (the system request, feasibility study, and project plan), outline the business goals for the new system, define the project’s scope, assess project feasibility, and provide the initial work plan. These planning phase deliverables are the key inputs into the analysis phase. In the analysis phase, the systems analyst works extensively with the business users of the new system to understand their needs from the new system. The basic process of analysis involves three steps: Understand the existing situation (the as-is system). Identify improvements. Define requirements for the new system (the to-be system). Sometimes the first step (i.e., understanding the as-is system) is skipped or done in a limited manner. This happens when no current system exists, if the existing system and processes are irrelevant to the future system, or if the project team is using a RAD or agile development methodology in which the as-is system is not emphasized. Traditional methods such as water- fall and parallel development (see Chapter 2) typically allot significant time to understanding the as-is system and identifying improvements before moving to capture requirements for the to-be system. Newer RAD and agile methodologies, such as iterative development, system prototyping, throwaway prototyping, and extreme programming (see Chapter 2), focus almost exclusively on improvements and the to-be system requirements, and they devote little time for investigating the current as-is system. Experience shows that it is useful to study the current situation whenever possible. The insights gained from reviewing the existing system can be quite valuable to the project team. To move the users “from here to there,” an analyst needs strong critical thinking skills. Critical thinking is the ability to recognize strengths and weaknesses and recast an idea in an improved form. These skills are needed in order for the analyst to understand issues and develop new and improved business processes that are supported by information system technologies. These skills are essential in examining the results of requirements discovery and translating those requirements into a concept for the new system. As an example, let us say that a user states that the new system should “eliminate inventory stock-outs.” While this might be a worthy project goal, the analyst needs to think about it criti- cally in order to formulate the statement in terms of useful requirements. The analyst could first have the users think about circumstances leading to stock-outs (e.g., supplier orders are not placed in a timely way), and then describe the actual business practices that lead to these cir- cumstances (e.g., on-hand inventory levels are updated only once a week; delays occur in iden- tifying the best supply source for the items; delays occur in receiving approval of the supply order, etc.). By focusing on correcting these issues, the team is in a better position to develop new business processes that address these concerns. The new requirements will then be based on the issues that truly need to be fixed. In this case, the requirements might include, in part: The system shall update on-hand inventory levels twice per day. The system shall produce an out-of-stock notification immediately when an item quantity on hand reaches the item reorder point. 84 C ha pt er 3 Requirements Determination The system shall include a recommended supplier with every out-of-stock notification. The system shall produce a supply purchase order that is sent to the appropriate manager for approval. The system shall send an approved supply purchase order to the supplier via secure electronic communication. As this example demonstrates, it is unrealistic to expect the true requirements to be deliv- ered on a silver platter during a few conversations with the business users. The analyst must be prepared to dig into the situation and discover requirements. This is rarely an easy process. A number of techniques and tools can be used by the analyst to facilitate this process of discovering requirements. In this chapter, we will describe those techniques and tools so that you can learn how to use them during the analysis phase. We will also explain the critical role that requirements play in defining the new system. As mentioned above, the analyst also employs additional tools during this phase to clarify and document the to-be system concept. These tools are the subject of complete chapters: use cases (Chapter 4), process models (Chapter 5), and data models (Chapter 6). The final deliverable of the analysis phase is the system proposal, a document compiling the detailed requirements definition statement, use cases, process model, and data model together with a revised feasibility analysis and work plan. At the conclusion of the analysis phase, the system proposal is presented to the approval committee, usually in the form of a system walk-through. The goal of the walk-through is to explain the system in moderate detail so that the users, managers, and key decision makers clearly understand it, can identify any needed modifications, and are able to make a decision about whether the project should con- tinue. Before moving into the design phase, the project’s business value should be reviewed to ensure it remains positive. If approved, the system proposal components (requirements defini- tion, use cases, process model, and data model) are used as inputs to the steps in the design phase, which further refine them and define in much more detail how the system will be built. The line between the analysis and design phases is very blurry, because the deliverables created in the analysis phase are really the first step in the design of the new system. Many of the major design decisions for the new system are found in the analysis deliverables. In fact, a better name for the analysis phase would really be “analysis and initial design,” but because this name is rather long and because most organizations simply call this phase “analysis,” we will, too. Nonetheless, it is important to remember that the deliverables from the analysis phase are really the first step in the design of the new system. In many ways, determining requirements is the single most critical aspect of the entire SDLC. Although many factors contribute to the failure of systems development projects, fail- ing to determine the correct requirements is a primary cause.1 A 2008 study of Fortune 500 company software projects found just 37% of survey respondents felt the project met users’ needs.2 Therefore, analysts should devote considerable attention to the work performed in the analysis phase. It is here that the major elements of the system first begin to emerge. If the requirements are later found to be incorrect or incomplete, significant rework may be needed, adding substantial time and cost to the project. During requirements determination, the to-be system concept is easy to change because little work has been done yet. As the system moves through the subsequent SDLC phases (design and implementation), it becomes harder and harder to return to require- ments determination and make major changes because of all of the rework that is involved. This is why the iterative approaches of many RAD and agile methodologies are 1For example, see Kweku Ewusi-Mensah, Software Development Failures: Anatomy of Failed Projects, MIT Press, 2003. 2Janet Mullaney, “Requirements gathering resources, practices lacking at Fortune 500 companies,” SearchSoftware Quality.com, Aug. 20, 2008.  Requirements Determination 85 so effective—small batches of requirements can be identified and implemented in incre- mental stages, allowing the overall system to change and evolve over time. Also, method- ologies such as the V-model stress that tests for the system should be defined at the same time that the requirements are being defined. That way, testing is not just a last-minute, thrown-together process, but instead is based directly on the requirements of the system as they are being defined. REQUIREMENTS DETERMINATION Requirements determination is performed to transform the system request’s high-level state- ment of business requirements into a more detailed, precise list of what the new system must do to provide the needed value to the business. This detailed list of requirements is supported, confirmed, and clarified by the other activities of the analysis phase: creating use cases and building process and data models. We first explain what a requirement is and discuss the process of creating a requirements definition statement. What Is a Requirement? A requirement is simply a statement of what the system must do or what characteristics it needs to have. During a systems development project, requirements are created that provide different perspectives. For example, we may describe what the business needs (business requirements); what the users need to do (user requirements); what the software should do (functional require- ments); characteristics the system should have (nonfunctional requirements); and how the system should be built (system requirements). Although this list of requirement categories may seem intimidating at first, the categories merely reflect the purpose of the requirements and the stage in the SDLC in which they are defined. We have already discussed the creation of the systems request in the planning phase of the SDLC. In the system request, there are statements that describe the reasons for proposing the systems development project. These statements reflect the business require- ments that this system, if built, will fulfill. These business requirements help define the overall goals of the system and help clarify the contributions it will make to the organiza- tion’s success. Examples of business requirements include: “Provide product search capa- bilities,” “Produce performance reports”, “Provide accurate project status reports,” and “Provide account access to mobile customers.” When the systems development project is complete, success will be measured by evaluating whether the stated business require- ments have actually been achieved; therefore, they provide the overall direction for the project. During the analysis phase, requirements are written from the perspective of the business, and they focus on what the system needs to do in order to satisfy business user needs. A good starting place is to concentrate on what the user actually needs to accomplish with the system in order to fulfill a needed job or task. These user requirements describe tasks that the users perform as an integral part of the business’ operations, such as: “Schedule a client appoint- ment”; “Place a new customer order”; “Re-order inventory”; “Determine available credit”; and “Reconcile supplier shipment.” Use cases (discussed in Chapter 4) are tools used to clarify the steps involved in performing these user tasks. By understanding what the user needs to do to complete a task, the analyst can then determine ways in which the new system can support the users’ needs. The system’s functional requirements evolve from understanding how the new system can support user needs. A functional requirement relates directly to a process the system should perform as a part of supporting a user task and/or information it should provide as the user 86 C ha pt er 3 Requirements Determination YO U R 3-1 Identifying Requirements T UR N One of the most common mistakes made by new ana- 7. have 2-second maximum response time for prede- lysts is to confuse functional and nonfunctional require- fined queries and 10-minute maximum response ments. Pretend that you received the following list of time for ad hoc queries. requirements for a sales system: 8. include information from all company subsidiaries. Requirements for the proposed system: 9. print subsidiary reports in the primary language of The system should... the subsidiary. 1. be accessible to Web users. 10. provide monthly rankings of salesperson performance. 2. include the company standard logo and color scheme. Questions 3. restrict access to profitability information. 1. Which requirements are functional business 4. include actual and budgeted cost information. requirements? Provide two additional examples. 5. provide management reports. 2. Which requirements are nonfunctional business 6. include sales information that is updated at least requirements? What kind of nonfunctional require- daily. ments are they? Provide two additional examples. is performing a task. The International Institute of Business Analysis (IIBA) defines functional requirements as “the product capabilities, or things that a product must do for its users.”3 Functional requirements begin to define how the system will support the user in completing a task. For example, assume the user requirement is “Schedule a client appointment.” The func- tional requirements associated with that task include: “Find available openings matching client availability,” “Select desired appointment,” “Record appointment,” and “Confirm appointment.” Notice how these functional requirements expand upon the user’s task to describe capabilities and functions that the system will need to include, allowing the user to complete the task. As the analyst works with the business users of the system to discover user and functional requirements, the user may reveal processes that will be needed or information that will be needed. For example, as shown in Figure 3-1, the user may state “The system must retain cus- tomer order history for 3 years” (an information need). The analyst should probe for the rea- soning behind this statement, such as “The system should allow registered customers to review their own order history for the past 3 years” (a process need). Similarly, the user may state “The Functional Requirement Description Examples Process-oriented A process the system must perform; The system must allow registered customers to review their own order a process the system must do history for the past 3 years. The system must check incoming customer orders for inventory availability. The system should allow students to view a course schedule while registering for classes. Information-oriented Information the system must contain The system must retain customer order history for 3 years. The system must include real-time inventory levels at all warehouses. The system must include budgeted and actual sales and expense amounts for the current year and 3 previous years. FIGURE 3-1 Functional Requirements 3 International Institute of Business Analysis, Guide to Business Analysis Body of Knowledge® (BABOK®), 2nd ed.  Requirements Determination 87 system should check incoming customer orders for inventory availability” (a process need). An alert analyst will recognize the related information need, “The system should maintain real- time inventory levels at all warehouses.” All of these requirements are necessary to fully under- stand the system that is being developed. Process models (Chapter 5) are used to explain the relationship of functions/processes to the system users, how the functions/processes relate to each other, how data is entered and produced by functions/processes, and how functions/processes create and use stored data. Process models help clarify the software components that will be needed to accomplish the functional requirements. In addition, the information-oriented functional requirements begin to define the data that must be kept track of in order to accomplish the user tasks. The data component of the system is defined in the data model (Chapter 6). User, functional, and nonfunctional requirements identified in the analysis phase will flow into the design phase, where they evolve to become more technical, describing how the system will be implemented. Requirements in the design phase reflect the developer’s perspective, and they usually are called system requirements. These requirements focus on describing how to create the software product that will be produced from the project. More will be said about system requirements in Part 3 of the textbook. Before we continue, we want to stress that it can be difficult to draw a black-and-white dividing line between these requirement categories. To add to the confusion, some compa- nies use the terms interchangeably and do not distinguish between the types of requirements at all. The important thing to remember is that a requirement is a statement of what the system must do. The focus of requirements changes over time as the project moves from planning to analysis to design to implementation. Requirements evolve from broad overall goal statements to detailed statements of the business capabilities that a system should pro- vide to detailed technical statements of the way in which the capabilities will be implemented in the new system. The final category of requirements is nonfunctional requirements. The IIBA defines this group of requirements as “the quality attributes, design, and implementation constraints, and external interfaces which a product must have.”4 Although the term “nonfunctional” is not very descriptive, this requirement category includes important behavioral properties that the system must have. For example, the ability to access the system through a mobile device would be considered a nonfunctional requirement. Nonfunctional requirements take center stage in the design phase when decisions are made about the user interface, the hardware and software, and the system’s underlying architecture. (We will revisit them in Chapter 8.) Many of these requirements will be discovered during interactions with users in the analysis phase, however, and should be recorded as they are identified. Figure 3-2 lists different kinds of nonfunctional requirements and examples of each kind. Notice that the nonfunctional requirements describe a variety of system characteristics: operational, performance, security, and cultural and political. These characteristics do not describe business processes or information, but they are very important in understanding what the final system should be like. For example, the project team needs to know whether a system must be highly secure, requires sub-second response time, or has to reach a multilin- gual customer base. The goal at this point is to identify any major issues. In addition, if the methodology in use includes developing test plans during analysis, then these requirements will be important in establishing testing benchmarks that will be needed later. The Process of Determining Requirements Both business and IT perspectives are needed to determine requirements during the analysis phase. Systems analysts may not understand the true business needs of the users, while the 4 Ibid. 88 C ha pt er 3 Requirements Determination Nonfunctional Requirement Description Examples Operational The physical and technical environments The system will run on Andriod mobile devices. in which the system will operate The system should be able to integrate with the existing inventory system. The system should be compatible with any Web browser. Performance The speed, capacity, and reliability of Any interaction between the user and the system should not the system exceed 2 seconds. The system downloads new status parameters within 5 min- utes of a change. The system should be available for use 24 hours per day, 365 days per year. The system supports 300 simultaneous users from 9–11 a.m.; 150 simultaneous users at all other times. Security Who has authorized access to the system Only direct managers can see staff personnel records. under what circumstances Technicians can see only their own work assignments. The system includes all available safeguards from viruses, worms, Trojan horses, etc. Cultural and Political Cultural and political factors and legal The system should be able to distinguish between US cur- requirements that affect the system rency and currency from other nations. Company policy is to buy computers only from Dell. Country managers are permitted to authorize custom user interfaces within their units. Personal information is protected in compliance with the Data Protection Act. Source: The Atlantic Systems Guild, www.systemsguild.com FIGURE 3-2 Nonfunctional Requirements business users may not be aware of promising new technologies. Therefore, the most effective approach is to have both businesspeople and analysts working together to determine require- ments. In fact, the analysis phase involves significant interactions with people who have an interest in the new system (often called stakeholders). One of the first tasks for the analyst is to identify the primary sources of requirements, including the project sponsor, project CONCEPTS 3-A What Can Happen if You Ignore Nonfunctional Requirements IN ACTION I once worked on a consulting project in which my man- The technology they had in place was antiquated, but ager created a requirements definition without listing non- nonetheless they wanted the system to run effectively on functional requirements. The project was then estimated the existing equipment. Because we did not set the pro- based on the requirements definition and sold to the client ject scope properly by including our assumptions about for $5,000. In my manager’s mind, the system that we nonfunctional requirements in the requirements defini- would build for the client would be a very simple stand- tion, we basically had to do whatever they wanted. alone system running on current technology. It should not The capabilities they wanted took weeks to design take more than a week to analyze, design, and build. and program. The project ended up taking 4 months, and Unfortunately, the client had other ideas. They the final project cost was $250,000. Our company had to wanted the system to be used by many people in three pick up the tab for everything except the agreed upon different departments, and they wanted the ability for $5,000. This was by far the most frustrating project situa- any number of people to work on the system concurrently. tion I ever experienced. Barbara Wixom  Requirements Determination 89 champion(s), all users of the system (both direct and indirect), and possibly others. It is important that all user perspectives are included. The analyst must also consider how best to elicit the requirements from the stakeholders. There are a variety of elicitation techniques that can be used to acquire information, including interviews, questionnaires, observation, joint application development (JAD, as it is more com- monly known), and document analysis. We will discuss these techniques in the next section. The information gathered by these techniques is critically analyzed and used to craft the requirements definition statement. The analyst works with the entire project team and the business users to verify, change, and complete the list of requirements and, if necessary, to prioritize the importance of the requirements that are identified. During this process, use cases, process models, and data models may be used to clarify and define the ideas for the new system. This process continues throughout the analysis phase, and the requirements definition evolves over time as new requirements are identified and as the project moves into later phases of the SDLC. Beware: the evolution of the requirements definition must be carefully managed. Keep- ing the requirements list tight and focused is a key to project success. The project team cannot keep adding new items to the requirements definition or the system will keep growing and growing and never gets finished. Instead, the project team carefully identifies requirements and evaluates which ones fit within the system scope. When a requirement reflects a real business need, but is not within the scope of the current system or current release, it should be evaluated in terms of its importance and impact on time and budget. It may be that the requirement is essential enough to add to the current project, along with appropriate adjustments to the project budget and time frame. We should expect that the requirements may change. However, sometimes requirements are deferred or given a low priority. The management of requirements (and system scope) is one of the hardest parts of managing a project! The Requirements Definition Statement The requirements definition statement—usually just called the requirements definition—is a straightforward text report that simply lists the functional and nonfunctional requirements in an outline format. Figure 3-3 shows a sample requirements definition for Holiday Travel Vehi- cles, a fictitious recreational vehicle dealership. As shown in Figure 3-3, requirements are typically identified by numbering. Assigning unique numbers enables each requirement to be tracked through the entire development pro- cess. For clarity, the requirements are typically grouped into functional and nonfunctional groupings. Then, within each of those groups, they are classified further by the type of require- ment or by business area. Sometimes, requirements are prioritized on the requirements definition statement. They can be ranked as having “high,” “medium,” or “low” importance in the new system, or they can be labeled with the version of the system that will address the requirement (e.g., release 1, release 2, release 3). This practice is particularly important with RAD methodologies that deliver requirements in batches by developing incremental versions of the system. The most obvious purpose of the requirements definition is to provide a clear statement of what the new system should do in order to achieve the system vision described in the sys- tem request. The use cases, process models, and data models provide additional explanatory content in different formats. A critically important purpose of the requirements definition, however, is to define the scope of the system. The document describes to the analysts exactly what the final system needs to do. In addition, it serves to establish the users’ expectations for the system. If and when discrepancies or misunderstandings arise, the document serves as a resource for clarification. 90 C ha pt er 3 Requirements Determination Functional Requirements 1. New Vehicle Management 1.1 The system will allow managers to view the current new vehicle inventory. 1.2 The system will allow the new vehicle manager to place orders for new vehicles. 1.3 The system will record the addition of new vehicles to inventory when they are received from the manufacturers. 2. Vehicle Sales Management 2.1 The system will enable salespersons to create a customer offer. 2.2 The system will allow salespeople to know whether an offer is pending on a specific vehicle. 2.3 The system will enable managers to record approval of a customer offer. 2.4 The system will prepare a sales contract. 2.5 The system will prepare a shop work order based on customer requested dealer options. 2.6 The system will record a customer deposit. 2.7 The system will record a customer payment. 2.8 The system will create a record of the customer’s vehicle purchase. 3. Used Vehicle Management 3.1 The system will record information on a customer trade-in vehicle... etc. Nonfunctional Requirements 1. Operational 1.1 The system should run on tablet devices to be used by salespeople. 1.2 The system should interface with the shop management system. 1.3 The system should connect to printers wirelessly. 2. Performance 2.1 The system should support a sales staff of 15 salespeople. 2.2 The system should be updated with pending offers on vehicles every 5 minutes. 3. Security 3.1 No salesperson can access any other salesperson’s customer contacts. 3.2 Only the owner and sales manager may approve customer offers. 3.3 Use of each tablet device should be restricted to the salesperson to whom it is assigned. 4. Cultural and Political 4.1 Company policy says that all computer equipment is purchased from Dell. 4.2 Customer personal information is protected in compliance with the Data Protection Act. 4.3 The system will conform to the state’s “lemon law.” FIGURE 3-3 Sample Requirements Definition REQUIREMENTS ELICITATION TECHNIQUES An analyst is very much like a detective (and business users sometimes are like elusive sus- pects). He or she knows that there is a problem to be solved and therefore must look for clues that uncover the solution. Unfortunately, the clues are not always obvious (and often are missed), so the analyst needs to notice details, talk with witnesses, and follow leads, just as  Requirements Elicitation Techniques 91 Sherlock Holmes would have done. The best analysts will thoroughly search for requirements using a variety of techniques and make sure that the current business processes and the needs for the new system are well understood before moving into design. You do not want to dis- cover later that you have key requirements wrong—surprises like this late in the SDLC can cause all kinds of problems. Requirements Elicitation in Practice Before discussing the five requirements elicitation techniques in detail, a few practical tips are in order. First, the analyst should recognize that important side effects of the requirements definition process include building political support for the project and establishing trust and rapport between the project team and the ultimate users of the system. Every contact and interaction between the analyst and a potential business user or manager is an opportunity to generate interest, enthusiasm, and commitment to the project. Therefore, the analyst should be prepared to make good use of these opportunities as they arise during the require- ments definition process. Second, the analyst should carefully determine who is included in the requirements defi- nition process. The choice to include (or exclude) someone is significant; involving someone in the process implies that the analyst views that person as an important resource and values his or her opinions. You must include all of the key stakeholders (the people who can affect the system or who will be affected by the system). This might include managers, employees, staff members, and even some customers and suppliers. Also, be sensitive to the fact that some people may have significant influence within the organization even if they do not rank high in the formal organizational hierarchy. If you do not involve a key person, that individual may feel slighted, causing problems during implementation (e.g., saying “I could have told them this might happen, but they didn’t ask me!”). Finally, do everything possible to respect the time commitment that you are asking the participants to make. The best way to do this is to be fully prepared and to make good use of all the types of requirements elicitation techniques. Although, as we will see, interviewing is the most commonly used technique, other indirect methods may help the analyst develop a basic understanding of the business domain so that the direct techniques are more productive. In general, a useful strategy for the analyst to employ is to begin requirements gathering by interviewing senior managers to gain an understanding of the project and get the “big picture.” These preliminary interviews can then be followed by document analysis and, possibly, obser- vation of business processes to learn more about the business domain, the vocabulary, and the as-is system. More interviews may then follow to collect the rest of the information needed to understand the as-is system. In our experience, identifying improvements is most commonly done through JAD ses- sions because these sessions enable the analysts, users, and other key stakeholders to work together and create a shared understanding of the possibilities for the to-be system. Occa- sionally, these JAD sessions are followed by questionnaires sent to a much larger group of users or potential users to get a broad range of opinions. The concept for the to-be system is frequently developed through interviews with senior managers, followed by JAD sessions with users of all levels, to make sure that the key requirements of the new system are well understood. In this section, we focus on the five most commonly used requirements elicitation tech- niques: interviews, JAD sessions, questionnaires, document analysis, and observation. Interviews The interview is the most commonly used requirements elicitation technique. After all, it is natural—usually, if you need to know something, you ask someone. In general, interviews are 92 C ha pt er 3 Requirements Determination conducted one on one (one interviewer and one interviewee), but sometimes, due to time constraints, several people are interviewed at the same time. There are five basic steps to the interview process: selecting interviewees, designing interview questions, preparing for the interview, conducting the interview, and postinterview follow-up.5 Selecting Interviewees An interview schedule should be created, listing who will be inter- viewed, the purpose of the interview, and where and when it will take place (Figure 3-4). The people who appear on the interview schedule are selected on the basis of the analyst’s infor- mation needs. The project sponsor, key business users, and other members of the project team can help the analyst find the best candidates to provide important information about requirements. People at different levels of the organization will have different viewpoints on the busi- ness area. It is important to include both managers who oversee the processes and staff who actually perform the processes to gain both high-level and low-level perspectives. Also, the kinds of interview subjects that you need may change over time. For example, at the start of the project the analyst has a limited understanding of the as-is business process. It is common to begin by interviewing one or two senior managers to get a strategic view and then move to mid-level managers who can provide broad, overarching information about the business pro- cess and the expected role of the system being developed. Once the analyst has a good under- standing of the big picture, lower-level managers and staff members can fill in the exact details of how the process works. Like most other things about systems analysis, this is an iterative process—starting with senior managers, moving to mid-level managers, then staff members, back to mid-level managers, and so on, depending upon what information is needed along the way. It is quite common for the list of interviewees to grow, often by 50–75%. As you interview people, you likely will identify more information that is needed and additional people who can provide the information. Designing Interview Questions Typically, interviews include: closed-ended questions, open-ended questions, and probing questions. Closed-ended questions require a specific answer. You can think of them as being similar to multiple choice or arithmetic questions on Purpose of Name Position Interview Meeting Andria McClellan Director, Accounting Strategic vision for new Mon, March 1 accounting system 8:00–10:00 a.m. Jennifer Draper Manager, Accounts Current problems with Mon, March 1 Receivable accounts receivable 2:00–3:15 p.m. process; future goals Mark Goodin Manager, Accounts Current problems with Mon, March 1 Payable accounts payable process; 4:00–5:15 p.m. future goals Anne Asher Supervisor, Data Entry Accounts receivable and Wed, March 3 payable processes 10:00–11:00 a.m. FIGURE 3-4 Fernando Merce Data Entry Clerk Accounts receivable and Wed, March 3 Sample Interview payable processes 1:00–3:00 p.m. Schedule 5A good book on interviewing is Brian James, The Systems Analysis Interview, Manchester: NCC Blackwell, 1989.  Requirements Elicitation Techniques 93 CONCEPTS 3-B Selecting the Wrong People IN ACTION In 1990, I led a consulting team for a major develop- under construction. These individuals were the first and ment project for the US Army. The goal was to replace second line managers of the business function. The eight existing systems used on virtually every Army individuals were experts at managing the process, but base across the United States. The as-is process and did not know the exact details of how the process data models for these systems had been built, and our worked. The resulting to-be process model was very job was to identify improvement opportunities and general and nonspecific. Alan Dennis develop to-be process models for each of the eight systems. Question For the first system, we selected a group of mid- level managers (captains and majors) recommended by Suppose you were in charge of the project. Create an their commanders as being the experts in the system interview schedule for the remaining seven projects. an exam (Figure 3-5). Closed-ended questions are used when the analyst is looking for specific, precise information (e.g., how many credit card requests are received per day). In general, precise questions are best. For example, rather than asking “Do you handle a lot of requests?” it is better to ask “How many requests do you process per day?” Closed-ended questions enable analysts to control the interview and obtain the infor- mation they need. However, these types of questions do not uncover why the answer is the way it is, nor do they uncover information that the interviewer does not think to ask ahead of time. Open-ended questions seek a more wide-ranging response from the interviewee. They are similar in many ways to essay questions that you might find on an exam (see Figure 3-5 for examples). Open-ended questions are designed to gather rich information and give the inter- viewee more control over the information that is revealed during the interview. Sometimes the subjects the interviewee chooses to discuss uncover information that is just as important as the answer (e.g., if the interviewee talks only about other departments when asked about problems, it may suggest that he or she is reluctant to admit his or her own department’s problems). Types of Questions Examples Closed-Ended Questions How many telephone orders are received per day? How do customers place orders? What information is missing from the monthly sales report? Open-Ended Questions What do you think about the way invoices are currently processed? What are some of the problems you face on a daily basis? What are some of the improvements you would like to see in the way invoices are processed? Probing Questions Why? FIGURE 3-5 Can you give me an example? Three Types of Can you explain that in a bit more detail? Questions 94 C ha pt er 3 Requirements Determination Probing questions follow up on what has just been discussed in order for the interviewer to learn more. They encourage the interviewee to expand on or to confirm information from a previous response, and they are a signal that the interviewer is listening and interested in the topic under discussion. Many beginning analysts avoid probing questions because they are afraid that the interviewee might be offended at being challenged or because they believe it shows that they did not understand what the interviewee said. When done politely, probing questions can be a powerful tool in requirements discovery. In general, you should not ask questions about information that is readily available from other sources. For example, rather than asking what information is used to perform to a task, it is more effective to show the interviewee a form or report (see document analysis later) and ask what information on it is used. This helps focus the interviewee on the task and saves time, because he or she does not need to describe the information in detail—he or she just needs to point it out on the form or report. Your interview questions should anticipate the type of information the interviewee is likely to know. Managers are often somewhat removed from the details of daily business processes and so might be unable to answer questions about them, whereas lower-level staff members could readily respond. Conversely, lower-level employees may not be able to answer broad, policy-oriented questions, while managers could. Since no one wants to appear ignorant, avoid confounding your interviewees with questions outside their areas of knowledge. No type of question is better than another, and usually a combination of questions is used during an interview. At the initial stage of an IS development project the as-is process can be unclear, so the interview process begins with unstructured interviews, interviews that seek a broad and roughly defined set of information. In this case, the interviewer has a general sense of the information needed, but few closed-ended questions to ask. These are the most chal- lenging interviews to conduct because they require the interviewer to ask open-ended ques- tions and probe for important information “on the fly.” As the project progresses, the analyst comes to understand the business process much better, and he or she needs very specific information about how business processes are per- formed (e.g., exactly how a customer credit request is approved). At this time, the analyst conducts structured interviews in which specific sets of questions are developed prior to the interviews. There usually are more closed-ended questions in a structured interview than in the unstructured approach. No matter what kind of interview is being conducted, interview questions must be organized into a logical sequence so that the interview flows well. For example, when trying to gather information about the current business process, the analyst will find it useful to move in logical order through the process or from the most important issues to the least important. There are two fundamental approaches to organizing the interview questions: top-down or bottom-up; see Figure 3-6. With the top-down interview, the interviewer starts with broad, general issues and gradually works towards more specific ones. With the bottom-up interview, the interviewer starts with very specific questions and moves to broad questions. In practice, analysts mix the two approaches, starting with broad general issues, moving to specific ques- tions, and then back to general issues. The top-down approach is an appropriate strategy for most interviews. (It is certainly the most common approach.) The top-down approach enables the interviewee to become accus- tomed to the topic before he or she needs to provide specifics. It also enables the interviewer to understand the issues before moving to the details, because the interviewer may not have sufficient information at the start of the interview to ask very specific questions. Perhaps most importantly, the top-down approach enables the interviewee to raise a set of big-picture issues before becoming enmeshed in details, so the interviewer is less likely to miss important issues.  Requirements Elicitation Techniques 95 own Top-D How High-level: very general can order processing be improved? Medium-level: moderately How can we specific reduce the number of times that customers return items they’ve ordered? Low-level: very specific How can we reduce the number of errors in order processing (e.g., shipping the wrong products)? FIGURE 3-6 p Top-Down and m-U Bottom-Up Question- Botto ing Strategies One case in which the bottom-up strategy may be preferred is when the analyst already has gathered a lot of information about issues and just needs to fill in some holes with details. Or, bottom-up may be appropriate if lower-level staff members feel threatened or are unable to answer high-level questions. For example, “How can we improve customer service?” may be too broad a question for a customer service clerk, whereas a specific ques- tion is readily answerable (e.g., “How can we speed up customer returns?”). In any event, all interviews should begin with noncontroversial questions first and then gradually move into more contentious issues after the interviewer has developed some rapport with the interviewee. Preparing for the Interview It is important to prepare for the interview in the same way that you would prepare to give a presentation. You should have a general interview plan which lists the questions that you will ask in the appropriate order; anticipates possible answers and provides how you will follow up with them; and identifies segues between related topics. Confirm the areas in which the interviewee has knowledge so you do not ask questions that he or she cannot answer. Review the topic areas, the questions, and the interview plan, and clearly decide which ones have the greatest priority in case you run out of time. In general, structured interviews with closed-ended questions take more time to prepare than unstructured interviews. So, some beginning analysts prefer unstructured interviews, thinking that they can “wing it.” This is very dangerous and often counterproductive, because any information not gathered in the first interview would have to be obtained by follow-up efforts, and most people do not like to be interviewed repeatedly about the same issues. Be sure to prepare the interviewee as well. When you schedule the interview, inform the interviewee of the reason for the interview and the areas you will be discussing far enough in advance so that he or she has time to think about the issues and organize his or her thoughts. This is particularly important when you are an outsider to the organization and for 96 C ha pt er 3 Requirements Determination interviewing lower-level employees who often are not asked for their opinions and who may be uncertain about why you are interviewing them. Conducting the Interview When you start the interview, the first goal is to build rapport with the interviewee so that he or she trusts you and is willing to tell you the whole truth, not just give the answers that he or she thinks you want. You should appear to be professional and an unbiased, independent seeker of information. The interview should start with an explanation of why you are there and why you have chosen to interview the person, and then move into your planned interview questions. It is critical to carefully record all the information that the interviewee provides. In our experience, the best approach is to take careful notes—write down everything the interviewee says, even if it does not appear immediately relevant. Do not be afraid to ask the person to slow down or to pause while you write, because this is a clear indication that the interviewee’s infor- mation is important to you. One potentially controversial issue is whether or not to tape- record the interview. Recording ensures that you do not miss important points, but it can be intimidating for the interviewee. Most organizations have policies or generally accepted prac- tices about the recording of interviews, so find out what they are before you start an interview. If you are worried about missing information and cannot tape the interview, then bring along a second person to take detailed notes. As the interview progresses, it is important that you understand the issues that are discussed. If you do not understand something, be sure to ask. Do not be afraid to ask “dumb questions,” because the only thing worse than appearing “dumb” is to be “dumb” by not understanding something that you could have cleared up by questioning. If you do not understand something during the interview, you certainly will not understand it afterward. Try to recognize and define jargon, and be sure to clarify jargon you do not understand. One good strategy to increase your understanding during an interview is to periodically summarize the key points that the interviewee is communicating. This avoids misunder- standings and also demonstrates that you are listening. Finally, be sure to separate facts from opinion. The interviewee may say, for example, “We process too many credit card requests.” This is an opinion, and it is useful to follow this up with a probing question requesting support for the statement (e.g., “Oh, how many do you process in a day?”). It is helpful to check the facts because any differences between the facts and the interviewee’s opinions can point out key areas for improvement. Suppose that the interviewee complains about a high or increasing number of errors, but the logs show that errors have been decreasing. This suggests that errors are viewed as a very important problem that should be addressed by the new system, even if they are declining. As the interview draws to a close, be sure to give the interviewee time to ask questions or provide information that he or she thinks is important but was not part of your interview plan. In most cases, the interviewee will have no additional concerns or information, but in some cases this will lead to unanticipated, but important information. Likewise, it can be useful to ask the interviewee if there are other people who should be interviewed. Make sure that the interview ends on time. (If necessary, omit some topics or plan to schedule another interview.) As a last step in the interview, briefly explain what will happen next (see the Post-interview Follow-up section). You do not want to prematurely promise certain features in the new system or a specific delivery date, but you do want to reassure the interviewee that his or her time was well spent and very helpful to the project. Beginning systems analysts may naively think that conducting an interview is as easy as conversing with a friend. Unfortunately, this is almost never true. Interviewees often are not able or willing to hand over the needed information in a neat, organized fashion. In some cases, they may not want to share what they know at all. Analysts should hone their interper- sonal skills to improve their interviewing success. (See Practical Tip 3-1.)  Requirements Elicitation Techniques 97 PRACTICAL 3-1 Developing Interpersonal Skills TIP Interpersonal skills are those that enable you to develop make sure I understand. The key issues are...”). This rapport with others, and they are very important for inter- demonstrates that you consider the information impor- viewing. They help you to communicate with others tant—and also forces you to pay attention. (You cannot effectively. Some people develop good interpersonal repeat what you did not hear.) skills at an early age; they simply seem to know how to Be succinct. When you speak, be succinct. The goal communicate and interact with others. Other people are in interviewing (and in much of life) is to learn, not to less “lucky” and need to work hard to develop their skills. impress. The more you speak, the less time you give to Interpersonal skills, like most skills, can be learned. others. Here are some tips: Be honest. Answer all questions truthfully, and if you Don’t worry, be happy. Happy people radiate confi- do not know the answer, say so. dence and project their feelings on others. Try interview- Watch body language (yours and theirs). The way a ing someone while smiling and then interviewing person sits or stands conveys much information. In someone else while frowning and see what happens! general, a person who is interested in what you are Pay attention. Pay attention to what the other person is saying sits or leans forward, makes eye contact, and saying (which is harder than you might think). See how often touches his or her face. A person leaning away many times you catch yourself with your mind on some- from you or with an arm over the back of a chair is thing other than the conversation at hand. disinterested. Crossed arms indicate defensiveness or Summarize key points. At the end of each major uncertainty, while “steepling” (sitting with hands raised theme or idea that someone explains, you should in front of the body with fingertips touching) indicates repeat the key points back to the speaker (e.g., “Let me a feeling of superiority. Post-interview Follow-up After the interview is over, the analyst needs to prepare an interview report that describes the information from the interview (Figure 3-7). The report contains inter- view notes, information that was collected over the course of the interview and is summarized in a useful format. In general, the interview report should be written within 48 hours of the inter- view, because the longer you wait, the more likely you are to forget information. Often, the interview report is sent to the interviewee with a request to read it and inform the analyst of clarifications or updates. Make sure the interviewee is convinced that you genu- inely want his or her corrections to the report. Usually, there are few changes, but the need for any significant changes suggests that a second interview will be required. Never distribute someone’s information without prior approval. CONCEPTS 3-C The Reluctant Interviewee IN ACTION Early in my consulting career I was sent to a client our attempt to document this system was abandoned. organization with the goal of interviewing the only per- Roberta Roth son in the organization who knew how the accounts receivable system worked, and developing documenta- Questions tion for that system (nonexistent at the time). The inter- 1. Why do you suppose the interviewee was so viewee was on time, polite, and told me absolutely uncooperative? nothing of value about the accounts receivable system, despite my best efforts over several interview sessions. 2. Can you think of any ways to avoid this failed Eventually, my manager called me off this project, and outcome? 98 C ha pt er 3 Requirements Determination Interview Notes Approved by: Linda Estey Person Interviewed: Linda Estey, Director, Human Resources Interviewer: Barbara Wixom Purpose of Interview: Understand reports produced for human resources (HR) by the current system. Determine information requirements for future system. Summary of Interview: Sample reports of all current HR reports are attached to this report. The information that is not used and missing information are noted on the reports. Two biggest problems with the current system are: 1. The data are too old. (The HR department needs information within 2 days of month end; currently information is provided to them after a 3-week delay.) 2. The data are of poor quality. (Often, reports must be reconciled with the HR departmental database.) The most common data errors found in the current system include incorrect job-level information and missing salary information. FIGURE 3-7 Open Items: Interview Report Get current employee roster report from Mary Skudrna (extension 4355). Verify calculations used to determine vacation time with Mary Skudrna. A template for this Schedule interview with Jim Wack (extension 2337) regarding the reasons for data quality problems. figure is available on Detailed Notes: See attached transcript. the student web site Joint Application Development (JAD) JAD is an information gathering technique that allows the project team, users, and manage- ment to work together to identify requirements for the system. IBM developed the JAD tech- nique in the late 1970s, and it is a very useful method for collecting information from users.6 Capers Jones claims that JAD can reduce scope creep by 50%, and it prevents the requirements for a system from being too specific or too vague, both of which can cause trouble during later stages of the SDLC.7 JAD is a structured process in which 10–20 users meet under the direc- tion of a facilitator skilled in JAD techniques. The facilitator is a person who sets the meeting agenda and guides the discussion, but does not join in the discussion as a participant. He or she does not provide ideas or opinions on the topics under discussion and remains neutral during the session. The facilitator must be an expert in both group process techniques and systems analysis and design techniques. Ideally, the facilitator will have experience with the business under discussion. In many cases, the JAD facilitator is an outside consultant. Organ- izations may not have a regular day-to-day need for JAD or e-JAD expertise, and developing and maintaining this expertise in-house can be expensive. One or two scribes assist the facilita- tor by recording notes, making copies, and so on. Often, the scribes will use computers and CASE tools to record information as the JAD session proceeds. The JAD group meets for several hours, several days, or several weeks until all of the issues have been discussed and the needed information is collected. Most JAD sessions take place in a specially prepared meeting room, away from the participants’ offices, so that they are not interrupted. The meeting room is usually arranged in a U shape so that all participants can 6 More information on JAD can be found in J. Wood and D. Silver, Joint Application Development, New York: John Wiley & Sons, 1989; and Alan Cline, “Joint Application Development for Requirements Collection and Management,” http://www.carolla.com/wp-jad.htm. 7 See Kevin Strehlo, “Catching up with the Jones and ‘Requirement’ Creep,” InfoWorld, July 29, 1996; and Kevin Strehlo, “The Makings of a Happy Customer: Specifying Project X,” Infoworld, Nov 11, 1996.  Requirements Elicitation Techniques 99 easily see each other (Figure 3-8). At the front of the room (the open part of the “U”), there is a whiteboard, flip chart and/or overhead projector for use by the facilitator, who leads the discussion. One problem with JAD is that it suffers from the traditional problems associated with groups: sometimes people are reluctant to challenge the opinions of others (particularly their boss), a few people often dominate the discussion, and not everyone participates. In a 15-member group, for example, if everyone participates equally, then each person can talk for only 4 minutes each hour and must listen for the remaining 56 minutes—not a very efficient way to collect information. Electronic JAD, or e-JAD, attempts to overcome these problems by the use of groupware. In an e-JAD meeting room, each participant uses special software on a networked computer to anonymously submit ideas, view all ideas generated by the group, and rate and rank ideas through voting. The facilitator uses the electronic tools of the e-JAD system to guide the group Whiteboard Screen Flip chart sheets Name cards Projectors Printer Name cards Computers FIGURE 3-8 Joint Application Development Meeting Room 100 C ha pte r 3 Requirements Determination YO U R 3-2 Interview Practice T UR N Interviewing is not as simple as it first appears. Select two Questions people from class to go to the front of the room to demon- strate an interview. (This also can be done in groups.) Have 1. Describe the body language of the interview pair. one person be the interviewer, and the other the inter- 2. What kind of interview was conducted? viewee. The interviewer should conduct a 5-minute inter- 3. What kinds of questions were asked? view regarding the school course registration system. Gather 4. What was done well? How could the interview be information about the existing system and how the system improved? can be improved. If there is time, repeat with another pair. process, for maintaining anonymity and enabling the group to focus on each idea’s merits and not the power or rank of the person who contributed the idea. In this way, all participants can contribute at the same time, without fear of reprisal from people with differing opinions. Initial research suggests that e-JAD can reduce the time required to run JAD sessions by 50–80%.8 Selecting Participants Selecting JAD participants is done in the same basic way as selecting inter- view participants. Participants are selected on the basis of information they can contribute, to provide a broad mix of organizational levels, and to build political support for the new system. The need for all JAD participants to be away from their offices at the same time can be a major problem. The office may need to be closed or run with a skeleton staff until the JAD sessions are complete. Ideally, the participants who are released from regular duties to attend the JAD sessions should be the very best people in that business unit. However, without strong management support, JAD sessions can fail, because those selected to attend the JAD session are people who are less likely to be missed (i.e., the least competent people). Designing the JAD Session JAD sessions can run from as little as a half day to several weeks, depending upon the size and scope of the project. In our experience, most JAD sessions tend to last 5–10 days spread over a 3-week period. Most e-JAD sessions tend to last 1–4 days in a 1-week period. As with interviewing, JAD success depends upon a careful plan. JAD sessions usually are designed and structured along the same principles as interviews. Most JAD sessions are designed to collect specific information from users, and this requires the development of a set of questions before the meeting. A difference between JAD and interviewing is that all JAD sessions are structured—they must be carefully planned. In general, closed-ended questions are seldom used, because they do not spark the open and frank discussion that is typical of JAD. In our experience, it is better to proceed top-down in JAD sessions when gathering infor- mation. Typically, 30 minutes is allocated to each separate agenda item, and frequent breaks are scheduled throughout the day because participants tire easily. Preparing for the JAD Session As with interviewing, it is important to prepare the analysts and participants for the JAD session. Because the sessions can go beyond the depth of a typical inter- view and usually are conducted off-site, participants can be more concerned about how to prepare. It is important that the participants understand what is expected of them. If the goal of the JAD session, for example, is to develop an understanding of the current system, then participants can 8For more information on e-JAD, see A. R. Dennis, G. S. Hayes, and R. M. Daniels, “Business Process Modeling with Groupware,” Journal of Management Information Systems, 1999, 15(4); 115–142.  Requirements Elicitation Techniques 101 bring procedure manuals and documents with them. If the goal is to identify improvements for a system, then they can think about how they would improve the system prior to the JAD session. Conducting the JAD Session Most JAD sessions try to follow a formal agenda, and most have formal ground rules that define appropriate behavior. Common ground rules include following the schedule, respecting others’ opinions, accepting disagreement, and ensuring that only one person talks at a time. The role of the JAD facilitator can be challenging. Many participants come to the JAD session with strong feelings about the system being discussed. Channeling these feelings so that the session moves forward in a positive direction and getting participants to recognize and accept—but not necessarily agree on—opinions and situations different from their own requires significant expertise in systems analysis and design, JAD, and interpersonal skills. Few systems analysts attempt to facilitate JAD sessions without being trained in JAD techniques, and most apprentice with a skilled JAD facilitator before they attempt to lead their first session. The JAD facilitator performs three key functions. First, he or she ensures that the group sticks to the agenda. The only reason to digress from the agenda is when it becomes clear to the facilitator, project leader, and project sponsor that the JAD session has produced some new information that is unexpected and requires the JAD session (and perhaps the project) to move in a new direction. When participants attempt to divert the discussion away from the agenda, the facilitator must be firm, but polite, in leading the discussion back to the agenda and getting the group back on track. Second, the facilitator must help the group understand the technical terms and jargon that surround the system development process and help the participants understand the specific analysis techniques used. Participants are experts in their business area, but they probably are not experts in systems analysis. The facilitator must therefore minimize the learning required and teach participants how to effectively provide the right information. Third, the facilitator records the group’s input on a public display area, which can be a white- board, flip chart, or computer display. He or she structures the information that the group pro- vides and helps the group recognize key issues and important solutions. Under no circumstance should the facilitator insert his or her opinions into the discussion. The facilitator must remain neutral at all times and simply help the group through the process. The moment the facilitator offers an opinion on an issue, the group will no longer see him or her as a neutral party, but rather as someone who could be attempting to sway the group into some predetermined solution. However, this does not mean that the facilitator should not try to help the group resolve issues. For example, if two items appear to be the same to the facilitator, the facilitator should not say, “I think these may be similar.” Instead, the facilitator should ask, “Are these similar?” If the group decides that they are, the facilitator can combine them and move on. However, if the group decides that they are not similar (despite what the facilitator believes), the facilitator should accept the decision and move on. The group is always right, and the facilitator has no opinion. It is common for the JAD participants to make use of a number of tools during the JAD ses- sion in order to fully define the new system. Use cases may be created to describe how the users will interact with the new system. Prototypes may be created to more fully understand the user interface or navigation through the system. Process models can be constructed to understand the software that will be developed, while a data model can be used to describe the data that will be captured and maintained. The facilitator and the analysts on the project team should use every tool at their disposal to help the participants clarify and define their needs for the new system. Post-JAD Follow-Up As with interviews, a JAD post-session report is prepared and circulated among session attendees. The post-session report is essentially the same as the interview report in Figure 3-7. Since the JAD sessions are longer and provide more information, it usually takes a week or two after the JAD session before the report is complete. 102 C ha pte r 3 Requirements Determination YO U R 3-3 JAD Practice T UR N Organize yourselves into groups of four to seven people, (e.g., working on a class assignment, making a sandwich, and pick one person in each group to be the JAD facilita- paying bills, getting to class). How did the JAD session tor. Using a blackboard, whiteboard, or flip chart, gather go? Based on your experience, what are some pros and information about how the group performs some process cons of using JAD in a real organization? Questionnaires A questionnaire is a set of written questions for obtaining information from individuals. Questionnaires often are used when there is a large number of people from whom informa- tion and opinions are needed. In our experience, questionnaires are commonly used for systems intended for use outside of the organization (e.g., by customers or vendors) or for systems with business users spread across many geographic locations. Today, most question- naires are being distributed in electronic form, either via e-mail or on the Web. Selecting Participants As with interviews and JAD sessions, the first step is to select the individuals to whom the questionnaire will be sent. Typically, a sample, or subset, of people are selected who are representative of the entire group. Sampling guidelines are discussed in most statistics books, and most business schools include courses that cover the topic, so we will not discuss it here. The important point in selecting a sample, however, is to realize that not eve- ryone who receives a questionnaire will actually complete it. On average, only 30–50% of paper and e-mail questionnaires are returned. Response rates for Web-based questionnaires tend to be significantly lower (often, only 5–30%). Designing the Questionnaire Developing good questions is critical for questionnaires because the information on a questionnaire cannot be immediately clarified for a confused respondent. Questions on questionnaires must be very clearly written and must leave little room for misun- derstanding; therefore, closed-ended questions tend to be most commonly used. Questions must enable the analyst to clearly separate facts from opinions. Opinion questions often ask the respondent the extent to which they agree or disagree (e.g., “Are network problems common?”), while factual questions seek more precise values (e.g., “How often does a network problem occur: once an hour, once a day, or once a week?”). See Figure 3-9 for guidelines on questionnaire design. Perhaps the most obvious issue—but one that is sometimes overlooked—is to have a clear understanding of how the information collected from the questionnaire will be analyzed and used. You must address this issue before you distribute the questionnaire, because it is too late afterward. Begin with nonthreatening and interesting questions. Group items into logically coherent sections. Do not put important items at the very end of the questionnaire. Do not crowd a page with too many items. Avoid abbreviations. Avoid biased or suggestive items or terms. Number questions to avoid confusion. FIGURE 3-9 Pretest the questionnaire to identify confusing questions. Good Questionnaire Provide anonymity to respondents. Design  Requirements Elicitation Techniques 103 PRACTICAL 3-2 Managing Problems in JAD Sessions TIP I have run more than a hundred JAD sessions and have they mention something already on the list, you learned several standard “facilitator tricks.” Here are some quickly interrupt, point out that it is there, and ask common problems and some ways to deal with them. what other information to add. Do not let them repeat the same point, but write any new information. Reducing domination. The facilitator should ensure Violent agreement. Some of the worst disagreements that no one person dominates the group discussion. occur when participants really agree on the issues but The only way to deal with someone who dominates is do not realize that they agree because they are using head on. During a break, approach the person, thank different terms. An example is arguing whether a glass him or her for their insightful comments, and ask them is half empty or half full; they agree on the facts, but to help you make sure that others also participate. cannot agree on the words. In this case, the facilitator Encouraging noncontributors. Drawing out people has to translate the terms into different words and find who have participated very little is challenging because common ground so the parties recognize that they you want to bring them into the conversation so that really agree. they will contribute again. The best approach is to ask a direct factual question that you are certain they can Unresolved conflict. In some cases, participants do answer. And it helps to ask the question using some not agree and cannot understand how to determine repetition to give them time to think. For example, what alternatives are better. You can help by structur- “Pat, I know you’ve worked shipping orders a long ing the issue. Ask for criteria by which the group will time. You’ve probably been in the Shipping Department identify a good alternative (e.g., “Suppose this idea longer than anyone else. Could you help us understand really did improve customer service. How would I exactly what happens when an order is received in recognize the improved customer service?”). Then Shipping?” once you have a list of criteria, ask the group to assess the alternatives using them. Side discussions. Sometimes participants engage in side conversations and fail to pay attention to the True conflict. Sometimes, despite every attempt, par- group. The easiest solution is simply to walk close to ticipants just cannot agree on an issue. The solution is the people and continue to facilitate right in front of to postpone the discussion and move on. Document them. Few people will continue a side conversation the issue as an “open issue” and list it prominently on when you are 2 feet from them and the entire group’s a flip chart. Have the group return to the issue hours attention is on you and them. later. Often the issue will resolve itself by then and you have not wasted time on it. If the issue cannot be Agenda merry-go-round. The merry-go-round occurs resolved later, move it to the list of issues to be decided when a group member keeps returning to the same by the project sponsor or some other more senior issue every few minutes and will not let go. One solu- member of management. tion is to let the person have 5 minutes to ramble on about the issue while you carefully write down every Use humor. Humor is one of the most powerful tools point on a flip chart or computer file. This flip chart or a facilitator has and thus must be used judiciously. file is then posted conspicuously on the wall. When The best JAD humor is always in context; never tell the person brings up the issue again, you interrupt jokes but take the opportunity to find the humor in the them, walk to the paper and ask them what to add. If situation. Alan Dennis Questions should be relatively consistent in style so that the respondent does not have to read instructions for each question before answering it. It is generally a good practice to organize related questions together to make them simpler to answer. Some experts suggest that questionnaires should start with questions important to respondents, so that the questionnaire immediately grabs their interest and induces them to answer it. Perhaps the most important step is to have several colleagues review the questionnaire and then pretest it with a few people drawn from the groups to whom it will be sent. It is surprising how often seemingly simple questions can be misunderstood. 104 C ha pte r 3 Requirements Determination YO U R 3-4 Questionnaire Practice T UR N Organize yourselves into small groups. Have each per- Questions son develop a short questionnaire to collect information 1. How did the questionnaire you completed differ about the frequency in which group members perform from the one you created? some process (e.g., working on a class assignment, mak- ing a sandwich, paying bills, getting to class), how long 2. What are the strengths of each questionnaire? it takes them, how they feel about the process, and 3. How would you analyze the survey results if you opportunities for improving the process. had received 50 responses? Once everyone has completed his or her question- 4. What would you change about the questionnaire naire, ask each member to pass it to the right and then that you developed? complete his or her neighbor’s questionnaire. Pass the questionnaire back to the creator when it is completed. Administering the Questionnaire The key issue in administering the questionnaire is getting participants to complete the questionnaire and send it back. Dozens of marketing research books have been written about ways to improve response rates. Commonly used techniques include clearly explaining why the questionnaire is being conducted and why the respondent has been selected; stating a date by which the questionnaire is to be returned; offering an inducement to complete the questionnaire (e.g., a free pen); and offering to supply a summary of the question- naire responses. Systems analysts have additional techniques to improve responses rates inside the organization, such as personally handing out the questionnaire and personally contacting those who have not returned them after a week or two, as well as requesting the respondents’ supervisors to administer the questionnaires in a group meeting. Questionnaire Follow-Up It is helpful to process the returned questionnaires and develop a questionnaire report soon after the questionnaire deadline. This ensures that t