GS BUSA 415 CH 3 Requirements Determination

For example, assume the user requirement is "Schedule a client appointment." The functional requirements associated with that task include:

"Find available openings matching client availability," "Select desired appointment," "Record appointment," and "Confirm appointment." Notice how these functional requirements expand upon the user's task to describe capabilities and functions that the system will need to include, allowing the user to complete the task.

In this section, we focus on the five most commonly used requirements elicitation techniques:

1. interviews, 2. JAD sessions, 3. questionnaires, 4. document analysis, and 5. observation.

1 of 5 : Elicit Information : Interviews The interview is the most commonly used requirements elicitation technique. In general, interviews are conducted one on one (one interviewer and one interviewee), but sometimes, due to time constraints, several people are interviewed at the same time. There are five basic steps to the interview process:

1. selecting interviewees, 2. designing interview questions, 3. preparing for the interview, 4. conducting the interview, and 5. post interview follow-up.

Conducting the Interview When you start the interview, the first goal is to build rapport with the interviewee so that he or she trusts you and is willing to tell you the whole truth, not just give the answers that he or she thinks you want. ○ You should appear to be professional and an unbiased, independent seeker of information. ○ The interview should start with an explanation of why you are there and why you have chosen to interview the person, and then move into your planned interview questions. It is critical to carefully record all the information that the interviewee provides. ○ In our experience, the best approach is to take careful notes—write down everything the interviewee says, even if it does not appear immediately relevant. Do not be afraid to ask the person to slow down or to pause while you write, because this is a clear indication that the interviewee's information is important to you. ○ One potentially controversial issue is whether or not to tape-record the interview. Recording ensures that you do not miss important points, but it can be intimidating for the interviewee. Most organizations have policies or generally accepted practices about the recording of interviews, so find out what they are before you start an interview. ○ If you are worried about missing information and cannot tape the interview, then bring along a second person to take detailed notes.

As the interview progresses, it is important that you understand the issues that are discussed. ○ If you do not understand something, be sure to ask. Do not be afraid to ask "dumb questions," because the only thing worse than appearing "dumb" is to be "dumb" by not understanding something that you could have cleared up by questioning. If you do not understand something during the interview, you certainly will not understand it afterward. ○ One good strategy to increase your understanding during an interview is to periodically summarize the key points that the interviewee is communicating. Finally, be sure to separate facts from opinion. ○ It is helpful to check the facts because any differences between the facts and the interviewee's opinions can point out key areas for improvement. As the interview draws to a close, be sure to give the interviewee time to ask questions or provide information that he or she thinks is important but was not part of your interview plan. ○ Likewise, it can be useful to ask the interviewee if there are other people who should be interviewed. Make sure that the interview ends on time. As a last step in the interview, briefly explain what will happen next (see the Post-interview Follow-up section). You do not want to prematurely promise certain features in the new system or a specific delivery date, but you do want to reassure the interviewee that his or her time was well spent and very helpful to the project.

POST JAD Follow up

As with interviews, a JAD post-session report is prepared and circulated among session attendees. The post-session report is essentially the same as the interview report in Figure 3‑7. Since the JAD sessions are longer and provide more information, it usually takes a week or two after the JAD session before the report is complete.

Functional Requirement

Process-oriented A process the system must perform; a process the system must do Information-oriented Information the system must contain

Breadth of Information Breadth of information refers to the range of information and information sources that can be easily collected by that technique.

Best Questionnaires and document analysis both are easily capable of soliciting a wide range of information from a large number of information sources. Worst In contrast, interviews and observation require the analyst to visit each information source individually and, therefore, take more time. Middle JAD sessions are in the middle because many information sources are brought together at the same time.

Administering the Questionnaire The key issue in administering the questionnaire is getting participants to complete the questionnaire and send it back.

Commonly used techniques include • clearly explaining why the questionnaire is being conducted and • why the respondent has been selected; • stating a date by which the questionnaire is to be returned; • offering an inducement to complete the questionnaire (e.g., a free pen); and • offering to supply a summary of the questionnaire responses. Systems analysts have additional techniques to improve responses rates inside the organization, such as personally handing out the questionnaire and personally contacting those who have not returned them after a week or two, as well as requesting the respondents' supervisors to administer the questionnaires in a group meeting.

4 of 5 : Elicit Information : Document Analysis (cont.) These documents (forms, reports, policy manuals, organization charts) only tell part of the story. They represent the formal system that the organization uses. Quite often, the "real," or informal system differs from the formal one, and these differences, particularly large ones, give strong indications of what needs to be changed.

For example, forms or reports that are never used likely should be eliminated. Likewise, boxes or questions on forms that are never filled in (or are used for other purposes) should be rethought. See Figure 3‑10 for an example of how a document can be interpreted. ○ The 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.

