cis 353 ca st 1

c03.pdf

Home >Computer Science homework help >cis 353 ca st 1

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

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).

8 8 C h a p t e r 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/.

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.)

9 0 C h a p t e r 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

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).

9 2 C h a p t e r 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).

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

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.

9 4 C h a p t e r 3 Requirements Determination

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

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

9 6 C h a p t e r 3 Requirements Determination

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

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

9 8 C h a p t e r 3 Requirements Determination

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.

Th e fi rst goal is to build rapport with the interviewee, so that he or she trusts the inter- viewer and is willing to tell the whole truth, not just give the answers that he or she thinks are wanted. Th e interviewer should appear to be a professional and unbiased, independent seeker of information. Th e interview should start with an explanation of why the inter- viewer is there and why he or she has chosen to interview the person; then the interviewer should move into the 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. Th e interviewer shouldn’t be afraid to ask the person to slow down or to pause while writing, because this is a clear indication that the interviewee’s information is important. One potentially controversial issue is whether or not to tape-record an interview. Recording ensures that the interviewer does not miss important

3. Prepare for the Interview

4. Conduct the Interview

FIGURE 3-5 Top-Down and Bottom-Up Questioning Strategies

High-level: Very general

Top-Down

Bottom-Up

Medium-level: Moderately specific

Low-level: Very specific

How can order processing

be improved?

How can we reduce the number of times that customers return items

they’ve ordered?

How can we reduce the number of errors in order processing (e.g., shipping

the wrong products)?

points, but it can be intimidating for the interviewee. Most organizations have policies or generally accepted practices about the recording of interviews, so they should be determined before an interview. If the interviewer is worried about missing information and cannot tape the interview, then he or she can bring along a second person to take detailed notes.

As the interview progresses, it is important to understand the issues that are discussed. If the interviewer does not understand something, he or she should ask for clarifi cation. Th e interviewer should not be afraid to ask dumb questions, because the only thing worse than appearing dumb is to be dumb by not understanding something. If the interviewer doesn’t understand something during the interview, he or she certainly won’t understand it aft erwards. Jargon should be recognized and defi ned; any jargon not understood should be clarifi ed. One good strategy to increase understanding during an interview is to periodically summarize the key points that the interviewee is communicating. Th is avoids misunder- standings and also demonstrates that the interviewer is listening.

Finally, facts should be separated from opinion. Th e interviewee may say, for example, We process too many credit card requests. Th is 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 diff erences between the facts and the interviewee’s opinions can point out key areas for improvement. Suppose the inter- viewee complains about a high or increasing number of errors, but the logs show that errors have been decreasing. Th is 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, the interviewee should have time to ask questions or provide information that he or she thinks is important but was not part of the interview plan. In most cases, the interviewee has no additional concerns or information, but in some cases this leads to unanticipated, but important, information. Likewise, it can be useful to ask the interviewee if there are other people who should be interviewed. Th e interview should end on time (if necessary, some topics can be omitted or another interview can be scheduled).

As a last step in the interview, the interviewer should briefl y explain what will happen. Th e interviewer shouldn’t prematurely promise certain features in the new system or a spe- cifi c delivery date, but he or she should reassure the interviewee that his or her time was well spent and very helpful to the project.

Aft er the interview is over, the analyst needs to prepare an interview report that describes the information from the interview (Figure 3-6). Th e report contains interview 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 forty-eight hours of the interview, because the longer the interviewer waits, the more likely he or she is to forget information.

Oft en, the interview report is sent to the interviewee with a request to read it and inform the analyst of clarifi cations or updates. Th e interviewee needs to be convinced that the inter- viewer genuinely wants his or her corrections to the report. Usually there are few changes, but the need for any signifi cant changes suggests that a second interview will be required. Never distribute someone’s information without prior approval.

Joint Application Development (JAD) JAD is an information-gathering technique that allows the project team, users, and management to work together to identify requirements for the system. IBM developed the JAD technique in the late 1970s, and it is oft en the most useful method for collecting information from users.9

9 More information on JAD can be found in J. Wood and D. Silver, Joint Application Development (New York: Wiley, 1989); Alan Cline, “Joint Application Development for Requirements Collection and Management,” http:// www.carolla.com/wp-jad.htm.

5. Post-Interview Follow-up

1 0 0 C h a p t e r 3 Requirements Determination

Requirements-Gathering Techniques 101

Capers Jones claims that JAD can reduce scope creep by 50 percent and prevent the system’s requirements from being too specifi c or too vague, both of which cause trouble during later stages of the development process.10

JAD is a structured process in which ten to twenty users meet together under the direc- tion of a facilitator skilled in JAD techniques. Th e facilitator 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 so as to remain neutral during the session. Th e facilitator must be an expert in both group-process techniques and systems- analysis and design techniques. One or two scribes assist the facilitator by recording notes, making copies, and so on. Oft en the scribes use computers and CASE tools to record infor- mation as the JAD session proceedings.

Th e JAD group meets for several hours, several days, or several weeks until all 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’ offi ces so that they are not interrupted. Th e meeting room is usually arranged in a U-shape so that all participants can easily see each other. At the front of the room (the open part of the U), are a whiteboard, fl ip chart, and/or overhead projector for use by the facilitator leading the discussion.

FIGURE 3-6 Interview Report

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 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 two days of month end; currently, information is provided to them after a three-week delay)

2. The data are of poor quality (often reports must be reconciled with departmental HR database)

• The most common data errors found in the current system include incorrect job level information and missing salary information.

Open Items:

• Get current employee roster report from Mary Skudrna (extension 4355).

• Verify calculations used to determine vacation time with Mary Skudrna.

• Schedule interview with Jim Wack (extension 2337) regarding the reasons for data quality problems.

Detailed Notes: See attached transcript.

10 See Kevin Strehlo, “Catching up with the Jones and ‘Requirement’ Creep,” Infoworld (July 29, 1996); Kevin Strehlo, “Th e Makings of a Happy Customer: Specifying Project X,” Infoworld (November 11, 1996).

JAD suff ers from the traditional problems associated with groups: Sometimes people are reluctant to challenge the opinions of others (particularly their boss), a few people oft en dominate the discussion, and not everyone participates. In a fi ft een-member group, for exam- ple, if everyone participates equally, then each person can talk for only four minutes each hour and must listen for the remaining fi ft y-six minutes—not a very effi cient way to collect information.

