When gathering requirements the most commonly used technique is

Case Study 1: Requirement Analysis And Gathering For The State Firefighters Association

One of the fi rst activities of an analyst is to determine the business requirements for a new system. Th is chapter begins by presenting the requirements defi nition, a document that lists the new system’s capabilities. It then describes how to analyze requirements using require- ments analysis strategies and how to gather requirements using interviews, JAD sessions, questionnaires, document analysis, and observation. Th e chapter also describes a set of alter- native requirements-documentation techniques and describes the system proposal document that pulls everything together.

OBJECTIVES

■ Understand how to create a requirements defi nition ■ Become familiar with requirements-analysis techniques ■ Understand when to use each requirements-analysis technique ■ Understand how to gather requirements using interviews, JAD sessions, questionnaires,

document analysis, and observation ■ Understand the use of concept maps, story cards, and task lists as requirements-

documentation techniques ■ Understand when to use each requirements-gathering technique ■ Be able to begin creating a system proposal

INTRODUCTION Th e systems development process aids an organization in moving from the current system (oft en called the as-is system) to the new system (oft en called the to-be system). Th e output of planning, discussed in Chapter 2, is the system request, which provides general ideas for the to-be system, defi nes the project’s scope, and provides the initial workplan. Analysis takes the general ideas in the system request and refi nes them into a detailed requirements defi nition (this chapter), functional models (Chapter 4), structural models (Chapter 5), and behavioral models (Chapter 6) that together form the system proposal. Th e system proposal also includes revised project management deliverables, such as the feasibility analysis and the workplan (Chapter 2).

Th e output of analysis, the system proposal, is presented to the approval committee, who decides if the project is to continue. If approved, the system proposal moves into design, and its elements (requirements defi nition and functional, structural, and behavioral models) are used as inputs to the steps in design. Th is further refi nes them and defi nes in much more detail how the system will be built.

Th e line between analysis and design is very blurry. Th is is because the deliverables created during analysis are really the fi rst step in the design of the new system. Many of the major design decisions for the new system are found in the analysis deliverables. It is

C H A P T E R 3

Requirements Determination

Copyright © 2015 John Wiley & Sons, Inc.

Requirements Determination 87

important to remember that the deliverables from analysis are really the fi rst step in the design of the new system.

In many ways, because it is here that the major elements of the system fi rst emerge, the requirements-determination step is the single most critical step of the entire system devel- opment process. During requirements determination, the system is easy to change because little work has been done yet. As the system moves through the system development process, it becomes harder and harder to return to requirements determination and to make major changes because of all of the rework that is involved. Several studies have shown that more than half of all system failures are due to problems with the requirements.1 Th is is why the iterative approaches of object-oriented methodologies are so eff ective—small batches of requirements can be identifi ed and implemented in incremental stages, allowing the overall system to evolve over time.

REQUIREMENTS DETERMINATION Th e purpose of requirements determination is to turn the very high-level explanation of the business requirements stated in the system request into a more precise list of require- ments that can be used as inputs to the rest of analysis (creating functional, structural, and behavioral models). Th is expansion of the requirements ultimately leads to the design of the system.

Defi ning a Requirement A requirement is simply a statement of what the system must do or what characteristic it must have. During analysis, requirements are written from the perspective of the busi- nessperson, and they focus on the “what” of the system. Because they focus on the needs of the business user, they are usually called business requirements (and sometimes user requirements). Later in design, business requirements evolve to become more technical, and they describe how the system will be implemented. Requirements in design are writ- ten from the developer’s perspective, and they are usually called system requirements.

We want to stress that there is no black-and-white line dividing a business requirement and a system requirement—and some companies use the terms interchangeably. Th e impor- tant thing to remember is that a requirement is a statement of what the system must do, and requirements will change over time as the project moves from inception to elaboration to construction. Requirements evolve from detailed statements of the business capabilities that a system should have to detailed statements of the technical way the capabilities will be implemented in the new system.

Requirements can be either functional or nonfunctional in nature. A functional require- ment relates directly to a process a system has to perform or information it needs to contain. For example, requirements stating that a system must have the ability to search for available inventory or to report actual and budgeted expenses are functional requirements. Functional requirements fl ow directly into the creation of functional, structural, and behavioral models that represent the functionality of the evolving system (see Chapters 4, 5, and 6).