Preparing for the JAD Session As with interviewing, it is important to prepare the analysts and participants for the JAD session. Because the sessions can go beyond the depth of a typical interview and usually are conducted off-site, participants can be more concerned about how to prepare.

It is important that the participants understand what is expected of them. If the goal of the JAD session, for example, is to develop an understanding of the current system, then participants can bring procedure manuals and documents with them.

Preparing for the Interview It is important to prepare for the interview in the same way that you would prepare to give a presentation. 1. You should have a general interview plan which lists the questions that you will ask in the appropriate order; anticipates possible answers and provides how you will follow up with them; and identifies segues between related topics. 2. Confirm the areas in which the interviewee has knowledge so you do not ask questions that he or she cannot answer. 3. Review the topic areas, the questions, and the interview plan, and clearly decide which ones have the greatest priority in case you run out of time.

In general, structured interviews with closed-ended questions take more time to prepare than unstructured interviews. So, some beginning analysts prefer unstructured interviews, thinking that they can "wing it." ○ This is very dangerous and often counterproductive, because any information not gathered in the first interview would have to be obtained by follow-up efforts, and most people do not like to be interviewed repeatedly about the same issues. 4. Be sure to prepare the interviewee as well. When you schedule the interview, inform the interviewee of the reason for the interview and the areas you will be discussing far enough in advance so that he or she has time to think about the issues and organize his or her thoughts. This is particularly important when you are an outsider to the organization and for interviewing lower-level employees who often are not asked for their opinions and who may be uncertain about why you are interviewing them.

Requirements Analysis Strategies As we discussed earlier in the chapter, the analyst often must encourage the stakeholders to think critically about the needs for the new system and discover the true underlying requirements.

In this section, we present several strategies that the analyst can employ with the stakeholders to accomplish this goal. • Problem Analysis • Root Cause Analysis • Duration Analysis • Activity-Based Costing • Informal Benchmarking • Outcome Analysis • Technology Analysis • Activity Elimination

In our experience, identifying improvements is most commonly done through

JAD sessions because these sessions enable the analysts, users, and other key stakeholders to work together and create a shared understanding of the possibilities for the to-be system.

Traditional methods such as waterfall and parallel development (see Chapter 2) typically allot significant time to understanding the as-is system and identifying improvements before moving to capture requirements for the to-be system.

Newer RAD and agile methodologies, such as iterative development, system prototyping, throwaway prototyping, and extreme programming (see Chapter 2), focus almost exclusively on improvements and the to-be system requirements, and they devote little time for investigating the current as-is system.

Most JAD sessions take place in a specially prepared meeting room • away from the participants' offices, so that they are not interrupted. • The meeting room is usually arranged in a U shape so that all participants can easily see each other (Figure 3‑8). • At the front of the room (the open part of the "U"), there is a whiteboard, flip chart, and/or projector for use by the facilitator, who leads the discussion.

One problem with JAD is that it suffers from the traditional problems associated with groups: ○ sometimes people are reluctant to challenge the opinions of others (particularly their boss), a few people often dominate the discussion, and not everyone participates. Electronic JAD, or e-JAD, attempts to overcome these problems by the use of groupware. In an e-JAD meeting room, each participant uses special software on a networked computer to anonymously submit ideas, view all ideas generated by the group, and rate and rank ideas through voting. The facilitator uses the electronic tools of the e-JAD system to guide the group process, for maintaining anonymity and enabling the group to focus on each idea's merits and not the power or rank of the person who contributed the idea. • In this way, all participants can contribute at the same time, without fear of reprisal from people with differing opinions. Initial research suggests that e-JAD can reduce the time required to run JAD sessions by 50-80%

2 of 8 : Requirements Analysis Strategies : Root Cause Analysis Sometimes the solutions are appropriate, but many times they address a symptom of the problem, not the true problem or root cause itself

Root cause analysis focuses on problems first rather than solutions. The analyst starts by having the users generate a list of problems with the current system, then prioritizes the problems in order of importance. Starting with the most important, the users and/or analysts generate all possible root causes for the problem. The key point in root cause analysis is to always challenge the obvious and dig into the problem deeply enough that the true underlying cause(s) is revealed.

Requirements Elicitation in Practice First, the analyst should recognize that important side effects of the requirements definition process include • building political support for the project and • establishing trust and rapport between the project team and the ultimate users of the system.

Second, the analyst should carefully determine who is included in the requirements definition process. • The choice to include (or exclude) someone is significant; involving someone in the process implies that the analyst views that person as an important resource and values his or her opinions. ○ You must include all of the key stakeholders (the people who can affect the system or who will be affected by the system). This might include managers, employees, staff members, and even some customers and suppliers. ○ Also, be sensitive to the fact that some people may have significant influence within the organization even if they do not rank high in the formal organizational hierarchy. Finally, do everything possible to respect the time commitment that you are asking the participants to make. The best way to do this is to be fully prepared and to make good use of all the types of requirements elicitation techniques.