A new form of JAD called electronic JAD, or e-JAD, attempts to overcome these prob- lems by using groupware. In an e-JAD meeting room, each participant uses special soft ware on a networked computer to send anonymous ideas and opinions to everyone else. In this way, all participants can contribute at the same time without fear of reprisal from people with diff ering opinions. Initial research suggests that e-JAD can reduce the time required to run JAD sessions by 50 to 80 percent.11 A good JAD approach follows a set of fi ve steps.

JAD participants are selected in the same way as are interview participants, based on the information they can contribute in order to provide a broad mix of organizational levels and to build political support for the new system. Th e need for all JAD participants to be away from their offi ce at the same time can be a major problem. Th e offi ce might need to be closed or operate with a skeleton staff until the JAD sessions are complete.

11 For 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 15, no. 4 (1999): 115–142.

1. Select Participants

1 0 2 C h a p t e r 3 Requirements Determination

Interpersonal skills are skills that enable you to develop rapport with others, and they are very important for interviewing. They help you to communicate with others effectively. Some people develop good interpersonal skills at an early age; they simply seem to know how to communicate and interact with others. Other people are less lucky and need to work hard to develop their skills.

Interpersonal skills, like most skills, can be learned. Here are some tips:

• Don’t worry, be happy. Happy people radiate con- fi dence and project their feelings on others. Try inter- viewing someone while smiling and then interviewing someone else while frowning and see what happens.

• Pay attention. Pay attention to what the other person is saying (which is harder than you might think). See how many times you catch yourself with your mind on something other than the conversation at hand.

• Summarize key points. At the end of each major theme or idea that someone explains, repeat the key points back to the speaker (e.g., Let me make sure I

understand. The key issues are. . . .”). This demon- strates that you consider the information important, and it also forces you to pay attention (you can’t repeat what you didn’t hear).

• Be succinct. When you speak, be succinct. The goal in interviewing (and in much of life) is to learn, not to impress. The more you speak, the less time you give to others.

• Be honest. Answer all questions truthfully, and if you don’t know the answer, say so.

• Watch body language (yours and theirs). The way a person sits or stands conveys much information. In general, a person who is interested in what you are saying sits or leans forward, makes eye contact, and often touches his or her face. A person leaning away from you or with an arm over the back of a chair is uninterested. Crossed arms indicate defensiveness or uncertainty, and steepling (sitting with hands raised in front of the body with fi ngertips touching) indi- cates a feeling of superiority.

3-1 Developing Interpersonal SkillsPRACTICAL

TIP

Requirements-Gathering Techniques 103

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).

Th e facilitator should be someone who is an expert in JAD or e-JAD techniques and, ideally, someone who has experience with the business under discussion. In many cases, the JAD facilitator is a consultant external to the organization because the organization might not have a recurring need for JAD or e-JAD expertise. Developing and maintaining this expertise in-house can be expensive.

JAD sessions can run from as little as half a day to several weeks, depending upon the size and scope of the project. In our experience, most JAD sessions tend to last fi ve to ten days, spread over a three-week period. Most e-JAD sessions tend to last one to four days in a one-week period. JAD and e-JAD sessions usually go beyond collecting information and move into anal- ysis. For example, the users and the analysts collectively can create analysis deliverables, such as the functional models or the requirements defi nition.

JAD sessions usually are designed and structured using the same principles as inter- views. Most JAD sessions are designed to collect specifi c information from users, and this requires developing a set of questions before the meeting. One diff erence 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 information. Typically thirty minutes is allocated to each separate agenda item, and frequent breaks are scheduled throughout the day because participants tire easily.

As with interviewing, it is important to prepare the analysts and participants for a JAD session. Because the sessions can go beyond the depth of a typical interview and are usually conducted off -site, participants may be more concerned about how to prepare. It is impor- tant 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 bring procedure manuals and documents with them. If the goal is to identify improvements for a system, then before they come to the JAD session they can think about how they would improve the system.

Most JAD sessions follow a formal agenda, and most have formal ground rules that defi ne appro- priate behavior. Common ground rules include following the schedule, respecting others’ opin- ions, accepting disagreement, and ensuring that only one person talks at a time.

Th e role of a JAD facilitator can be challenging. Many participants come to a JAD session with strong feelings about the system to be discussed. Channeling these feelings so that the ses- sion moves forward in a positive direction and getting participants to recognize and accept—but not necessarily agree on—opinions and situations diff erent from their own requires signifi cant 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 fi rst session.

Th e JAD facilitator performs three key functions. First, he or she ensures that the group sticks to the agenda. Th e 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

4. Conducting a JAD Session

2. Design a JAD Session

3. Preparing for a JAD Session

agenda, the facilitator must be fi rm but polite in leading 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 specifi c analysis techniques used. Participants are experts in their area, or their part of the business, but they are not experts in systems analysis. Th e facilitator must, therefore, minimize the learning required and teach participants how to eff ectively provide the right information.

Th ird, the facilitator records the group’s input on a public display area, which can be a whiteboard, fl ip chart, or computer display. He or she structures the information that the group provides and helps the group recognize key issues and important solutions. Th e facil- itator must remain neutral at all times and simply help the group through the process. Th e moment the facilitator off ers an opinion on an issue, the group will see him or her not 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 they are, the facilitator can combine them and move on. However, if the group decides they are not similar (despite what the facilitator believes), the facilitator should accept the decision and move on. Th e group is always right, and the facilitator has no opinion.

As with interviews, a JAD post-session report is prepared and circulated among session attendees. Th e post-session report is essentially the same as the interview report in Figure 3-6. Because the JAD sessions are longer and provide more information, it usually takes a week or two aft er the JAD session before the report is complete.

Questionnaires A questionnaire is a set of written questions used to obtain information from individ- uals. Questionnaires are oft en used when there is a large number of people from whom information and opinions are needed. In our experience, questionnaires are a common technique with systems intended for use outside the organization (e.g., by customers or vendors) or for systems with business users spread across many geographic locations. Most people automatically think of paper when they think of questionnaires, but today more questionnaires are being distributed in electronic form, either via e-mail or on the Web. Electronic distribution can save a signifi cant amount of money as compared to dis- tributing paper questionnaires. A good process to use when using questionnaires follows four steps.

