Lecture 6 - Requirement Gathering Lecture Notes PDF

System Analysis and Design By Dr. Marwa Hussien Mohamed Information Systems dept. Faculty of Computer Science and Information Systems  Lecture 6 Requirements Determination Learning Objectives Explain the analysis phase of the SDLC. Describe the content and purpose of the requirements...

System Analysis and Design By Dr. Marwa Hussien Mohamed Information Systems dept. Faculty of Computer Science and Information Systems  Lecture 6 Requirements Determination Learning 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 Analysis Phase Main activities in the analysis phase are: 1. Requirement determination 2. Use case analysis 3. Process modeling 4. Data modeling The Analysis Phase In the analysis phase, the systems analyst works extensively with the business users of the new system to understand their needs from the new system. The basic process of analysis involves three steps: Understand the existing situation (the as-is system). Identify improvements. Define requirements for the new system (the to-be system). The final deliverable of the analysis phase is the system proposal, which compiles the detailed requirements definition statement, use cases, process models, and data model together with a revised feasibility analysis and work plan. 5 Requirements Determination 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, building process models, and building a data model. 6 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 will be created that 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); 7 Business Requirements Business requirements help define the overall goals of the system and help clarify the contributions it will make to the organization’s success. Examples: “Increase market share”; “Shorten order processing time”; “Reduce customer service costs”; “Lower inventory spoilage”; “Improve responsiveness to customer service requests”; and “Provide account access to mobile customers.” When the systems development project is complete, success will be measured by evaluating whether the stated business requirements have actually been achieved. 8 User Requirements User requirements concentrate on what the user actually needs to accomplish with the system in order to fulfill a needed job or task. They describe tasks that the users perform as an integral part of the business’ operations. Example: “Schedule a client appointment”; “Place a new customer order”; “Re-order inventory”; “Determine available credit”; and “Look up account balances.” 9 Functional Requirements Functional Requirements relate directly to a process the system has to perform as a part of supporting a user task and/or information it needs to provide as the user is performing a task. Functional requirements begin to define how the system will support the user in completing a task. For example, assume the user requirement is “Schedule a client appointment.” The functional requirements associated with that task include: “Determine client availability,” “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. 10 Non-Functional Requirements Nonfunctional requirements is the quality attributes, design, and implementation constraints, and external interfaces of the final product. It includes important behavioral properties that the system must have, such as performance, usability, operational, performance, security, and cultural and political. Example: The ability to access the system through a mobile device, the project team needs to know whether a system must be highly secure, requires sub- second response time, or has to reach a multilingual customer base. These requirements will be discovered during conversations with users in the analysis phase, however, and should be recorded as they are discovered. 11 Non-Functional Requirements example 12 The Process of Determining Requirements A recent study by the Standish Group found that the lack of user involvement is the top reason for IT project failure. On the other hand, the business users may not be aware of the opportunities that a new technology may offer. It is important that the team carefully considers the underlying business process and how best to support that business process with information system technology. Requirements determination requires significant interactions with stakeholders, 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. 13 The Process of Determining Requirements There are a variety of elicitation techniques that can be used to acquire information, including interviews, questionnaires, observation, joint application development (JAD), and document analysis. The information gathered by these techniques is critically analyzed and used to craft the requirements definition statement. The analyst works with the entire project team and the business users to verify, change, and complete the list of requirements and, if necessary, to prioritize the importance of the requirements that are identified. During this process, use cases, process models, and data models may be used to clarify and define the ideas for the new system. This process continues throughout the analysis phase, and the requirements definition evolves over time. 14 The Requirements Definition Statement The requirements definition statement is a straightforward text report that simply lists the functional and non-functional requirements in an outline format. Statements in requirements document should be: outline format so that each requirement is clearly identified. identified with unique numbers to be easily tracked through the entire development process. grouped into functional and nonfunctional groupings. Prioritize / rank the requirements according to their importance in the new system “high”, “medium”, “low”. 15 Example- The Requirements Definition Statement for a Vehicle Management System 16 Example- The Requirements Definition Statement for a Vehicle Management System 17 Requirements Determination Techniques Include: interviews, JAD sessions, questionnaires, document analysis, and observation. An analyst is very much like a detective (and business users sometimes are like elusive suspects). He or she knows that there is a problem to be solved and therefore must look for clues that uncover the solution. Unfortunately, the clues are not always obvious (and often are missed), so the analyst needs to notice details, talk with witnesses, and follow leads. The best analysts will thoroughly search for requirements using a variety of techniques. You don’t want to discover later that you have key requirements wrong— surprises like this late in the SDLC can cause all kinds of problems. 18 1. Interviews The interview is the most commonly used requirements elicitation technique. 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: selecting interviewees, designing interview questions, preparing for the interview, conducting the interview, and post interview follow-up. 19 1. Selecting Interviewees In a schedule, list people who will be interviewed, the purpose of the interview, and where and when it will take place. 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 determine who in the organization can best provide important information about requirements. 20  2. Designing Interview Questions There are three types of interview questions: 1. Closed ended questions require a specific answer. used when the analyst is looking for specific, precise information (e.g., how many credit card requests are received per day). 2. Open-ended questions similar in many ways to essay questions that you might find on an exam. designed to gather rich information from the interviewee. 3. Probing questions follow up on what has just been discussed in order for the interviewer to learn more, and they often are used when the interviewer is unclear about an interviewee’s answer. 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. 21 Interview Questions - Examples 22 3. Preparing for the Interview You should have a general interview plan which lists the questions that you will ask in the appropriate order; and anticipates possible answers and provides how you will follow up with them. 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. 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 thoughts. 23  4. Conducting the Interview When you start the interview: Build rapport with the interviewee so that he trusts you and is willing to tell you the whole truth, not just give the answers that he or she thinks you want. Appear to be professional and an unbiased, independent seeker of information. 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. Record all the information that the interviewee provides (e.g., take notes or tape- recored). If you do not understand something, be sure to ask. Periodically summarize the key points that the interviewee is communicating. At the end, be sure to give the interviewee time to ask questions or provide information that he thinks is important but was not part of your interview plan. 24 5. Post-interview Follow-up After the interview is over, the analyst needs to prepare an interview report that describes the information from the interview. The 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 48 hours of the interview, because the longer you wait, the more likely you are to forget information. The interview report is sent to the interviewee with a request to read it and inform the analyst of clarifications or updates. Usually, there are few changes, but the need for any significant changes suggests that a second interview will be required. 25 26 2. 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. JAD is a structured process in which 10 to 20 users meet under the direction of a facilitator skilled in JAD techniques. The facilitator is a person who sets the meeting agenda and guides the discussion but does not join in the discussion as a participant. He 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. Often, the scribes will use computers and CASE tools to record information as the JAD session proceeds. 27 Joint Application Development (JAD) The JAD group meets for several hours, several days, or several weeks until all of the issues have been discussed and the needed information is collected. Most JAD sessions take place in a specially prepared meeting room, usually arranged in a U shape so that all participants can easily see each other. 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. 28 The JAD Meeting Room 29 Electronic JAD (e-JAD) 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, maintaining anonymity and enabling the group to focus on each idea’s merits. In this way, all participants can contribute at the same time, without fear of reprisal from people with differing opinions. e-JAD can reduce the time required to run JAD sessions by 50%– 80%. 30 1. 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. The need for all JAD participants to be away from their offices at the same time can be a major problem. However, without strong management support, JAD sessions can fail. The facilitator should be someone who is an expert in JAD or e-JAD techniques and has experience with the business under discussion. In many cases, the JAD facilitator is a consultant external to the organization because the organization may not have a regular day-to- day need for JAD or e-JAD expertise. 31 2. 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. JAD and e-JAD sessions usually move beyond the collection of information into producing analysis deliverables. JAD success depends upon a careful plan. Most JAD sessions are designed to collect specific information from users, and this requires the development of a set of questions prior to the meeting. A difference between JAD and interviewing is that all JAD sessions are structured—they must be carefully planned. Closed-ended questions are seldom used, because they do not spark the open discussion that is typical of JAD. 32 3. Preparing for the JAD Session As with interviewing, it is important to prepare the analysts and participants for the JAD session. 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. If the goal is to identify improvements for a system, then they can think about how they would improve the system prior to the JAD session. 33 4. Conducting the JAD Session Most JAD sessions try to follow a formal agenda, and most have formal ground rules that define appropriate behavior. Common ground rules include following the schedule, respecting others’ opinions, accepting disagreement, and ensuring that only one person talks at a time. The role of the JAD facilitator can be challenging. The JAD facilitator performs three key functions. 1. He ensures that the group sticks to the agenda. If 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. He must help the group understand the technical terms that surround the system development process and help them understand the specific analysis techniques. Participants are experts in their business area, but they probably are not experts in systems analysis. 3. He 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. 34 5. Post-JAD Follow-up As with interviews, a JAD post-session report is prepared and circulated among session attendees. 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. 35 3. Questionnaires A questionnaire is a set of written questions for obtaining information from individuals. They are used when there is a large number of people from whom information and opinions are needed. 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. Forms of questionnaires: paper electronic form, either via e-mail or on the Web. Electronic distribution can save a significant amount of money, compared with distributing paper questionnaires. 36 1. Selecting Participants The standard approach is to select a sample, or subset, of people who are representative of the entire group. 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%). 37 2. Designing the Questionnaire 38 3. 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. 39 4. 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. 40 4. Document Analysis Used to understand the as-is system. 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. 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, or it may not contain updated information about recent system changes. However, there are many helpful documents that do exist in the organization: paper reports, memorandums, policy manuals, user training manuals, organization charts, and forms. 41 5. Observation Observation: the act of watching processes being performed, is a powerful tool to gain insight into the as-is system. Observation enables the analyst to see the reality of a situation, rather than listening to others describe it in interviews or JAD sessions. Research studies have shown that many managers really do not remember how they work and how they allocate their time. Observation is a good way to check the validity of information gathered from other sources such as interviews and questionnaires. 42 Selecting the Appropriate Techniques No one technique is always better than the others, and in practice most projects benefit from a combination of techniques. In general, document analysis and observation require the least amount of training, while JAD sessions are the most challenging. Selecting the appropriate techniques depends on the stage of analysis: understanding the as-is system, identifying improvements, or developing the to-be system. 43  Selecting the Appropriate Techniques When to use what? Type of Some techniques are more suited for use at different stages of the analysis process. information Interviews and JAD used in the three stages of analysis. In contrast, document analysis and observation in understanding the as-is system, although they occasionally provide information about improvements. Questionnaires used to gather information about the as-is system, as well as general information about improvements. Depth of how rich and detailed is the information. Information Interviews and JAD sessions are very useful at providing rich and detailed information. Document analysis and observation are useful for obtaining facts. Questionnaires can provide a medium depth of information, soliciting both facts and opinions with little understanding of why. Breadth of the range of information and sources that can be easily collected by that technique. information Questionnaires and document analysis both are easily capable of getting a wide range of information from a large number of information sources. Interviews and observation require visit each information source individually, take more time. JAD sessions many information sources are brought together at the same time. 44  Selecting the Appropriate Techniques When to use what? Integration of the integration of information from different sources. Different people can provide Information conflicting information. JAD sessions are designed to improve integration because all information is integrated when it is collected, not afterward. Depth of refers to the amount of time the intended users of the new system must devote to the Information analysis process. User involvement can have a significant cost, and not all users are willing to contribute valuable time and energy. Questionnaires, document analysis, and observation place the least burden on users. JAD sessions require the greatest effort. Cost In terms of money and time. Questionnaires, document analysis, and observation are low-cost techniques (although observation can be quite time consuming). Interviews and JAD sessions as having moderate costs. 45 Tune Source - Case Study Jason began to understand the current Web-based sales processes and systems that already existed in the organization. Two requirements-gathering techniques proved to be helpful in understanding the current systems and processes—document analysis and interviews. First, the project team collected existing reports (e.g., sales forms, screen shots of the online sales screens) and system documentation (data models, process models) that shed light on the as-is system. Then, they conducted short interviews with the person who provided the documentation, for clarification. Next, Jason interviewed the senior analysts for the current sales systems to get a better understanding of how those systems worked. He asked whether they had any ideas for the new system, as well as whether there were any integration issues that would need to be addressed. 46 Tune Source - Case Study Carly suggested that the project team conduct several JAD sessions with store managers, marketing analysts, and Web-savvy members of the IT staff. Together, the groups could brainstorm the features desired in the Digital Music Download system. Jason facilitated three JAD sessions that were conducted over the course of a week. 47 Tune Source - Functional Requirements 48 Tune Source – Non Functional Requirements 49 Tasks to do this week Hand in: Project Time estimation. The Project Work Plan using MS Project (Gantt chart). Project Staffing Plan. Risk Assessment (at least 2 risks). Prepare: Choose appropriate requirement gathering technique(s). Prepare requirement document (Functional and non-functional). 50