The final category of requirements is nonfunctional requirements.

The IIBA defines this group of requirements as "the quality attributes, design, and implementation constraints, and external interfaces which a product must have." Nonfunctional requirements take center stage in the design phase when decisions are made about the user interface, the hardware and software, and the system's underlying architecture.

Conducting the JAD Session Most JAD sessions try to follow a formal agenda, and most have formal ground rules that define appropriate behavior. Common ground rules include following the schedule, respecting others' opinions, accepting disagreement, and ensuring that only one person talks at a time. Channeling these feelings so that the session moves forward in a positive direction and getting participants to recognize and accept—but not necessarily agree on—opinions and situations different from their own requires significant expertise in systems analysis and design, JAD, and interpersonal skills.

The JAD facilitator performs three key functions. 1. First, he or she ensures that the group sticks to the agenda. When participants attempt to divert the discussion away from the agenda, the facilitator must be firm, but polite, in leading the discussion back to the agenda and getting the group back on track. 2. Second, the facilitator must help the group understand the technical terms and jargon that surround the system development process and help the participants understand the specific analysis techniques used. 3. Third, the facilitator records the group's input on a public display area, which can be a whiteboard, flip chart, or computer display. He or she structures the information that the group provides and helps the group recognize key issues and important solutions. ○ Under no circumstance should the facilitator insert his or her opinions into the discussion. The facilitator must remain neutral at all times and simply help the group through the process. ○ 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?" ○ The group is always right, and the facilitator has no opinion.

3 of 8 : Requirements Analysis Strategies : Duration Analysis requires a detailed examination of the amount of time it takes to perform each process in the current as-is system. Processes in which many different 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 often 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.

The analysts begin by determining the total amount of time it takes, on average, to perform a set of business processes for a typical input. They then time each of the individual steps (or sub processes) in the business process. The time to complete the basic steps are then totaled and compared with the total for the overall process. A significant difference between the two—and, in our experiences, the total time often 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.

Selecting Interviewees An interview schedule should be created, listing who will be interviewed, the purpose of the interview, and where and when it will take place (Figure 3‑4). It is quite common for the list of interviewees to grow, often by 50-75%. As you interview people, you likely will identify more information that is needed and additional people who can provide the information.

The people who appear on the interview schedule are selected on the basis of the analyst's information needs. The project sponsor, key business users, and other members of the project team can help the analyst find the best candidates to provide important information about requirements. ○ It is important to include both managers who oversee the processes and staff who actually perform the processes to gain both high-level and low-level perspectives. ○ Like most other things about systems analysis, this is an iterative process—starting with senior managers, moving to mid-level managers, then staff members, back to mid- level managers, and so on, depending upon what information is needed along the way.

Questionnaire Follow-Up It is helpful to process the returned questionnaires and develop a questionnaire report soon after the questionnaire deadline.

This ensures that the analysis process proceeds in a timely fashion and that respondents who requested copies of the results receive them promptly

During requirements determination, the to-be system concept is easy to change because little work has been done yet.

This is why the iterative approaches of many RAD and agile methodologies are so effective—small batches of requirements can be identified and implemented in incremental stages, allowing the overall system to change and evolve over time. Methodologies such as the V-model stress that tests for the system should be defined at the same time that the requirements are being defined.That way, testing is not just a last-minute, thrown-together process, but instead is based directly on the requirements of the system as they are being defined.

Beginning systems analysts may naively think that conducting an interview is as easy as conversing with a friend.

Unfortunately, this is almost never true. Interviewees often are not able or willing to hand over the needed information in a neat, organized fashion. In some cases, they may not want to share what they know at all. Analysts should hone their interpersonal skills to improve their interviewing success. (See Practical Tip 3‑1.)

Conducting the JAD Session (cont) It is common for the JAD participants to make use of a number of tools during the JAD session in order to fully define the new system.

Use cases may be created to describe how the users will interact with the new system. Prototypes are commonly created to more fully understand the user interface or navigation through the system. Process models can be constructed to understand the software that will be developed, while a data model can be used to describe the data that will be captured and maintained.

There are two fundamental approaches to organizing the interview questions: • top-down or • bottom-up With the top-down interview, the interviewer starts with broad, general issues and gradually works towards more specific ones • The top-down approach is an appropriate strategy for most interviews. (It is certainly the most common approach.) • The top-down approach enables the interviewee to become accustomed to the topic before he or she needs to provide specifics. It also enables the interviewer to understand the issues before moving to the details, because the interviewer may not have sufficient information at the start of the interview to ask very specific questions. • Perhaps most importantly, the top-down approach enables the interviewee to raise a set of big-picture issues before becoming enmeshed in details, so the interviewer is less likely to miss important issues.