As with interviews and JAD sessions, the fi rst step is to identify the individuals to whom the questionnaire will be sent. However, it is not usual to select every person who could provide useful information. Th e standard approach is to select a sample, or subset, of people who are representative of an entire group. Sampling guidelines are discussed in most statistics books, and most business schools include courses that cover the topic, so we do not discuss it here. Th e important point in selecting a sample, however, is to realize that not everyone who receives a questionnaire will actually complete it. On average, only 30 to 50 percent of paper and e-mail questionnaires are returned. Response rates for Web-based questionnaires tend to be signifi cantly lower (oft en only 5 to 30 percent).

1 0 4 C h a p t e r 3 Requirements Determination

1. Select Participants

5. Post-JAD Follow-up

Requirements-Gathering Techniques 105

Managing Problems in JAD Sessions

I have run more than a hundred JAD sessions and have learned several standard “facilitator tricks.” Here are some common problems and some ways to deal with them.

• Domination. The facilitator should ensure that no one person dominates the group discussion. The only way to deal with someone who dominates is head on. Dur- ing a break, approach the person, thank him or her for his or her insightful comments, and ask the person to help you make sure that others also participate.

• Noncontributors. Drawing out people who have par- ticipated very little is challenging because you want to bring them into the conversation so that they will contribute again. The best approach is to ask a direct factual question that you are certain they can answer. And it helps to ask the question in a long way to give them time to think. For example, “Pat, I know you’ve worked shipping orders a long time. You’ve probably been in the shipping department longer than anyone else. Could you help us understand exactly what hap- pens when an order is received in shipping?”

• Side discussions. Sometimes participants engage in side conversations and fail to pay attention to the group. The easiest solution is simply to walk close to the people and continue to facilitate right in front of them. Few people will continue a side conversion when you are two feet from them and the entire group’s attention is on you and them.

• Agenda merry-go-round. The merry-go-round occurs when a group member keeps returning to the same issue every few minutes and won’t let go. One solu- tion is to let the person have fi ve minutes to ramble on about the issue while you carefully write down every point on a fl ip chart or computer fi le. This fl ip chart or fi le is then posted conspicuously on the wall. When the person brings up the issue again, you interrupt them, walk to the paper and ask them what to add. If they mention something already on the list,

you quickly interrupt, point out that it is there, and ask what other information to add. Don’t let them repeat the same point, but write any new information.

• Violent agreement. Some of the worst disagreements occur when participants really agree on the issues but don’t realize that they agree because they are using different terms. An example is arguing whether a glass is half empty or half full; they agree on the facts but can’t agree on the words. In this case, the facilitator has to translate the terms into different words and fi nd common ground so the parties rec- ognize that they really agree.

• Unresolved confl ict. In some cases, participants don’t agree and can’t understand how to determine what alternatives are better. You can help by structur- ing the issue. Ask for criteria by which the group will identify a good alternative (e.g., “Suppose this idea really did improve customer service. How would I recognize the improved customer service?”). Then once you have a list of criteria, ask the group to assess the alternatives using them.

• True confl ict. Sometimes, despite every attempt, par- ticipants just can’t agree on an issue. The solution is to postpone the discussion and move on. Document the issue as an open issue and list it prominently on a fl ip chart. Have the group return to the issue hours later. Often the issue will have resolved itself by then and you haven’t wasted time on it. If the issue cannot be resolved later, move it to the list of issues to be decided by the project sponsor or some other more senior member of management.

• Humor. Humor is one of the most powerful tools a facilitator has and thus must be used judiciously. The best JAD humor is always in context; never tell jokes but take the opportunity to fi nd the humor in the situation.

Alan Dennis

PRACTICAL

TIP

Because the information on a questionnaire cannot be immediately clarifi ed for a confused respondent, developing good questions is critical for questionnaires. Questions on question- naires must be very clearly written and leave little room for misunderstanding, so closed-ended questions tend to be most commonly used. Questions must clearly enable the analyst to sep- arate facts from opinions. Opinion questions oft en ask respondents the extent to which they agree or disagree (e.g., Are network problems common?), whereas factual questions seek more

2. Designing a Questionnaire

precise values (e.g., How oft en does a network problem occur: once an hour, once a day, once a week?). See Figure 3-7 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. Th is issue must be addressed before the questionnaire is distributed, because it is too late aft erward.

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 good practice to group related questions together to make them simpler to answer. Some experts suggest that ques- tionnaires 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 oft en seemingly simple questions can be misunderstood.

Th e 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, off ering an inducement to complete the ques- tionnaire (e.g., a free pen), and off ering to supply a summary of the questionnaire responses. Systems analysts have additional techniques to improve response rates inside the organiza- tion, such as personally handing out the questionnaire and personally contacting those who have not returned them aft er a week or two, as well as requesting the respondents’ supervisors to administer the questionnaires in a group meeting.

It is helpful to process the returned questionnaires and develop a questionnaire report soon aft er the questionnaire deadline. Th is ensures that the analysis process proceeds in a timely fashion and that respondents who requested copies of the results receive them promptly.

Document Analysis Project teams oft en use document analysis to understand the as-is system. Under ideal cir- cumstances, the project team that developed the existing system will have produced docu- mentation that was then updated by all subsequent projects. In this case, the project team can start by reviewing the documentation and examining the system itself.

Unfortunately, many systems are not well documented because project teams fail to document their projects along the way, and when the projects are over, there is no time to go back and document. Th erefore, there might not be much technical documentation about the current systems available, or it might not contain updated information about recent sys- tem changes. However, many helpful documents do exist in an organization: paper reports,

3. Administering the Questionnaire

4. Questionnaire Follow-up

1 0 6 C h a p t e r 3 Requirements Determination

• 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. • Pretest the questionnaire to identify confusing questions. • Provide anonymity to respondents.

FIGURE 3-7 Good Questionnaire Design

memorandums, policy manuals, user-training manuals, organization charts, forms, and, of course, the user interface with the existing system.