Nonfunctional requirements refer to behavioral properties that the system must have, such as performance and usability. Th e ability to access the system using a Web browser is considered a nonfunctional requirement. Nonfunctional requirements can infl uence the rest of analysis (functional, structural, and behavioral models) but oft en do so only indirectly; nonfunctional requirements are used primarily in design when decisions are made about the database, the user interface, the hardware and soft ware, and the system’s underlying physical architecture. 1 For example, see Th e Scope of Soft ware Development Project Failures (Dennis, MA: Th e Standish Group, 1995).

Copyright © 2015 John Wiley & Sons, Inc.

88 Chapter 3 Requirements Determination

Nonfunctional requirements describe a variety of characteristics regarding the system: operational, performance, security, and cultural and political. Operational requirements address issues related to the physical and technical requirements in which the system will operate. Performance requirements address issues related to the speed, capacity, and reli- ability of the system. Security requirements deal with issues with regard to who has access to the system and under what specifi c circumstances. Cultural and political requirements deal with issues related to the cultural, political factors and legal requirements that aff ect the system. Th ese characteristics do not describe business processes or information, but they are very important in understanding what the fi nal system should be like. Nonfunctional requirements primarily aff ect decisions that will be made during the design of a system. We will return to this topic later in the book when we discuss design (see Chapters 9, 10, and 11).

One area of information systems development that focused on diff erentiating functional and nonfunctional requirements is soft ware quality. Th ere have been many diff erent models proposed to measure the quality of soft ware. However, virtually all of them diff erentiate func- tional and nonfunctional requirements. From a quality perspective, functional quality is related to the degree that the soft ware meets the functional requirements, i.e., how much of the actual problem is solved by the soft ware solution provided. Whereas, the nonfunctional requirements are associated with the effi ciency, maintainability, portability, reliability, reusability, testability, and usability quality dimensions. As stated above, the nonfunctional related dimensions are associated primarily with the actual detailed design and implementation of the system.

When considering ISO 9000 compliance, quality dimensions are further decomposed into those that the user can see (external) and those that the user cannot see (internal). Th e external nonfunctional dimensions include effi ciency, reliability, and usability, whereas the internal nonfunctional dimensions include maintainability, portability, reusability, and testability. From a user perspective, the external dimensions are more important. If the system is simply too diffi cult to use, regardless how well the system solves the problem, the user will simply not use the system. In other words, from a user’s perspective, for an information system to be successful, the system must not only meet the functional specifi cation, but it must also meet the external nonfunctional specifi cations. From a developer perspective, the internal dimen- sions are also important. For example, given that successful systems tend to be long-lived and multiplatform, both the maintainability and portability dimensions can have strategic implica- tions for the system being developed. Also, given the agile development approaches being used in industry today, the development of reusable and testable soft ware is crucial.

Th ree additional topics that have infl uenced information system requirements are the Sarbanes-Oxley Act, COBIT (Control OBjectives for Information and related Technology) compliance and Capability Maturity Model compliance. Depending on the system being con- sidered, these three topics could aff ect the defi nition of a system’s functional requirements, nonfunctional requirements, or both. Th e Sarbanes-Oxley Act, for example, mandates addi- tional functional and nonfunctional requirements. Th ese include additional security concerns (nonfunctional) and specifi c information requirements that management must now provide (functional). When developing fi nancial information systems, information system developers should be sure to include Sarbanes-Oxley expertise in the development team. Moreover, a client could insist on COBIT compliance or that a specifi c Capability Maturity Model level had been reached in order for the fi rm to be considered as a possible vendor to supply the system under consideration. Obviously, these types of requirements add to the nonfunctional requirements. Further discussion of these topics is beyond the scope of this book.2

2 A concise discussion of the Sarbanes-Oxley Act is presented in G. P. Lander, What is Sarbanes-Oxley? (New York: McGraw-Hill, 2004). A good reference for Sarbanes-Oxley Act-based security requirements is D. C. Brewer, Security Controls for Sarbanes-Oxley Section 404 IT Compliance: Authorization, Authentication, and Access (Indianapolis, IN: Wiley, 2006). For detailed information on COBIT, see www.isaca.org; for ISO 9000, see www.iso.org; and for details on the Capability Maturity Model, see www.sei.cmu.edu/cmmi/.

Copyright © 2015 John Wiley & Sons, Inc.

Requirements Determination 89

Another recent topic that infl uences requirements for some systems is globalization. For example, a global information supply chain generates a large number of additional nonfunc- tional requirements. If the necessary operational environments do not exist for a mobile solu- tion to be developed, it is important to adapt the solution to the local environment. Or, it may not be reasonable to expect to deploy a high-technology-based solution in an area that does not have the necessary power and communications infrastructure. In some cases, we may need to consider supporting some parts of the global information supply chain with manual—rather than automated—systems.