With the bottom-up interview, the interviewer starts with very specific questions and moves to broad questions. ○ One case in which the bottom-up strategy may be preferred is when the analyst already has gathered a lot of information about issues and just needs to fill in some holes with details. ○ bottom-up may be appropriate if lower- level staff members feel threatened or are unable to answer high-level questions. In practice, analysts mix the two approaches, starting with broad general issues, moving to specific questions, and then back to general issues. In any event, all interviews should begin with noncontroversial questions first and then gradually move into more contentious issues after the interviewer has developed some rapport with the interviewee.

Selecting the Appropriate Techniques Each of the requirements elicitation techniques just discussed has strengths and weaknesses. No one technique is always better than the others, and in practice, most projects benefit from Type of Information • Depth of information • Breadth of information • Integration of information • User Involvement • Cost

a combination of techniques. Thus, it is important to understand the strengths and weaknesses of each technique and when to use each (Figure 3‑11). One issue not discussed is that of the analysts' experience. In general, document analysis and observation require the least amount of training, while JAD sessions are the most challenging.

7 of 8 : Requirements Analysis Strategies : Technology Analysis Technology analysis therefore starts by having the analysts and managers develop

a list of important and interesting technologies. Then the group systematically identifies how each and every technology could be applied to the business process and identifies how the business would benefit.

Requirements determination is performed to transform the system request's high-level statement of business requirements into

a more detailed, precise list of what the new system must do to provide the needed value to the business. This detailed list of requirements is supported, confirmed, and clarified by the other activities of the analysis phase: creating use cases and building process and data models.

The system's functional requirements evolve from understanding how the new system can support user needs. A functional requirement relates directly to

a process the system should perform as a part of supporting a user task and/or information it should provide as the user is performing a task. The International Institute of Business Analysis (IIBA) defines functional requirements as "the product capabilities, or things that a product must do for its users." ○ Functional requirements begin to define how the system will support the user in completing a task.

The work performed in the analysis phase involves expanding the vision described in the system request into

a thorough, detailed understanding of exactly what the new system needs to do. As the detailed understanding of what the new system must do evolves, those details will be expressed and documented in several ways, .• including a detailed requirements definition statement (this chapter), • use cases (Chapter 4), • process models (Chapter 5), and • data model (Chapter 6).

2 of 5 : Elicit Information : Joint Application Development (JAD) Joint Application Development (JAD) is an information gathering technique that Capers Jones claims that JAD can reduce scope creep by 50%, and it prevents the requirements for a system from being too specific or too vague, both of which can cause trouble during later stages of the SDLC.

allows the project team, users, and management to work together to identify requirements for the system. ○ JAD is a structured process in which 10-20 users meet under the direction of a facilitator skilled in JAD techniques. ○ The JAD group meets for several hours, several days, or several weeks until all of the issues have been discussed and the needed information is collected.

Designing the JAD Session JAD sessions can run from as little as a half day to several weeks, depending upon the size and scope of the project. In our experience, most JAD sessions tend to last 5-10 days spread over a 3-week period. Most e-JAD sessions tend to last 1-4 days in a 1-week period. As with interviewing, JAD success depends upon a careful plan. JAD sessions usually are designed and structured along the same principles

as interviews. Most JAD sessions are designed to collect specific information from users, and this requires the development of a set of questions before the meeting. A difference between JAD and interviewing is that all JAD sessions are structured—they must be carefully planned. ○ In general, closed-ended questions are seldom used, because they do not spark the open and frank discussion that is typical of JAD. ○ In our experience, it is better to proceed top-down in JAD sessions when gathering information. Typically, 30 minutes is allocated to each separate agenda item, and frequent breaks are scheduled throughout the day because participants tire easily.

4 of 5 : Elicit Information : Document Analysis Project teams often use document analysis to understand the Unfortunately, most 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.

as-is system. Under ideal circumstances, the project team that developed the existing system will have produced documentation, which was then updated by all subsequent projects. In this case, the project team can start by reviewing the documentation and examining the system itself. However, there are many helpful documents that do exist in the organization: • paper reports, • memorandums, • policy manuals, • user training manuals, • organization charts, and forms. ○ Problem reports filed by the system users can be another rich source of information about issues with the existing system.

1 of 8 : Requirements Analysis Strategies : Problem Analysis The most straightforward (and probably the most commonly used) requirements analysis strategy is problem analysis. Problem analysis means ○ Most users have a very good idea of the changes they would like to see, and most will be quite vocal about suggesting them. ○ Most changes tend to solve problems rather than capitalize on opportunities, but this is possible, too. ○ Improvements from problem analysis tend to be small and incremental

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. This type of improvement often is very effective at improving a system's efficiency or ease of use. However, it often provides only minor improvements in business value—the new system is better than the old, but it may be hard to identify significant monetary benefits from the new system. ○ The ideas produced by problem analysis tend to be solutions to problems.

During the analysis phase, requirements are written from the perspective of the