But these documents tell only part of the story. Th ey represent the formal system that the organization uses. Quite oft en, the real, or informal, system diff ers from the formal one, and these diff erences, particularly large ones, give strong indications of what needs to be changed. For example, forms or reports that are never used should probably be eliminated. Likewise, boxes or questions on forms that are never fi lled in (or are used for other purposes) should be rethought. See Figure 3-8 for an example of how a document can be interpreted.

Th e most powerful indication that the system needs to be changed is when users create their own forms or add additional information to existing ones. Such changes clearly demonstrate the need for improvements to existing systems. Th us, it is useful to review both blank and completed forms to identify these deviations. Likewise, when users access multiple reports to satisfy their information needs, it is a clear sign that new information or new infor- mation formats are needed.

Name: Buffy Pat Smith

Pet’s Name: Buffy Collie 7/6/99

Address: 100 Central Court. Apartment 10

Toronto, Ontario K7L 3N6

Phone Number: 555-3400

416-

Do you have insurance: yes

Insurance Company: Pet’s Mutual

Policy Number: KA-5493243

CENTRAL VETERINARY CLINIC Patient Information Card

The staff had to add additional information about the type of animal and the animal’s date of birth. This information should be added to the new form in the to-be system.

The customer made a mistake. This should be labeled Owner’s Name to prevent confusion.

The customer did not include area code in the phone number. This should be made more clear.

FIGURE 3-8 Performing a Document Analysis

Requirements-Gathering Techniques 107

Observation Observation, the act of watching processes being performed, is a powerful tool for gathering information about the as-is system because it enables the analyst to see the reality of a situa- tion, rather than listening to others describe it in interviews or JAD sessions. Several research studies have shown that many managers really do not remember how they work and how they allocate their time. (Quick, how many hours did you spend last week on each of your courses?) Observation is a good way to check the validity of information gathered from indi- rect sources such as interviews and questionnaires.

In many ways, the analyst becomes an anthropologist as he or she walks through the organization and observes the business system as it functions. Th e goal is to keep a low pro- fi le, to not interrupt those working, and to not infl uence those being observed. Nonetheless, it is important to understand that what analysts observe may not be the normal day-to-day routine because people tend to be extremely careful in their behavior when they are being watched. Even though normal practice may be to break formal organizational rules, the observer is unlikely to see this. (Remember how you drove the last time a police car followed you?) Th us, what you see might not be what you get.

Observation is oft en used to supplement interview information. Th e location of a person’s offi ce and its furnishings give clues to the person’s power and infl uence in the organization and can be used to support or refute information given in an interview. For example, an analyst might become skeptical of someone who claims to use the existing computer system exten- sively if the computer is never turned on while the analyst visits. In most cases, observation supports the information that users provide in interviews. When it does not, it is an important signal that extra care must be taken in analyzing the business system.

Selecting the Appropriate Techniques Each of the requirements-gathering techniques discussed earlier has strengths and weak- nesses. No one technique is always better than the others, and in practice most projects use a combination of techniques. Th us, it is important to understand the strengths and weaknesses of each technique and when to use each (see Figure 3-9). One issue not discussed is that of the analysts’ experience. In general, document analysis and observation require the least amount of training, whereas JAD sessions are the most challenging.

Type of Information Th e fi rst characteristic is the type of information. Some techniques are more suited for use at diff erent stages of the analysis process, whether understanding the as-is system, identifying improvements, or developing the to-be system. Interviews and JAD are commonly used in all three stages. In contrast, document analysis and observation usually are most helpful for understanding the as-is, although occasionally they provide information about

FIGURE 3-9 Table of Requirements-Gathering Techniques

Type of information As-is, improvements, As-is, improvements, As-is, improvements As-is As-is to-be to-be

Depth of information High High Medium Low Low

Breadth of information Low Medium High High Low

Integration of information Low High Low Low Low

User involvement Medium High Low Low Low

Cost Medium Low to Medium Low Low Low to Medium

Joint Application Document Interviews Design Questionnaires Analysis Observation

1 0 8 C h a p t e r 3 Requirements Determination

current problems that need to be improved. Questionnaires are oft en used to gather informa- tion about the as-is system as well as general information about improvements.

Depth of Information Th e depth of information refers to how rich and detailed the infor- mation is that the technique usually produces and the extent to which the technique is useful for obtaining not only facts and opinions but also an understanding of why those facts and opinions exist. Interviews and JAD sessions are very useful for providing a good depth of rich and detailed information and helping the analyst to understand the reasons behind them. At the other extreme, document analysis and observation are useful for obtaining facts, but little beyond that. Questionnaires can provide a medium depth of information, soliciting both facts and opinions with little understanding of why they exist.

Breadth of Information Breadth of information refers to the range of information and infor- mation sources that can be easily collected using the chosen technique. Questionnaires and document analysis are both easily capable of soliciting a wide range of information from a large number of information sources. In contrast, interviews and observation require the analyst to visit each information source individually and, therefore, take more time. JAD sessions are in the middle because many information sources are brought together at the same time.

Integration of Information One of the most challenging aspects of requirements gather- ing is integrating the information from diff erent sources. Simply put, diff erent people can provide confl icting information. Combining this information and attempting to resolve diff erences in opinions or facts is usually very time consuming because it means contacting each information source in turn, explaining the discrepancy, and attempting to refi ne the information. In many cases, the individual wrongly perceives that the analyst is challenging his or her information, when in fact it is another user in the organization who is doing so. Th is can make the user defensive and make it hard to resolve the diff erences.

All techniques suff er integration problems to some degree, but JAD sessions are designed to improve integration because all information is integrated when it is collected, not aft er- ward. If two users provide confl icting information, the confl ict becomes immediately obvi- ous, as does the source of the confl ict. Th e immediate integration of information is the single most important benefi t of JAD that distinguishes it from other techniques, and this is why most organizations use JAD for important projects.

User Involvement User involvement refers to the amount of time and energy the intended users of the new system must devote to the analysis process. It is generally agreed that as users become more involved in the analysis process, the chance of success increases. However, user involvement can have a signifi cant cost, and not all users are willing to contribute valuable time and energy. Questionnaires, document analysis, and observation place the least burden on users, whereas JAD sessions require the greatest eff ort.