Manual systems have an entirely diff erent set of requirements that create diff erent per- formance expectations and additional security concerns. Furthermore, cultural and political concerns are potentially paramount. A simple example that aff ects the design of user inter- faces is the proper use of color on forms (on a screen or paper). Diff erent cultures interpret diff erent colors diff erently. In other words, in a global, multicultural business environment, addressing cultural concerns goes well beyond simply having a multilingual user interface. We must be able to adapt the global solution to the local realities. Friedman refers to these concerns as glocalization.3 Otherwise, we will simply create another example of a failed infor- mation system development project.

Requirements Defi nition Th e requirements defi nition report—usually just called the requirements defi nition—is a straightforward text report that simply lists the functional and nonfunctional requirements in an outline format. Figure 3-1 shows a sample requirements defi nition for an appointment system for a typical doctor’s offi ce. Notice it contains both functional and nonfunctional requirements. Th e functional requirements include managing appointments, producing schedules, and recording the availability of the individual doctors. Th e nonfunctional require- ments include items such as the expected amount of time that it takes to store a new appoint- ment, the need to support wireless printing, and which types of employees have access to the diff erent parts of the system.

Th e requirements are numbered in a legal or outline format so that each requirement is clearly identifi ed. Th e requirements are fi rst grouped into functional and nonfunctional requirements; within each of those headings, they are further grouped by the type of nonfunc- tional requirement or by function.

Sometimes business requirements are prioritized on the requirements defi nition. Th ey 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). Th is practice is particularly important when using object-oriented meth- odologies since they deliver systems in an incremental manner.

Th e most obvious purpose of the requirements defi nition is to provide the information needed by the other deliverables in analysis, which include functional, structural, and behav- ioral models, and to support activities in design. Th e most important purpose of the require- ments defi nition, however, is to defi ne the scope of the system. Th e document describes to the analysts exactly what the system needs to end up doing. When discrepancies arise, the document serves as the place to go for clarifi cation.

Determining Requirements Determining requirements for the requirements defi nition is both a business task and an information technology task. In the early days of computing, there was a presumption that

3 T. L. Friedman, Th e World is Flat: A Brief History of the Twenty-First Century, Updated and Expanded Edition. (New York: Farrar, Straus, and Giroux, 2006.)

Copyright © 2015 John Wiley & Sons, Inc.

90 Chapter 3 Requirements Determination

the systems analysts, as experts with computer systems, were in the best position to defi ne how a computer system should operate. Many systems failed because they did not adequately address the true business needs of the users. Gradually, the presumption changed so that the users, as the business experts, were seen as being the best position to defi ne how a computer system should operate. However, many systems failed to deliver performance benefi ts because users simply automated an existing ineffi cient system, and they failed to incorporate new opportunities off ered by technology.

Th erefore, the most eff ective approach is to have both business people and analysts working together to determine business requirements. Sometimes, however, users don’t know exactly what they want, and analysts need to help them discover their needs. A set of strategies has become popular to help analysts do problem analysis, root cause analysis, dura- tion analysis, activity-based costing, informal benchmarking, outcome analysis, technology analysis, and activity elimination. Analysts can use these tools when they need to guide the users in explaining what is wanted from a system. Th ese strategies work similarly. Th ey help users critically examine the current state of systems and processes (the as-is system), identify exactly what needs to change, and develop a concept for a new system (the to-be system).

Functional Requirements

1. Manage Appointments 1.1. Patient makes new appointment. 1.2. Patient changes appointment. 1.3. Patient cancels appointment.

2. Produce Schedule 2.1. Office Manager checks daily schedule. 2.2. Office Manager prints daily schedule.

3. Record Doctor Availability 3.1. Doctor updates schedule

Nonfunctional Requirements

1. Operational Requirements 1.1. The system will operate in Windows environment. 1.2. The system should be able to connect to printers wirelessly. 1.3. The system should automatically back up at the end of each day.

2. Performance Requirements 2.1. The system will store a new appointment in 2 seconds or less. 2.2. The system will retrieve the daily appointment schedule in 2 seconds or less.

3. Security Requirements 3.1. Only doctors can set their availability. 3.2. Only a manager can produce a schedule.

4. Cultural and Political Requirements 4.1. No special cultural and political requirements are anticipated.

FIGURE 3-1 Sample Requirements Defi nition

Copyright © 2015 John Wiley & Sons, Inc.

Requirements Determination 91