business, and they focus on what the system needs to do in order to satisfy business user needs. These user requirements describe tasks that the users perform as an integral part of the business' operations, such as: • "Schedule a client appointment"; • "Place a new customer order"; • "Re-order inventory"; "Determine available credit"; and • "Reconcile supplier shipment." Use cases (discussed in Chapter 4) are tools used to clarify the steps involved in performing these user tasks. By understanding what the user needs to do to complete a task, the analyst can then determine ways in which the new system can support the users' needs.

Beware, the evolution of the requirements definition must be

carefully managed. Keeping the requirements list tight and focused is a key to project success. The project team cannot keep adding new items to the requirements definition or the system will keep growing and growing and never gets finished.

Designing the Questionnaire Developing good questions is critical for questionnaires because the information on a questionnaire cannot be immediately clarified for a confused respondent. ○ Questions should be relatively consistent in style so that the respondent does not have to read instructions for each question before answering it. ○ It is generally a good practice to organize related questions together to make them simpler to answer. Questions on questionnaires must be very

clearly written and must leave little room for misunderstanding; therefore, closed-ended questions tend to be most commonly used. Questions must enable the analyst to clearly separate facts from opinions. 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. • 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.

Integration of Information One of the most challenging aspects of requirements gathering is the integration of information from different sources. Simply put, different people can provide

conflicting information. Combining this information and attempting to resolve differences in opinions or facts is usually very time consuming because it means contacting each information source in turn, explaining the discrepancy, and attempting to refine the information. Best All techniques suffer integration problems to some degree, but JAD sessions are designed to improve integration because all information is integrated when it is collected, not afterward. ○ If two users provide conflicting information, the conflict becomes immediately obvious, as does the source of the conflict. The immediate integration of information is the single-most important benefit of JAD that distinguishes it from other techniques, and this is why most organizations use JAD for important projects.

4 of 8 : Requirements Analysis Strategies : Activity-Based Costing Activity-based costing is a similar analysis that examines the

cost of each major process or step in a business process rather than the time taken. The analysts identify the costs associated with each of the basic functional steps or processes, identify the most costly processes, and focus their improvement efforts on them. ○ Assigning costs is conceptually simple. You just examine the direct cost of labor and materials for each input. ○ Materials costs are easily assigned in a manufacturing process, while ○ labor costs are usually calculated on the basis of the amount of time spent on the input and the hourly cost of the staff.

In many ways, determining requirements is the single-most

critical aspect of the entire SDLC Although many factors contribute to the failure of systems development projects, failing to determine the correct requirements is a primary cause. If the requirements are later found to be incorrect or incomplete, significant rework may be needed, adding substantial time and cost to the project.

To move the users "from here to there," an analyst needs strong

critical thinking skills. Critical thinking is the ability to recognize strengths and weaknesses and recast an idea in an improved form. These skills are needed in order for the analyst to ○ understand issues and ○ develop new and improved business processes that are supported by information system technologies

Post-interview Follow-up After the interview is over, the analyst needs to prepare an interview report that In general, the interview report should be written within 48 hours of the interview, because the longer you wait, the more likely you are to forget information. ○ Often, the interview report is sent to the interviewee with a request to read it and inform the analyst of clarifications or updates. ○ Make sure the interviewee is convinced that you genuinely want his or her corrections to the report.

describes the information from the interview (Figure 3‑7). The report contains • interview notes, • information that was collected over the course of the interview and • is summarized in a useful format. Usually, there are few changes, but the need for any significant changes suggests that a second interview will be required. Never distribute someone's information without prior approval.

What Is a Requirement? A requirement is simply a statement of what the system must

do or what characteristics it needs to have. During a systems development project, requirements are created that provide different perspectives. For example, we may describe ○ what the business needs (business requirements); ○ what the users need to do (user requirements); what ○ the software should do (functional requirements); ○ characteristics the system should have (nonfunctional requirements); and ○ how the system should be built (system requirements). ○ The final category of requirements is nonfunctional requirements. It can be difficult to draw a black-and-white dividing line between these requirement categories. To add to the confusion, some companies use the terms interchangeably and do not distinguish between the types of requirements at all. ○ The important thing to remember is that a requirement is a statement of what the system must do.

8 of 8 : Requirements Analysis Strategies : Activity Elimination The analysts and managers work together to identify how the organization could eliminate

each and every activity in the business process, how the function could operate without it, and what effects are likely to occur. Initially, managers are reluctant to conclude that processes can be eliminated, but this is a "force-fit" exercise in that they must eliminate each activity. In some cases, the results are silly; nonetheless, participants must address each and every activity in the business process.

When a requirement reflects a real business need, but is not within the scope of the current system or current release, it should be

evaluated in terms of its importance and impact on time and budget. It may be that the requirement is essential enough to add to the current project, along with appropriate adjustments to the project budget and time frame.