Cost Cost is always an important consideration. In general, questionnaires, document analysis, and observation are low-cost techniques (although observation can be quite time consuming). Th e low cost does not imply that they are more or less eff ective than the other techniques. Interviews and JAD sessions generally have moderate costs. In general, JAD ses- sions are much more expensive initially, because they require many users to be absent from their offi ces for signifi cant periods of time, and they oft en involve highly paid consultants. However, JAD sessions signifi cantly reduce the time spent in information integration and thus can cost less in the long term.

Combining Techniques In practice, requirements gathering combines a series of diff erent tech- niques. Most analysts start by using interviews with senior manager(s) to gain an understanding of the project and the big-picture issues. From these interviews, it becomes clear whether large or small changes are anticipated. Th ese interviews are oft en followed with analysis of documents

Requirements-Gathering Techniques 109

12 See B. Henderson-Sellers, A. Simons, and H. Younessi, Th e OPEN Toolbox of Techniques (Harlow, England: Addison-Wesley, 1998). 13 For more information on concept mapping, see J. D. Novak and D. B. Gowin, Learning How to Learn (Cambridge, UK: Cambridge University Press, 1984); J. D. Novak, Learning, Creating, and Using Knowledge: Concept MapsTM as Facilitative Tools in Schools and Corporations (Mahwah, NJ: Lawrence Erlbaum Associates, Publishers, 1998). Also, a free concept mapping tool is available from the Institute of Human and Machine Cognition at cmap.ihmc.us.

1 1 0 C h a p t e r 3 Requirements Determination

and policies to gain some understanding of the as-is system. Usually interviews come next to gather the rest of the information needed for the as-is picture.

In our experience, identifying improvements is most commonly done using JAD sessions because the JAD session enables the users and key stakeholders to work together through an analysis technique and come to a shared understanding of the possibilities for the to-be sys- tem. Occasionally, these JAD sessions are followed by questionnaires sent to a much wider set of users or potential users to see whether the opinions of those who participated in the JAD sessions are widely shared.

Developing the concept for the to-be system is oft en done through interviews with senior managers, followed by JAD sessions with users of all levels to make sure that the key needs of the new system are well understood.

ALTERNATIVE REQUIREMENTS DOCUMENTATION TECHNIQUES Some other very useful requirements-gathering and documentation techniques include throwaway prototyping, use cases, role-playing CRC cards with use-case-based scenarios, concept mapping, and recording user stories on story cards and task lists. Th rowaway pro- totyping was described in Chapter 1. In essence, throwaway prototypes are created to better understand some aspect of the new system. In many cases, they are used to test out some technical aspect of a nonfunctional requirement, such as connecting a client workstation to a server. If you have never done this before, it will be a lot easier to develop a very small example system to test out the necessary design of the connection from the client workstation to the server instead of trying to do it the fi rst time with the full-blown system. Th rowaway proto- typing is very useful in designing user interfaces (see Chapter 10).

Use cases, as described in Chapter 1, are the fundamental approach that the Unifi ed Process and Unifi ed Modeling Language (UML) use to document and gather functional requirements. We describe them in Chapter 4. Role-playing CRC cards with use-case-based scenarios are very useful when creating functional (see Chapter 4), structural (see Chapter 5), and behavioral (see Chapter 6) models. We describe this approach in Chapter 5. Th e remainder of this section describes the use of concept mapping recording user stories on story cards and task lists.

Concept Maps Concept maps represent meaningful relationships between concepts. Th ey are useful for focusing individuals on the small number of key ideas on which they should concentrate. A concept map is essentially a node-and-arc representation, where the nodes represent the individual requirements and the arcs represent the relationships among the requirements. Each arc is labeled with a relationship name. Concept maps also have been recommended as a possible technique to support modeling requirements for object-oriented systems develop- ment and knowledge-management systems.12 Concept mapping is an educational psychology technique that has been used in schools, corporations, and health care agencies to facilitate learning, understanding, and knowledge creation.13 Th e advantage of the concept-mapping approach to representing requirements over the typical textual approach (see Figure 3-1) is that a concept map is not limited to a hierarchical representation. Concept maps allow the rela- tionships among the functional and nonfunctional requirements to be explicitly represented. Figure 3-10 shows a concept map that portrays the information contained in the requirements

R eq

u ir

em en

C u lt

u ra

l an

d Po

li ti

ca l

R eq

u ir

em en

N o n fu

n ct

io n al

R eq

u ir

em en

ts Se

cu ri

ty R

eq u ir

em en

O p er

at io

n al

R eq

u ir

em en

Pe rf

o rm

an ce

R eq

u ir

em en

B ac

ku p S

ch ed

u le

D ai

Su p p o rt

W ir

el es

s P ri

n ti

n g

St o re

N ew

A p p o in

tm en

t in

2 S

ec o n d s

o r

Le ss

R et

ri ev

e D

ai ly

A p p o in

tm en

t Sc

h ed

u le

i n 2

Se co

n d s

o r

Le ss

O p er

at e

in W

in d o w

s En

vi ro

n m

en t

M ak

e A

p p o in

tm en

t C

an ce

l A p p o in

tm en

t P ri

n t

Sc h ed

u le

U p d at

e Sc

h ed

u le

C h ec

k Sc

h ed

u le

C h an

ge A

p p o in

tm en

M an

ag e

A p p o in

tm en

ts P ro

d u ce

S ch

ed u le

Fu n ct

io n al

R eq

u ir

em en

R ec

o rd

D o ct

o r

A va

il ab

il it

O n ly

M an

ag er

s C

an P ro

d u ce

S ch

ed u le

O n ly

D o ct

o rs

S et

A va

il ab

il it

y im

p ac

im p ac

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

in cl

u d e

F IG

U R

E 3

-1 0

S am

p le

R e

q u

ir e

m e

n ts

C o

n ce

p t

M ap

111

defi nition shown in Figure 3-1. By using a concept map to represent the requirements instead of the textual approach, the relationship between the functional and nonfunctional require- ments can be made explicit. For example, the two security requirements Only Doctors Set Availability and Only Managers Can Produce Schedule are explicitly linked to the Record Doctor Availability and Produce Schedule functional requirements, respectively. Th is is very diffi cult to represent in a text-only version of the requirements defi nition. Also, by having the user and analyst focus on the graphical layout of the map, additional requirements can be discovered. One obvious issue with this approach is that if the number of requirements becomes many and the relationships between them become complex, then the number of nodes and arcs will become so intertwined that the advantage of being able to explicitly see the relationships will be lost. However, by combining both text and concept-map representations, it is possible to leverage the strength of both textual and graphical representations to more completely represent the requirements.