Although these strategies enable the analyst to help users create a vision for the new system, they are not suffi cient for extracting information about the detailed business require- ments that are needed to build it. Th erefore, analysts use a portfolio of requirements-gathering techniques to acquire information from users. Th e analyst has many techniques from which to choose: interviews, questionnaires, observation, joint application development (JAD), and document analysis. Th e information gathered using these techniques is critically analyzed and used to craft the requirements defi nition report.

Creating a Requirements Defi nition Creating a requirements defi nition is an iterative and ongoing process whereby the analyst collects information with requirements-gathering techniques (e.g., interviews, document analysis), critically analyzes the information to identify appropriate business requirements for the system, and adds the requirements to the requirements defi nition report. Th e require- ments defi nition is kept up to date so that the project team and business users can refer to it and get a clear understanding of the new system.

To create a requirements defi nition, the project team fi rst determines the kinds of func- tional and nonfunctional requirements that they will collect about the system (of course, these may change over time). Th ese become the main sections of the document. Next, the analysts use a variety of requirements-gathering techniques to collect information, and they list the business requirements that were identifi ed from that information. Finally, the analysts work with the entire project team and the business users to verify, change, and complete the list and to help prioritize the importance of the requirements that were identifi ed.

Th is process continues throughout analysis, and the requirements defi nition evolves over time as new requirements are identifi ed and as the project moves into later phases of the Unifi ed Process. Beware: Th e evolution of the requirements defi nition must be carefully man- aged. Th e project team cannot keep adding to the requirements defi nition, or the system will keep growing and growing and never get fi nished. Instead, the project team carefully identifi es requirements and evaluates which ones fi t within the scope of the system. When a requirement refl ects a real business need but is not within the scope of the current system or current release, it is either added on a list of future requirements or given a low priority. Th e management of requirements (and system scope) is one of the hardest parts of managing a project.

Real-World Problems with Requirements Determination Avison and Fitzgerald provide us with a set of problems that can arise with regard to deter- mining the set of requirements with which to be dealt.4 First, the analyst might not have access to the correct set of users to uncover the complete set of requirements. Th is can lead to requirements being missed, misrepresented, and/or overspecifi ed. Second, the specifi cation of the requirements may be inadequate. Th is can be especially true with the lightweight tech- niques associated with agile methodologies. Th ird, some requirements are simply unknowa- ble at the beginning of a development process. However, as the system is developed, the users and analysts will get a better understanding of both the domain issues and the applicable tech- nology. Th is can cause new functional and nonfunctional requirements to be identifi ed and current requirements to evolve or be canceled. Iterative and incremental-based development methodologies, such as the Unifi ed Process and agile, can help in this case. Fourth, verifying and validating of requirements can be very diffi cult. We take up this topic in the chapters that deal with the creation of functional (Chapter 4), structural (Chapter 5), and behavioral (Chapter 6) models.

4 See D. Avison and G. Fitzgerald, Information Systems Development: Methodologies, Techniques, & Tools, 4th Ed. (London: McGraw-Hill, 2006).

Copyright © 2015 John Wiley & Sons, Inc.

92 Chapter 3 Requirements Determination

REQUIREMENTS ANALYSIS STRATEGIES Before the project team can determine what requirements are appropriate for a given system, there needs to be a clear vision of the kind of system that will be created and the level of change that it will bring to the organization. Th e basic process of analysis is divided into three steps: understanding the as-is system, identifying improvements, and developing require- ments for the to-be system.

Sometimes the fi rst step (i.e., understanding the as-is system) is skipped or is performed in a cursory manner. Th is 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. Newer RAD, agile, and object-oriented methodologies, such as phased development, prototyping, throwaway prototyping, extreme pro- gramming, and Scrum (see Chapter 1) focus almost exclusively on improvements and the to-be system requirements, and they spend little time investigating the current as-is system.

Requirements analysis strategies help the analyst lead users through the analysis steps so that the vision of the system can be developed. Requirements analysis strategies and requirements-gathering techniques go hand in hand. Analysts use requirements-gathering techniques to collect information; requirements analysis strategies drive the kind of infor- mation that is gathered and how it is ultimately analyzed. Th e requirements analysis strat- egies and requirements gathering happen concurrently and are complementary activities.

To move the users from the as-is system to the to-be system, 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, and critical thinking skills are needed to really under- stand issues and develop new business processes. Th ese skills are also needed to thoroughly examine the results of requirements gathering, to identify business requirements, and to translate those requirements into a concept for the new system.