A number of techniques and tools can be used by the analyst to

facilitate this process of discovering requirements. It is unrealistic to expect the true requirements to be delivered on a silver platter during a few conversations with the business users. The analyst must be prepared to dig into the situation and discover requirements.

For clarity, the requirements are typically grouped into

functional and nonfunctional groupings. Then, within each of those groups, they are classified further by the type of requirement or by business area. ○ Sometimes, requirements are prioritized on the requirements definition statement. They can be ranked as having • "high," "medium," or "low" importance in the new system, or • they can be labeled with the version of the system that will address the requirement (e.g., release 1, release 2, release 3). This practice is particularly important with RAD methodologies that deliver requirements in batches by developing incremental versions of the system.

6 of 8 : Requirements Analysis Strategies : Outcome Analysis Outcome analysis focuses on understanding the

fundamental outcomes that provide value to customers. While these outcomes sound as though they should be obvious, they often are not. What is the fundamental outcome from the customer's perspective? With this approach, the system analysts encourage the managers and project sponsor to pretend that 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.

Depth of Information The depth of information refers to

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

As the project progresses, the analyst comes to understand the business process much better, and he or she needs very specific information about how business processes are performed (e.g., exactly how a customer credit request is approved). At this time, the analyst conducts structured interviews

in which specific sets of questions are developed prior to the interviews. There usually are more closed-ended questions in a structured interview than in the unstructured approach. No matter what kind of interview is being conducted, interview questions must be organized into a logical sequence so that the interview flows well.

Selecting Participants Selecting JAD participants is done in the same basic way as selecting interview participants. Participants are selected on the basis of

information they can contribute, to provide a broad mix of organizational levels, and to build political support for the new system. The need for all JAD participants to be away from their offices at the same time can be a major problem. The office may need to be closed or run with a skeleton staff until the JAD sessions are complete. ○ Ideally, the participants who are released from regular duties to attend the JAD sessions should be the very best people in that business unit. ○ However, without strong management support, JAD sessions can fail, because those selected to attend the JAD session are people who are less likely to be missed (i.e., the least competent people).

In general, a useful strategy for the analyst to employ is to begin requirements gathering by

interviewing senior managers to gain an understanding of the project and get the "big picture." • These preliminary interviews can then be followed by document analysis and, possibly, observation of business processes to learn more about the business domain, the vocabulary, and the as-is system. More interviews may then follow to collect the rest of the information needed to understand the as-is system. • The concept for the to-be system is frequently developed through interviews with senior managers, followed by JAD sessions with users of all levels, to make sure that the key requirements of the new system are well understood.

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). The low cost does not imply that they are more or less effective than the other techniques. We regard interviews and JAD sessions as having moderate costs. In general, JAD sessions are much more expensive initially, because they require many users to be absent from their offices for significant periods, and they often involve highly paid consultants. However, JAD sessions significantly reduce the time spent in information integration and thus cost less in the long term.

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 significant cost, and not all users are willing to contribute valuable time and energy. Best Questionnaires, document analysis, and observation place the least burden on users, while Worst JAD sessions require the greatest effort.

User, functional, and nonfunctional requirements identified in the analysis phase will flow into the design phase, where they evolve to become

more technical, describing how the system will be implemented. Requirements in the design phase reflect the developer's perspective, and they usually are called system requirements.

Questionnaires : Selecting Participants As with interviews and JAD sessions, the first step is to select the individuals to whom the questionnaire will be sent. Typically, a sample,

or subset, of people are selected who are representative of the entire group. Sampling guidelines are discussed in most statistics books, and most business schools include courses that cover the topic, so we will not discuss it here. The important point in selecting a sample, however, is to realize that not everyone who receives a questionnaire will actually complete it. On average, only 30-50% of paper and e-mail questionnaires are returned. Response rates for Web-based questionnaires tend to be significantly lower (often, only 5-30%).