User Stories User stories, along with their associated story cards and task lists, are associated with the agile development approaches. User stories have been shown to be very useful in gathering requirements in a nonthreatening manner that respects the user’s point of view. Th ey are typically captured using story cards (index cards) and are recorded on a task list (or from a Scrum perspective, on the product backlog). Both story cards and task lists are considered to be lightweight approaches to documenting and gathering requirements.14 Stories capture both functional and nonfunctional requirements. For example, with regard to the doctor’s offi ce appointment example, a functional requirement-based story could be:

As a secretary, I want to be able to schedule appointments for our patients so that we can meet our patients’ needs.

While an operational nonfunctional requirement-based story could be:

As a secretary, I want to be able to print the daily schedule using wireless technology so that all printing can be performed using a shared printer without having to deal with printer cables connecting all of the computers to the printer.

Once the story is written down, it is discussed to determine the amount of eff ort it will take to implement it. During the discussion, a task list is created for the story. If the story is deemed to be too large—e.g., there are too many tasks on the task list—the story is split up into multiple stories each being recorded on its own story card and the tasks are allocated across the new stories. In many shops, once a set of tasks has been identifi ed with a story, the story and its tasks are taped on a wall together so that all members of the development team can see the requirements. Th e story can be prioritized by importance by placing a rat- ing on the card. Th e story can also be evaluated for the level of risk associated with it. Th e importance level and amount of risk associated with the story can be used to help choose which requirements to implement fi rst. Th e advantage of using story cards and task lists to document requirements is that they are very low tech, high touch, easily updatable, and very portable.

1 1 2 C h a p t e r 3 Requirements Determination

14 For more information on story cards and task lists see M. Cohn, User Stories Applied: For Agile Soft ware Development (Boston, MA: Addison-Wesley, 2004); B. Rinzler, Telling Stories: A Short Path to Writing Better Soft ware Requirements (Indianapolis, IN: Wiley, 2009); M. Lippert, S. Roock, H. Wolf, eXtreme Programming in Action: Practical Experiences from Real World Projects (Chichester, England: Wiley & Sons, Ltd., 2002); C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston, MA: Addison-Wesley, 2004).

1. Table of Contents

2. Executive Summary

A summary of all the essential information in the proposal so that a busy executive can read it quickly and decide what parts of the proposal to read in more depth.

3. System Request

The revised system request form (see Chapter 2).

4. Workplan

The original workplan, revised after having completed analysis (see Chapter 2).

5. Feasibility Analysis

A revised feasibility analysis, using the information from analysis (see Chapter 2).

6. Requirements Defi nition

A list of the functional and nonfunctional business requirements for the system (this chapter).

7. Functional Model

An activity diagram, a set of use-case descriptions, and a use-case diagram that illustrate the basic processes or external functionality that the system needs to support (see Chapter 4).

8. Structural Models

A set of CRC cards, class diagram, and object diagrams that describe the structural aspects of the to-be system (see Chapter 5). This may also include structural models of the current as-is system that will be replaced.

9. Behavioral Models

A set of sequence diagrams, communication diagrams, behavioral-state machines, and a CRUDE matrix that describe the internal behavior of the to-be system (see Chapter 6). This may include behavioral models of the as-is system that will be replaced.

10. Appendices

These contain additional material relevant to the proposal, often used to support the recommended system. This might include results of a questionnaire survey or interviews, industry reports and statistics, and so on.

FIGURE 3-11 System Proposal Template

15 Depending on the client, much more detailed specifi cations may be required; for example the Department of Defense, NASA, IEEE/ANSI, and the Naval Research Laboratory all have very specifi c formats that must be followed. For more information on these more detailed specifi cations, see A. M Davis, Soft ware Requirements, Revision (Upper Saddle River, NJ: Prentice Hall, 1993); G. Kotonya and I. Sommerville, Requirements Engineering (Chichester, England: Wiley, 1998); R. H. Th ayer and M. Dorfman (eds.), Soft ware Requirements Engineering, 2nd Ed. (Los Alamitos, CA: IEEE Computer Society Press, 1997).

THE SYSTEM PROPOSAL A system proposal brings together into a single comprehensive document the material created during planning and analysis. Th e system proposal typically includes an executive summary, the system request, the workplan, the feasibility analysis, the requirements defi nition, and the evolving models that describe the new system. Th e evolving models include functional models (see Chapter 4), structural models (see Chapter 5), and behavioral models (see Chapter 6).15 Th e executive summary provides all critical information in a very concise form. It can be thought of as a summary of the complete proposal. Its purpose is to allow a busy executive to quickly read through it and determine which parts of the proposal he or she needs to go through more thoroughly. Th e executive summary is typically no more than a single page long. Figure 3-11 provides a template for a system proposal and references to where the other sections of the proposal are described.

The System Proposal 113

CHAPTER REVIEW Aft er reading and studying this chapter, you should be able to:

Create a requirements defi nition. Diff erentiate between a functional and a nonfunctional requirement. Discuss the problem analysis requirements strategy. Discuss the root cause analysis requirements strategy. Discuss the duration analysis requirements strategy. Discuss the activity-based costing analysis requirements strategy. Discuss the informal benchmarking analysis requirements strategy. Discuss the outcome analysis requirements strategy. Discuss the technology analysis requirements strategy. Discuss the activity elimination requirements strategy. Discuss how to use interviews to gather requirements. Discuss how to use joint application development to gather requirements. Discuss how to use questionnaires to gather requirements. Discuss how to use document analysis to gather requirements. Discuss how to use observation to gather requirements. Describe how to use concept maps to document requirements. Describe how to use story cards and task lists to document requirements. Describe the purpose and contents of system proposal.

KEY TERMS

Activity elimination Activity-based costing Analysis As-is system Benchmarking

Bottom-up interview Breadth of analysis Business requirements Closed-ended question Concept mapping