Problem Analysis Th e most straightforward (and probably the most commonly used) requirements-analysis technique is problem analysis. Problem analysis means asking the users and managers to identify problems with the as-is system and to describe how to solve them in the to-be system. Most users have a very good idea of the changes they would like to see, and most are quite vocal about suggesting them. Most changes tend to solve problems rather than capitalize on opportunities, but the latter is possible as well. Improvements from problem analysis tend to be small and incremental (e.g., provide more space in which to type the customer’s address; provide a new report that currently does not exist).

Th is type of improvement oft en is very eff ective at improving a system’s effi ciency or ease of use. However, it oft en provides only minor improvements in business value—the new system is better than the old, but it may be hard to identify signifi cant monetary benefi ts from the new system.

Root Cause Analysis Th e ideas produced by problem analysis tend to be solutions to problems. All solutions make assumptions about the nature of the problem, assumptions that might or might not be valid. In our experience, users (and most people in general) tend to quickly jump to solutions with- out fully considering the nature of the problem. Sometimes the solutions are appropriate, but many times they address a symptom of the problem, not the true problem or root cause itself.5

5 Two good books that discuss the diffi culty in fi nding the root causes to problems are: E. M. Goldratt and J. Cox, Th e Goal (Croton-on-Hudson, NY: North River Press, 1986); E. M. Goldratt, Th e Haystack Syndrome (Croton-on-Hudson, NY: North River Press, 1990).

Copyright © 2015 John Wiley & Sons, Inc.

Requirements Analysis Strategies 93

For example, suppose a fi rm notices that its users report inventory stock-outs. Th e cost of inventory stock-outs can be quite signifi cant. In this case, since they happen frequently, custom- ers could fi nd another source for the items that they are purchasing from the fi rm. It is in the fi rm’s interest to determine the underlying cause and not simply provide a knee-jerk reaction such as arbitrarily increasing the amount of inventory kept on hand. In the business world, the challenge lies in identifying the root cause—few real-world problems are simple. Th e users typically propose a set of causes for the problem under consideration. Th e solutions that users propose can address either symptoms or root causes, but without a careful analysis, it is diffi cult to tell which one is addressed.

Root cause analysis, therefore, focuses on problems, not solutions. Th e analyst starts by having the users generate a list of problems with the current system and then prioritize the problems in order of importance. Starting with the most important, the users and/or the analysts then generate all the possible root causes for the problems. Each possible root cause is investigated (starting with the most likely or easiest to check) until the true root causes are identifi ed. If any possible root causes are identifi ed for several problems, those should be investigated fi rst, because there is a good chance they are the real root causes infl uencing the symptom problems. In our example, there are several possible root causes:

■ Th e fi rm’s supplier might not be delivering orders to the fi rm in a timely manner. ■ Th ere could be a problem with the fi rm’s inventory controls. ■ Th e reorder level and quantities could be set wrong.

Sometimes, using a hierarchical chart to represent the causal relationships helps with the analysis. As Figure 3-2 shows, there are many possible root causes that underlie the higher-level causes identifi ed. Th e key point in root cause analysis is always to challenge the obvious.

Duration Analysis Duration analysis requires a detailed examination of the amount of time it takes to perform each process in the current as-is system. Th e analysts begin by determining the total amount of time it takes, on average, to perform a set of business processes for a typical input. Th ey then time each of the individual steps (or subprocesses) in the business process. Th e time to

Frequent Inventory Stock-Outs

Order Approval Late

Identifying Vendor Delayed

Delay in Sending Order to Vendor

Delays in Order Processing

Late Recording of Sales

Late Recording of Purchases Received

Infrequent Manual Inventory Reconciliation

Problems with Inventory Controls

Reorder point set too low

Reorder Quantity (EOQ) set too low

Incorrect Reorder Level and Quantities

FIGURE 3-2 Root Cause Analysis for Inventory Stock-Outs

Copyright © 2015 John Wiley & Sons, Inc.

complete the basic step is then totaled and compared to the total for the overall process. A signifi cant diff erence between the two—and in our experience the total time oft en can be 10 or even 100 times longer than the sum of the parts—indicates that this part of the process is badly in need of a major overhaul.

For example, suppose that the analysts are working on a home mortgage system and dis- cover that on average, it takes thirty days for the bank to approve a mortgage. Th ey then look at each of the basic steps in the process (e.g., data entry, credit check, title search, appraisal) and fi nd that the total amount of time actually spent on each mortgage is about eight hours. Th is is a strong indication that the overall process is badly broken, because it takes thirty days to perform one day’s work.