5 of 8 : Requirements Analysis Strategies : Informal Benchmarking Benchmarking refers to studying how Informal benchmarking is fairly common for "customer-facing" business processes (i.e., those 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.

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.

One or two scribes assist the facilitator by

recording notes, making copies, and so on. Often, the scribes will use computers and CASE tools to record information as the JAD session proceeds.

One of the first tasks for the analyst is to identify the primary sources of

requirements, including • the project sponsor, project champion(s), • all users of the system (both direct and indirect), and • possibly others. It is important that all user perspectives are included.

Before moving into the design phase, the project's business value should be

reviewed to ensure it remains positive. If approved, the system proposal components (requirements definition, use cases, process model, and data model) are used as inputs to the steps in the design phase, which further refine them and define in much more detail how the system will be built.

The Requirements Definition Statement The requirements definition statement—usually just called the requirements definition—is a The most obvious purpose of the requirements definition is to provide a clear statement of what the new system should do in order to achieve the system vision described in the system request.

straightforward text report that simply lists the functional and nonfunctional requirements in an outline format. As shown in Figure 3‑3, requirements are typically identified by numbering. Assigning unique numbers enables each requirement to be tracked through the entire development process. A critically important purpose of the requirements definition, however, is to define the scope of the system. The document describes to the analysts exactly what the final system needs to do. ○ If and when discrepancies or misunderstandings arise, the document serves as a resource for clarification.

The final deliverable of the analysis phase is the

system proposal, a document compiling the • detailed requirements definition statement, • use cases, • process models, and • data model together with a • revised feasibility analysis and • work plan.

At the conclusion of the analysis phase, the system proposal is presented to the approval committee, usually in the form of a

system walk-through. The goal of the walk-through is to explain the system in moderate detail so that the users, managers, and key decision makers clearly understand it, can identify any needed modifications, and are able to make a decision about whether the project should continue.

Although the term "nonfunctional" is not very descriptive, this requirement category includes important behavioral properties that the system must have. For example,

the ability to access the system through a mobile device would be considered a nonfunctional requirement. Figure 3‑2 lists different kinds of nonfunctional requirements and examples of each kind. Notice that the nonfunctional requirements describe a variety of system characteristics: • Operational • Performance • Security • Cultural and Political These characteristics do not describe business processes or information, but they are very important in understanding what the final system should be like. For example, the project team needs to know whether a system must be highly secure, requires subsecond response time, or has to reach a multilingual customer base.

In the systems request, there are statements that describe the reasons for proposing the systems development project. These statements reflect

the business requirements that this system, if built, will fulfill. These business requirements help define the overall goals of the system and help clarify the contributions it will make to the organization's success. Examples of business requirements include: • "Provide product search capabilities," • "Produce performance reports," • "Provide accurate project status reports," and • "Provide account access to mobile customers."

Process models help clarify the software components that will be needed to accomplish the functional requirements. In addition, the information-oriented functional requirements begin to define

the data that must be kept track of in order to accomplish the user tasks. The data component of the system is defined in the data model (Chapter 6).

The line between the analysis and design phases is very blurry, because the deliverables created in the analysis phase are really

the first step in the design of the new system. Many of the major design decisions for the new system are found in the analysis deliverables. In fact, a better name for the analysis phase would really be "analysis and initial design,"

The facilitator is a person who sets

the meeting agenda and guides the discussion, but does not join in the discussion as a participant. He or she does not provide ideas or opinions on the topics under discussion and remains neutral during the session. The facilitator must be an expert in both group process techniques and systems analysis and design techniques. Ideally, the facilitator will have experience with the business under discussion. In many cases, the JAD facilitator is an outside consultant.

5 of 5 : Elicit Information : Observation Observation, the act of watching processes being performed, is a powerful tool to gain insight into the as-is system. Observation is often used to supplement interview information. Observation enables the analyst to see the

the reality of a situation, rather than listening to others describe it in interviews or JAD sessions. ○ Observation is a good way to check the validity of information gathered from other sources such as interviews and questionnaires The goal is to keep a low profile, to not interrupt those working, and to not influence 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.

The Process of Determining Requirements Both business and IT perspectives are needed to determine requirements during the analysis phase. Systems analysts may not understand

the true business needs of the users, while the business users may not be aware of promising new technologies. Therefore, the most effective approach is to have both business people and analysts working together to determine requirements.

3 of 5 : Elicit Information : Questionnaires A questionnaire is a set of written questions for obtaining information from individuals. Questionnaires often are used when

there is a large number of people from whom information and opinions are needed. In our experience, questionnaires are commonly used for systems intended for use outside of the organization (e.g., by customers or vendors) or for systems with business users spread across many geographic locations. Today, most questionnaires are being distributed in electronic form, either via e-mail or on the Web.

Designing Interview Questions (cont.) At the initial stage of an IS development project the as-is process can be unclear, so the interview process begins with

unstructured interviews, interviews that seek a broad and roughly defined set of information. In this case, the interviewer has a general sense of the information needed, but few closed-ended questions to ask. These are the most challenging interviews to conduct because they require the interviewer to ask open-ended questions and probe for important information "on the fly."

As the analyst works with the business users of the system to discover user and functional requirements, the user may reveal processes that

will be needed or information that will be needed. For example, as shown in Figure 3‑1, the user may state "The system must retain customer order history for 3 years" (an information need). The analyst should probe for the reasoning behind this statement, such as "The system should allow registered customers to review their own order history for the past 3 years" (a process need).

Developing Interpersonal Skills Interpersonal skills are those that enable you to develop rapport with others, and they are very important for interviewing. They help you to communicate with others effectively.

• Don't worry, be happy. Happy people radiate confidence and project their feelings on others. • Pay attention. Pay attention to what the other person is saying (which is harder than you might think). • Summarize key points. At the end of each major theme or idea that someone explains, you should repeat the key points back to the speaker • Be succinct. When you speak, be succinct. The goal in interviewing (and in much of life) is to learn, not to impress. • Be honest. Answer all questions truthfully, and if you do not know the answer, say so. • Watch body language (yours and theirs). The way a person sits or stands conveys much information.

This chapter begins by describing the analysis phase and its primary deliverable, the system proposal. Objectives • Explain the analysis phase of the SDLC. • Describe the content and purpose of the requirements definition statement. • Classify requirements correctly as business, user, functional, or nonfunctional requirements.

• Employ the requirement elicitation techniques of ○ interviews, ○ JAD sessions, ○ questionnaires, ○ document analysis, and ○ observation. • Define the role that each requirement elicitation technique plays in determining requirements. • Describe several analysis strategies that can help the analyst discover requirements.

Comparing Analysis Strategies No one technique is inherently better than the others.

• Problem analysis and root cause analysis tend to be most useful in situations with a narrow focus where efficiency gains are sought. • Duration analysis and activity-based costing strategies help the team find the most "broken" business processes so that those processes can be redesigned and improved. • Outcome analysis, technology analysis, and informal benchmarking help the team think "outside the box" and are very useful when the team is trying to create completely new ways of accomplishing the business processes.

Designing Interview Questions Typically, interviews include: • closed-ended questions, • open-ended questions, and • probing questions. • Closed-ended questions require a specific answer. ○ Closed-ended questions are used when the analyst is looking for specific, precise information ○ However, these types of questions do not uncover why the answer is the way it is, nor do they uncover information that the interviewer does not think to ask ahead of time • Open-ended questions seek a more wide-ranging response from the interviewee. ○ 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 subjects the interviewee chooses to discuss uncover information that is just as important as the answer

• Probing questions follow up on what has just been discussed in order for the interviewer to learn more. ○ They encourage the interviewee to expand on or to confirm information from a previous response, and they are a signal that the interviewer is listening and interested in the topic under discussion. • In general, you should not ask questions about information that is readily available from other sources. • This helps focus the interviewee on the task and saves time, because he or she does not need to describe the information in detail— he or she just needs to point it out on the form or report. • Your interview questions should anticipate the type of information the interviewee is likely to know. Managers are often somewhat removed from the details of daily business processes and so might be unable to answer questions about them, whereas lower-level staff members could readily respond. • No type of question is better than another, and usually a combination of questions is used during an interview.

In the analysis phase, the systems analyst works extensively with the business users of the new system to understand their needs from the new system. The basic process of analysis involves three steps:

• Understand the existing situation (the as-is system). • Identify improvements. • Define requirements for the new system (the to-be system). Sometimes the first step (i.e., understanding the as-is system) is skipped or done in a limited manner. This happens when no current system exists, if the existing system and processes are irrelevant to the future system, or if the project team is using a RAD or agile development methodology in which the as-is system is not emphasized. ○ Experience shows that it is useful to study the current situation whenever possible. The insights gained from reviewing the existing system can be quite valuable to the project team.

Managing Problems in JAD Sessions • Reducing domination. The facilitator should ensure that no one person dominates the group discussion. • Encouraging non-contributors. Drawing out people who have participated very little is challenging because you want to bring them into the conversation so that they will contribute again. • Side discussions. Sometimes participants engage in side conversations and fail to pay attention to the group.. • Agenda merry-go-round. The merry-go-round occurs when a group member keeps returning to the same issue every few minutes and will not let go.

• Violent agreement. Some of the worst disagreements occur when participants really agree on the issues but do not realize that they agree because they are using different terms. • Unresolved conflict. In some cases, participants do not agree and cannot understand how to determine what alternatives are better. You can help by structuring the issue. • True conflict. Sometimes, despite every attempt, participants just cannot agree on an issue. The solution is to postpone the discussion and move on. • Use 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 find the humor in the situation.

Process models (Chapter 5) are used to explain the relationship of

• functions/processes to the system users, • how the functions/processes relate to each other, • how data are entered and produced by functions/processes, and • how functions/processes create and use stored data.

The analyst must also consider how best to elicit the requirements from the stakeholders. There are a variety of elicitation techniques that can be used to acquire information, including

• interviews, • questionnaires, • observation, • joint application development (JAD, as it is more commonly known), and • document analysis. The analyst works with the entire project team and the business users to verify, change, and complete the list of requirements and, if necessary, to prioritize the importance of the requirements that are identified.

The Analysis Phase The analysis phase is so named because the term analysis refers to breaking a whole into its parts with the intent of

• understanding the parts' nature, • function, and • interrelationships. In the context of the SDLC, the outputs of the planning phase (the system request, feasibility study, and project plan), outline the business goals for the new system, define the project's scope, assess project feasibility, and provide the initial work plan.