Concept maps Critical thinking skills Document analysis Duration analysis Electronic JAD (e-JAD)

Facilitator Formal system Functional requirements Ground rules Informal benchmarking

1 1 4 C h a p t e r 3 Requirements Determination

APPLYING THE CONCEPTS AT PATTERSON SUPERSTORE Chapter 3 introduced requirements determination for object-oriented systems develop- ment projects. Determining the system’s requirements is the most important activity in the systems development process. A requirement is WHAT the system must do or WHAT characteristics it must have. If the requirements are not fully or correctly defi ned, the sys- tem developed is unlikely to meet the needs of the user. In other words, if the requirements are wrong, the system will be wrong.

In this chapter’s installment of the Patterson Superstore case, we see the require- ments analysis and requirement-gathering techniques that the analysts used to determine requirements for Version 1 of the Integrated Health Clinic Delivery System. We also see the functional and nonfunctional requirements that were developed and an initial draft of the developing systems proposal for the project. Th is systems proposal will be fi nalized aft er the functional (Chapter 4), structural (Chapter 5), and behavioral (Chapter 6) modeling of the system has been completed.

You can fi nd the rest of the case at: www.wiley.com/go/dennis/casestudy

Informal system Interpersonal skills Interview Interview notes Interview report Interview schedule JAD (joint application

development) Nonfunctional requirements Observation

Open-ended question Outcome analysis Parallelization Process Integration Post-session report Potential business value Probing question Problem analysis Project cost Questionnaire

Requirement Requirements defi nition Requirements

determination Risk Root cause Root cause analysis Sample Scribe Story cards

Structured interview System proposal System requirements Task lists, 144 Technology analysis To-be system Top-down interview Unstructured interview User stories Walkthrough

QUESTIONS

1. What are the key deliverables that are created during analysis? What is the fi nal deliverable from analysis, and what does it contain?

2. What is the diff erence between an as-is system and a to-be system?

3. What is the purpose of the requirements defi nition? 4. What are the three basic steps of the analysis process?

Which step is sometimes skipped or done in a cursory fashion? Why?

5. Compare and contrast problem analysis and root cause analysis. Under what conditions would you use problem analysis? Under what conditions would you use root cause analysis?

6. Compare and contrast duration analysis and activity- based costing.

7. Describe the fi ve major steps in conducting interviews. 8. Explain the diff erences among a closed-ended ques-

tion, an open-ended question, and a probing question. When would you use each?

9. Explain the diff erences between unstructured inter- views and structured interviews. When would you use each approach?

10. Explain the diff erence between a top-down and bottom-up interview approach. When would you use each approach?

11. How are participants selected for interviews and JAD sessions?

12. How can you diff erentiate between facts and opinions? Why can both be useful?

13. Describe the fi ve major steps in conducting JAD sessions.

14. How does a JAD facilitator diff er from a scribe? 15. What are the three primary things that a facilitator

does in conducting the JAD session? 16. What is e-JAD, and why might a company be inter-

ested in using it? 17. How does designing questions for questionnaires diff er

from designing questions for interviews or JAD sessions? 18. What are typical response rates for questionnaires,

and how can you improve them? 19. What is document analysis? 20. How does the formal system diff er from the informal

system? How does document analysis help you under- stand both?

21. What are the key aspects of using observation in the information-gathering process?

22. Explain factors that can be used to select information- gathering techniques.

23. What is the primary advantage that concept maps have over traditional textual requirements documents techniques?

24. What are some of the advantages of using story cards and task lists as a requirements-gathering and docu- mentation technique?

25. What information is typically included in a system proposal?

26. What is the purpose of the executive summary of the system proposal?

EXERCISES

A. Review the Amazon.com website. Develop the requirements defi nition for the site. Create a list of functional business requirements that the system meets. What diff erent kinds of nonfunctional business

requirements does the system meet? Provide exam- ples for each kind.

B. Suppose you are going to build a new system that auto- mates or improves the interview process for the career

Exercises 115

services department of your school. Develop a require- ments defi nition for the new system. Include both functional and nonfunctional system requirements. Pretend you will release the system in three diff erent versions. Prioritize the requirements accordingly.

C. Describe in very general terms the as-is business process for registering for classes at your university. Collaborate with another student in your class, and evaluate the process using problem analysis and root cause analysis. Based on your work, list some improve- ments that you have identifi ed.

D. Describe in very general terms the as-is business pro- cess for applying for admission at your university. Collaborate with another student in your class, and evaluate the process using informal benchmarking. Based on your work, list some improvements that you have identifi ed.

E. Describe in very general terms the as-is business process for registering for classes at your university. Collaborate with another student in your class, and evaluate the process using activity elimination. Based on your work, list some improvements that you have identifi ed.

F. Suppose your university is having a dramatic increase in enrollment and is having diffi culty fi nding enough seats in courses for students. Perform a technology analysis to identify new ways to help students com- plete their studies and graduate.

G. Suppose you are the analyst charged with developing a new system for the university bookstore so that students can order books online and have them delivered to their dorms or off -campus housing. What requirements- gathering techniques will you use? Describe in detail how you would apply the techniques.

H. Suppose you are the analyst charged with developing a new system to help senior managers make bet- ter strategic decisions. What requirements-gathering techniques will you use? Describe in detail how you would apply the techniques.

I. Find a partner and interview each other about what tasks each did in the last job you held (full-time, part-time, past, or current). If you haven’t worked before, then assume your job is being a student. Before you do this, develop a brief interview plan. Aft er your partner interviews you, identify the type of interview, interview approach, and types of ques- tions used.

J. Find a group of students and run a sixty-minute JAD session on improving alumni relations at your university. Develop a brief JAD plan, select two tech- niques that will help identify improvements, and then develop an agenda. Conduct the session using the agenda, and write your post-session report.

K. Find a questionnaire on the Web that has been created to capture customer information. Describe the pur- pose of the survey, the way questions are worded, and how the questions have been organized. How can it be improved? How will the responses be analyzed?

L. Develop a questionnaire that will help gather infor- mation regarding processes at a popular restaurant or the college cafeteria (e.g., ordering, customer ser- vice). Give the questionnaire to ten to fi ft een students, analyze the responses, and write a brief report that describes the results.