Th ese problems probably occur because the process is badly fragmented. Many diff erent people must perform diff erent activities before the process fi nishes. In the mortgage exam- ple, the application probably sits on many people’s desks for long periods of time before it is processed.

Processes in which many diff erent people work on small parts of the inputs are prime candidates for process integration or parallelization. Process integration means changing the fundamental process so that fewer people work on the input, which oft en requires changing the processes and retraining staff to perform a wider range of duties. Process parallelization means changing the process so that all the individual steps are performed at the same time. For example, in the mortgage application case, there is probably no reason that the credit check cannot be performed at the same time as the appraisal and title check.

Activity-Based Costing Activity-based costing is a similar analysis; it examines the cost of each major process or step in a business process rather than the time taken.6 Th e analysts identify the costs associated with each of the basic functional steps or processes, identify the most costly processes, and focus their improvement eff orts on them.

Assigning costs is conceptually simple. Analysts simply examine the direct cost of labor and materials for each input. Materials costs are easily assigned in a manufacturing process, whereas labor costs are usually calculated based on the amount of time spent on the input and the hourly cost of the staff . However, as you may recall from a managerial accounting course, there are indirect costs, such as rent, depreciation, and so on, that also can be included in activity costs.

Informal Benchmarking Benchmarking refers to studying how other organizations perform a business process in order to learn how your organization can do something better. Benchmarking helps the organization by introducing ideas that employees may never have considered but that have the potential to add value.

Informal benchmarking is fairly common for customer-facing business processes (i.e., processes that interact with the customer). With informal benchmarking, the managers and analysts think about other organizations or visit them as customers to watch how the business process is performed. In many cases, the business studied may be a known leader in the indus- try or simply a related fi rm.

6 Many books have been written on activity-based costing. Useful ones include K. B. Burk and D. W. Webster, Activity-Based Costing (Fairfax, VA: American Management Systems, 1994); D. T. Hicks, Activity-Based Costing: Making It Work for Small and Mid-sized Companies (New York: Wiley, 1998). Th e two books by Eli Goldratt men- tioned previously (Th e Goal and Th e Haystack Syndrome) also off er unique insights into costing.

94 Chapter 3 Requirements Determination

Copyright © 2015 John Wiley & Sons, Inc.

Requirements-Gathering Techniques 95

Outcome Analysis Outcome analysis focuses on understanding the fundamental outcomes that provide value to customers. Although these outcomes sound as though they should be obvious, they oft en are not. For example, consider an insurance company. One of its customers has just had a car accident. What is the fundamental outcome from the customer’s perspective? Traditionally, insurance companies have answered this question by assuming the customer wants to receive the insurance payment quickly. To the customer, however, the payment is only a means to the real outcome: a repaired car. Th e insurance company might benefi t by extending its view of the business process past its traditional boundaries to include not paying for repairs but performing the repairs or contracting with an authorized body shop to do them.

With this approach, system analysts encourage the managers and project sponsor to pretend they are customers and to think carefully about what the organization’s products and services enable the customers to do—and what they could enable the customer to do.

Technology Analysis Many major changes in business since the turn of the century have been enabled by new technologies. Technology analysis starts by having the analysts and managers develop a list of important and interesting technologies. Th en the group systematically identifi es how every technology could be applied to the business process and identifi es how the business would benefi t. It is important to note the technology analysis in no way implies adopting technology for technology’s sake. Rather the focus is on using new technologies to meet the goals of the organization.

Activity Elimination Activity elimination is exactly what it sounds like. Th e analysts and managers work together to identify how the organization could eliminate each activity in the business process, how the function could operate without it, and what eff ects are likely to occur. Initially, managers are reluctant to conclude that processes can be eliminated, but this is a force-fi t exercise in that they must eliminate each activity. In some cases, the results are silly; nonetheless, participants must address every activity in the business process.

REQUIREMENTS-GATHERING TECHNIQUES An analyst is very much like a detective (and business users are sometimes 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 are oft en missed), so the analyst needs to notice details, talk with witnesses, and follow leads just as Sherlock Holmes would have done. Th e best analysts thoroughly gather 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. Analysts don’t want to discover later that they have key requirements wrong—such surprises late in the development process can cause all kinds of problems.

Th e requirements-gathering process is used for building political support for the pro- ject and establishing trust and rapport between the project team building the system and the users who ultimately will choose to use or not use the system. Involving someone in the process implies that the project teams view that person as an important resource and value his or her opinions. All the key stakeholders (the people who can aff ect the system or who will be aff ected by the system) must be included in the requirements-gathering process. Th e

Copyright © 2015 John Wiley & Sons, Inc.

