How to conduct a jad session

86

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

OBJECTIVES

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

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

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

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

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

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

C H A P T E R 3

Requirements Determination

Copyright © 2015 John Wiley & Sons, Inc.

Requirements Determination 87

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

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

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

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

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

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

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

Copyright © 2015 John Wiley & Sons, Inc.

88 Chapter 3 Requirements Determination

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

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

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

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

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

Copyright © 2015 John Wiley & Sons, Inc.

Requirements Determination 89

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

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

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

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

Sometimes business requirements are prioritized on the requirements defi nition. Th ey can be ranked as having high, medium, or low importance in the new system, or they can be labeled with the version of the system that will address the requirement (e.g., release 1, release 2, release 3). Th is practice is particularly important when using object-oriented meth- odologies since they deliver systems in an incremental manner.

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

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

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

Copyright © 2015 John Wiley & Sons, Inc.

90 Chapter 3 Requirements Determination

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

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

Functional Requirements

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

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

3. Record Doctor Availability 3.1. Doctor updates schedule

Nonfunctional Requirements

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

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

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

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

FIGURE 3-1 Sample Requirements Defi nition

Copyright © 2015 John Wiley & Sons, Inc.

Requirements Determination 91

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

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

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

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

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

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

Copyright © 2015 John Wiley & Sons, Inc.

92 Chapter 3 Requirements Determination

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

Sometimes the fi rst step (i.e., understanding the as-is system) is skipped or is performed in a cursory manner. Th is happens when no current system exists, if the existing system and processes are irrelevant to the future system, or if the project team is using a RAD or agile development methodology in which the as-is system is not emphasized. Newer RAD, agile, and object-oriented methodologies, such as phased development, prototyping, throwaway prototyping, extreme pro- gramming, and Scrum (see Chapter 1) focus almost exclusively on improvements and the to-be system requirements, and they spend little time investigating the current as-is system.

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

To move the users from the as-is system to the to-be system, an analyst needs strong critical thinking skills. Critical thinking is the ability to recognize strengths and weaknesses and recast an idea in an improved form, and critical thinking skills are needed to really under- stand issues and develop new business processes. Th ese skills are also needed to thoroughly examine the results of requirements gathering, to identify business requirements, and to translate those requirements into a concept for the new system.

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

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

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

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

Copyright © 2015 John Wiley & Sons, Inc.

Requirements Analysis Strategies 93

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

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

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

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

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

Frequent Inventory Stock-Outs

Order Approval Late

Identifying Vendor Delayed

Delay in Sending Order to Vendor

Delays in Order Processing

Late Recording of Sales

Late Recording of Purchases Received

Infrequent Manual Inventory Reconciliation

Problems with Inventory Controls

Reorder point set too low

Reorder Quantity (EOQ) set too low

Incorrect Reorder Level and Quantities

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

Copyright © 2015 John Wiley & Sons, Inc.

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

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

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

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

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

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

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

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

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

94 Chapter 3 Requirements Determination

Copyright © 2015 John Wiley & Sons, Inc.

Requirements-Gathering Techniques 95

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