M. Contact the career services department at your uni- versity, and fi nd all the pertinent documents designed to help students fi nd permanent and/or part-time jobs. Analyze the documents and write a brief report.

MINICASES

1. Th e State Firefi ghter’s Association has a membership of 15,000. Th e purpose of the organization is to pro- vide some fi nancial support to the families of deceased member fi refi ghters and to organize a conference each year bringing together fi refi ghters from all over the state. Members are billed dues and calls annually. Calls are additional funds required to take care of payments made to the families of deceased members. Th e bookkeeping work for the association is handled by the elected treasurer, Bob Smith, although it is widely known that his wife, Laura, does all the work.

Bob runs unopposed each year at the election, because no one wants to take over the tedious and time- consuming job of tracking memberships. Bob is paid a stipend of $8,000 per year, but his wife spends well over twenty hours per week on the job. Th e organiza- tion, however, is not happy with their performance.

A computer system is used to track the billing and receipt of funds. Th is system was developed in 1984 by a computer science student and his father. Th e system is a DOS-based system written using dBase 3. Th e most immediate problem facing the treasurer and

1 1 6 C h a p t e r 3 Requirements Determination

his wife is the fact that the soft ware package no longer exists, and there is no one around who knows how to maintain the system. One query, in particular, takes seventeen hours to run. Over the years, they have just avoided running this query, although the information in it would be quite useful. Questions from mem- bers concerning their statements cannot easily be answered. Usually Bob or Laura just jots down the inquiry and returns a call with the answer. Sometimes it takes three to fi ve hours to fi nd the information needed to answer the question. Oft en, they have to perform calculations manually because the system was not programmed to handle certain types of que- ries. When member information is entered into the system, each fi eld is presented one at a time, which makes it very diffi cult to return to a fi eld and correct a value that was entered. Sometimes a new member is entered but disappears from the records. Th e report of membership used in the conference materials does not alphabetize members by city. Only cities are listed in the correct order.

What requirements analysis strategy or strategies would you recommend for this situation? Explain your answer.

2. Brian Callahan, IS project manager, is just about ready to depart for an urgent meeting called by Joe Campbell, manager of manufacturing operations. A major project sponsored by Joe recently cleared the approval hurdle, and Brian helped bring the project through project initiation. Now that the approval committee has given the go-ahead, Brian has been working on the project’s analysis plan.

One evening, while playing golf with a friend who works in the manufacturing operations department, Brian learned that Joe wants to push the project’s time frame up from Brian’s original estimate of thirteen months. Brian’s friend overheard Joe say, “I can’t see why that IS project team needs to spend all that time analyzing things. Th ey’ve got two weeks scheduled just to look at the existing system! Th at seems like a real waste. I want that team to get going on building my system.”

Because Brian has a little inside knowledge about Joe’s agenda for this meeting, he has been considering how to handle Joe. What do you suggest Brian tell Joe?

3. Barry has recently been assigned to a project team that will be developing a new retail store management sys- tem for a chain of submarine sandwich shops. Barry has several years of experience in programming, but he has not done much analysis in his career. He was a

little nervous about the new work he would be doing, but he was confi dent he could handle any assignment he was given.

One of Barry’s fi rst assignments was to visit one of the submarine sandwich shops and prepare an observation report on how the store operates. Barry planned to arrive at the store around noon, but he chose a store in an area of town he was unfamiliar with, and due to traffi c delays and diffi culty in fi nd- ing the store, he did not arrive until 1:30. Th e store manager was not expecting him and refused to let a stranger behind the counter until Barry had her contact the project sponsor (the director of store management) at company headquarters to verify who he was and what his purpose was.

Aft er fi nally securing permission to observe, Barry stationed himself prominently in the work area behind the counter so that he could see everything. Th e staff had to maneuver around him as they went about their tasks, but there were only minor occa- sional collisions. Barry noticed that the store staff seemed to be going about their work very slowly and deliberately, but he supposed that was because the store wasn’t very busy. At fi rst, Barry questioned each worker about what he or she was doing, but the store manager eventually asked him not to interrupt their work so much—he was interfering with their service to the customers.

By 3:30, Barry was a little bored. He decided to leave, fi guring he could get back to the offi ce and prepare his report before 5:00 that day. He was sure his team leader would be pleased with his quick completion of his assignment. As he drove, he refl ected, “Th ere really won’t be much to say in this report. All they do is take the order, make the sandwich, collect the payment, and hand over the order. It’s really simple!” Barry’s confi dence in his analytical skills soared as he anticipated his team leader’s praise.

Back at the store, the store manager shook her head, commenting to her staff , “He comes here at the slowest time of day on the slowest day of the week. He never even looked at all the work I was doing in the back room while he was here—summarizing yester- day’s sales, checking inventory on hand, making up resupply orders for the weekend . . . plus he never even considered our store-opening and -closing procedures. I hate to think that the new store management system is going to be built by someone like that. I’d better contact Chuck [the director of store management] and let him know what went on here today.”

Minicases 117

1 1 8 C h a p t e r 3 Requirements Determination

Evaluate Barry’s conduct of the observation assignment.

4. Anne has been given the task of conducting a survey of sales clerks who will be using a new order-entry sys- tem being developed for a household products catalog company. Th e goal of the survey is to identify the clerks’ opinions on the strengths and weaknesses of the current system. Th ere are about 50 clerks who work in three diff erent cities, so a survey seemed like an ideal way of gathering the needed information from the clerks.

Anne developed the questionnaire carefully and pretested it on several sales supervisors who were available at corporate headquarters. Aft er revising it based on their suggestions, she sent a paper version of the questionnaire to each clerk, asking that it be

returned within one week. Aft er one week, she had only three completed questionnaires returned. Aft er another week, Anne received just two more completed questionnaires. Feeling somewhat desperate, Anne then sent out an e-mail version of the questionnaire, again to all the clerks, asking them to respond to the questionnaire by e-mail as soon as possible. She received two e-mail questionnaires and three mes- sages from clerks who had completed the paper ver- sion expressing annoyance at being bothered with the same questionnaire a second time. At this point, Anne has just a 14 percent response rate, which she is sure will not please her team leader. What suggestions do you have that could have improved Anne’s response rate to the questionnaire?