stakeholders might include managers, employees, staff members, and even some customers and suppliers. If a key person is not involved, that individual might feel slighted, which can cause problems during implementation (e.g., How could they have developed the system without my input?).

Th e second challenge of requirements gathering is choosing the way(s) information is collected. Th ere are many techniques for gathering requirements that vary from asking people questions to watching them work. In this section, we focus on the fi ve most commonly used techniques: interviews, JAD sessions (a special type of group meeting), questionnaires, docu- ment analysis, and observation. Each technique has its own strengths and weaknesses, many of which are complementary, so most projects use a combination of techniques.7

Interviews An interview is the most commonly used requirements-gathering technique. Aft er all, it is natural—if you need to know something, you usually ask someone. In general, interviews are conducted one-on-one (one interviewer and one interviewee), but sometimes, owing to time constraints, several people are interviewed at the same time. Th ere are fi ve basic steps to the inter- view process: selecting interviewees, designing interview questions, preparing for the interview, conducting the interview, and postinterview follow-up.8

Th e fi rst step in interviewing is to create an interview schedule listing who will be interviewed, when, and for what purpose (see Figure 3-3). Th e schedule can be an informal list that is used to help set up meeting times or a formal list that is incorporated into the workplan. Th e people who appear on the interview schedule are selected based on the analyst’s information needs. Th e project sponsor, key business users, and other members of the project team can help the analyst determine who in the organization can best provide important information about requirements. Th ese people are listed on the interview schedule in the order in which they should be interviewed.

People at diff erent levels of the organization have varying perspectives on the system, so it is important to include both managers who manage the processes and staff who actually perform the processes to gain both high-level and low-level perspectives on an issue. Also, the kinds of interview subjects needed can 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 to move to midlevel managers who can provide broad, overarching information about the business process and the expected role of the system being developed. Once the analyst has a good understanding of the big picture, lower-level managers and staff members can fi ll 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 midlevel managers, then staff members, back to midlevel managers, and so on, depending upon what information is needed along the way.

It is quite common for the list of interviewees to grow, oft en by 50 to 75 percent. As peo- ple are interviewed, more information that is needed and additional people who can provide the information will probably be identifi ed.

7 Some excellent books that address the importance of gathering requirements and various techniques include Alan M. Davis, Soft ware Requirements: Objects, Functions, & States, Revision (Englewood Cliff s, NJ: Prentice Hall, 1993); Gerald Kotonya and Ian Sommerville, Requirements Engineering (Chichester, England: Wiley, 1998); Dean Leffi ngwell and Don Widrig, Managing Soft ware Requirements: A Unifi ed Approach (Reading, MA: Addison-Wesley, 2000). 8 A good book on interviewing is that by Brian James, Th e Systems Analysis Interview (Manchester, England: NCC Blackwell, 1989).

1. Select Interviewees

96 Chapter 3 Requirements Determination

Copyright © 2015 John Wiley & Sons, Inc.

Requirements-Gathering Techniques 97

Th ere are three types of interview questions: closed-ended questions, open-ended questions, and probing questions. Closed-ended questions are those that require a specifi c answer. Th ey are similar to multiple-choice or arithmetic questions on an exam (see Figure 3-4). Closed- ended questions are used when an analyst is looking for specifi c, 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 inter- view and obtain the information they need. However, these types of questions don’t uncover why the answer is the way it is, nor do they uncover information that the interviewer does not think to ask for ahead of time.

Open-ended questions are those that leave room for elaboration on the part of the inter- viewee. Th ey are similar in many ways to essay questions that you might fi nd on an exam (see Figure 3-4 for examples). Open-ended questions are designed to gather rich information and give the interviewee more control over the information that is revealed during the interview. Sometimes the information that the interviewee chooses to discuss uncovers information that is just as important as the answer (e.g., if the interviewee talks only about other departments when asked for problems, it may suggest that he or she is reluctant to admit his or her own problems).

Th e third type of question is the probing question. Probing questions follow up on what has just been discussed in order to learn more, and they oft en are used when the interviewer is unclear about an interviewee’s answer. Th ey encourage the interviewee to expand on or to con- fi rm information from a previous response, and they signal that the interviewer is listening and is interested in the topic under discussion. Many beginning analysts are reluctant to use probing questions because they are afraid that the interviewee might be off ended at being challenged or because they believe it shows that they didn’t understand what the interviewee said. When done politely, probing questions can be a powerful tool in requirements gathering.

In general, an interviewer 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 simpler to show the interviewee a form or report (see the section on document analysis) and ask what information on it is used. Th is helps focus the interviewee on the task and saves time, because the interviewee does not need to describe the information detail—he or she just needs to point it out on the form or report.

No type of question is better than another, and a combination of questions is usually used during an interview. At the initial stage of an IS development project, the as-is process can

2. Design Interview Questions

FIGURE 3-3 Sample Interview Schedule

Andria McClellan Director, Accounting Strategic vision for new Mon., March 1 accounting system 8:00–10:00 AM

Jennifer Draper Manager, Accounts Current problems with Mon., March 1 Receivable accounts receivable 2:00–3:15 PM process; future goals

Mark Goodin Manager, Accounts Current problems with Mon., March 1 Payable accounts payable 4:00–5:15 PM process; future goals

Anne Asher Supervisor, Data Entry Accounts receivable and Wed., March 3 payable processes 10:00–11:00 AM

Fernando Merce Data Entry Clerk Accounts receivable and Wed., March 3 payable processes 1:00–3:00 PM

Purpose of Name Position Interview Meeting

Copyright © 2015 John Wiley & Sons, Inc.

be unclear, so the interview process begins with unstructured interviews, interviews that seek broad and roughly defi ned information. In this case, the interviewer has a general sense of the information needed but has few closed-ended questions to ask. Th ese are the most challeng- ing interviews to conduct because they require the interviewer to ask open-ended questions and probe for important information on the fl y.

As the project progresses, the analyst comes to understand the business process much better and needs very specifi c information about how business processes are performed (e.g., exactly how a customer credit card is approved). At this time, the analyst conducts structured interviews, in which specifi c sets of questions are developed before the interviews. Th ere 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 fl ows well. For example, when trying to gather information about the current business process, it can be useful to move in logical order through the process or from the most important issues to the least important.

Th ere are two fundamental approaches to organizing the interview questions: top down or bottom up (see Figure 3-5). With the top-down interview, the interviewer starts with broad, general issues and gradually works toward more-specifi c ones. With the bottom-up interview, the interviewer starts with very specifi c questions and moves to broad questions. In practice, analysts mix the two approaches, starting with broad, general issues, moving to specifi c ques- tions, and then returning to general issues.

Th e top-down approach is an appropriate strategy for most interviews (it is certainly the most common approach). Th e top-down approach enables the interviewee to become accus- tomed to the topic before he or she needs to provide specifi cs. It also enables the interviewer to understand the issues before moving to the details because the interviewer might not have suffi cient information at the start of the interview to ask very specifi c 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.

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 fi ll in some holes with details. Bottom-up interviewing may be appropriate if lower-level staff members feel threatened or unable to answer high-level questions. For example, How can we improve customer service? might be too broad a question for a customer service clerk, whereas a specifi c question is readily answerable (e.g., How can we speed up customer returns?). In any event, all interviews should begin with noncontroversial questions and then gradually move into more contentious issues aft er the interviewer has developed some rapport with the interviewee.

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 current system?

• What are some of the problems you face on a daily basis?

• What are some of the improvements you would like to see in a new system?

Probing questions • Why?

• Can you give me an example?

• Can you explain that in a bit more detail?

FIGURE 3-4 Three Types of Questions

Types of Questions Examples

98 Chapter 3 Requirements Determination

Copyright © 2015 John Wiley & Sons, Inc.

Requirements-Gathering Techniques 99

It is important to prepare for the interview in the same way that you would prepare to give a presentation. Th e interviewer should have a general interview plan listing the questions to be asked in the appropriate order, should anticipate possible answers and provide follow-up with them, and should identify segues between related topics. Th e interviewer should con- fi rm the areas in which the interviewee has knowledge so as not to ask questions that the interviewee cannot answer. Review the topic areas, the questions, and the interview plan, and clearly decide which have the greatest priority in case time runs short.

In general, structured interviews with closed-ended questions take more time to prepare than unstructured interviews. Some beginning analysts prefer unstructured interviews, think- ing that they can wing it. Th is is very dangerous and oft en counterproductive, because any information not gathered in the fi rst interview will require follow-up eff orts, and most users do not like to be interviewed repeatedly about the same issues.

Th e interviewer should be sure to prepare the interviewee as well. When the interview is scheduled, the interviewee should be told the reason for the interview and the areas that will be discussed far enough in advance so that he or she has time to think about the issues and organize his or her thoughts. Th is is particularly important when the interviewer is an outsider to the organization and for lower-level employees, who oft en are not asked for their opinions and who may be uncertain about why they are being interviewed.