System Development Methods CT046-3-2 PDF

System Development Methods CT046-3-2 System Planning – Part 2 This presentation file offers you an engaging experience in digital learning. All content in this presentation, lecture notes, visual media and music are credited to its owner under creative commons license. This presentation file belon...

System Development Methods CT046-3-2 System Planning – Part 2 This presentation file offers you an engaging experience in digital learning. All content in this presentation, lecture notes, visual media and music are credited to its owner under creative commons license. This presentation file belongs to APU and no media in this presentation should be duplicated or distributed. Typefaces used in this presentation are Trueno & Calibri.  01 Requirement Engineering purpose and activities Topic & Structure of the Lesson 02 Requirement Engineering techniques Here are the items that will be discussed in this lesson 03 Project risk management Learning Outcomes By the end of this lecture, you should be able to : 1.Explain the purpose of requirement engineering and its activities. 2.Describe various requirement engineering techniques. 3.Discuss the importance of project risk management.  Requirement Engineering purpose and activities Key Terms you Requirement Engineering techniques must be able to use Project risk management If you have mastered this topic, you should be able to use the following terms correctly in your assignments and exams:  PART 2 01 Requirement Engineering purpose and activities Here are the items that will be discussed in this part 02 Requirement Engineering techniques 03 Project risk management 01 Requirement Engineering purpose and activities Requirement Engineering (RE) Requirement Engineering (RE) is a process of gathering, analyzing and finalizing requirements for the project. AKA: Requirement Gathering, System Investigation. Requirements consist of a guideline of what the new information system should do to archive its objectives. High-Level Requirement. The overall goal of the system. Determined at the initial planning stage by the analyst Low-Level Requirements More detailed functions Determined by gathering requirements from various sources. Output: System Requirement Specification (SRS) Requirement Engineering (RE): Purpose Basically, asking the following questions to gather facts, WHO, WHAT, WHERE , WHEN, HOW , WHY. For each of those questions, you also must ask another very important question: why. Some examples of these questions are: Who? Who performs each of the procedures within the system? Why? Are the correct people performing the activity? Could other people perform the tasks more effectively? What is being done? What procedures are being followed? Why is that process necessary? What? Often, procedures are followed for many years, and no one knows why. You should question why a procedure is being followed at all. Where? Where are operations being performed? Why? Where could they be performed? Could they be performed more efficiently elsewhere? When? When is a procedure performed? Why is it being performed at this time? Is this the best time? How? How is a procedure performed? Why is it performed in that manner? Could it be performed better, more efficiently, or less expensively in some other manner? Requirement Engineering (RE): Main Activities Main activities that are involved in the RE: 1. Requirement 2. Requirement 3. Requirement Elicitation Compilation Validation and Analysis Requirement Elicitation Collect data about the old system and the new system to be built Requirement Compilation Gathering / merging the collected data into one location Requirement Validation and Analysis Narrowing / filtering, keeping only important and achievable requirements. 02 Requirement Engineering Techniques Requirement Engineering (RE): Techniques Popular RE Techniques: Interview Questionnaires / Survey Research Observation Document Review “One accurate measurement is worth a thousand expert opinons.” (Utvich’s Law) Sampling Requirement Engineering (RE): Interviews Interviewing is an important fact-finding tool during the systems analysis phase. An interview is a planned meeting during which you obtain information from another person. You must have the skills needed to plan, conduct, document, and evaluate interviews successfully. The interview should consist of several different kinds of questions: open-ended, closed- ended, or questions with a range of responses. Requirement Engineering (RE): Interviews (continued) OPEN-ENDED QUESTIONS Open-ended questions encourage spontaneous and unstructured responses. Such questions are useful when you want to understand a larger process or draw out the interviewee’s opinions, attitudes, or suggestions. For examples: What are users saying about the new system? How is this task performed? Why do you perform the task that way? How Are the checks reconciled? What added features would you like to have in the new billing system? Also, you can use an open-ended question to probe further by asking: Is there anything else you can tell me about this topic? Requirement Engineering (RE): Interviews (continued) CLOSED-ENDED QUESTIONS Closed-ended questions limit or restrict the response. You use closed-ended questions when you want information that is more specific or when you need to verify facts. For examples: How many personal computers do you have in this department? Do you review the reports before they are sent out? How many hours of training does a clerk receive? Is the calculation procedure described in the manual? How many customers ordered products from the Web site last month? Requirement Engineering (RE): Interviews (continued) RANGE-OF-RESPONSE Range-of-response questions are closed-ended questions QUESTIONS that ask the person to evaluate something by providing limited answers to specific responses or on a numeric scale: This method makes it easier to tabulate the answers and interpret the results. For examples: On a scale of 1 to 10, with 1 the lowest and 10 the highest, how effective was your training? How would you rate the severity of the problem: low, medium, or high? Is the system shutdown something that occurs never, sometimes, often, usually, or always? Requirement Engineering (RE) Questionnaires / Survey In projects where it is desirable to obtain input from many people, a questionnaire can be a valuable tool. A questionnaire, also called a survey, is a document containing several standard questions that can be sent to many individuals. Questionnaires can be used to obtain information about a wide range of topics, including workloads, reports received, volumes of transactions handled, job duties, difficulties, and opinions of how the job could be performed better or more efficiently. Requirement Engineering (RE) Questionnaires / Survey (continued) When designing a questionnaire, it is important to make sure that your questions collect the right data in a form that you can use to further your fact-finding. Some additional ideas to keep in mind when designing your questionnaire: Keep the questionnaire brief and user-friendly. Provide clear instructions that will answer all anticipated questions. Arrange the questions in a logical order, going from simple to more complex topics. Phrase questions to avoid misunderstandings; use simple terms and wording. Try not to lead the response or use questions that give clues to expected answers. Limit the use of open-ended questions that are difficult to tabulate. Limit the use of questions that can raise concerns about job security or other negative issues. Include a section at the end of the questionnaire for general comments. Test the questionnaire whenever possible on a small test group before finalizing it and distributing it to a large group. Requirement Engineering (RE) Research Your research can include the Internet, IT magazines, and books to obtain background information, technical material, and news about industry trends and developments. In addition, you can attend professional meetings, seminars, and discussions with other IT professionals, which can be very helpful in problem solving. Research also can involve a visit to a physical location, called a site visit, where the objective is to observe a system in use at another location. If you are studying your firm’s human resources information system, for example, you might want to see how another company’s system works. Requirement Engineering (RE): Observation OBSERVATION The observation gives you an additional perspective and a better understanding of system procedures. It allows you to verify statements made in interviews. Plan your observations in advance by preparing a checklist of specific tasks you want to observe and questions you want to ask, for examples: Observe all the steps in a transaction and note the documents, inputs, outputs, and processes involved. Examine each form, record, and report. Determine the purpose each item of information serves. Is the system shutdown something that occurs never, sometimes, often, usually, or always? Requirement Engineering (RE): Document Review DOCUMENT REVIEW Document review can help you understand how the current system is supposed to work. Remember that system documentation sometimes is out of date. Forms can change or be discontinued, and documented procedures often are modified or eliminated. You should obtain copies of actual forms and operating documents currently in use. You also should review blank copies of forms, as well as samples of actual completed forms. Requirement Engineering (RE): Sampling (continued) Your research can include the Internet, IT magazines, and books to obtain background information, technical material, and news about industry trends and developments. In addition, you can attend professional meetings, seminars, and discussions with other IT professionals, which can be very helpful in problem solving. A systematic sample would select every tenth customer for review. If you want to ensure that the sample is balanced geographically. A stratified sample to select five customers from each of four zip codes. Another example of stratified sampling is to select a certain percentage of transactions from each zip code, rather than a fixed number. A random sample selects any 20 customers. 03 Project risk management Risk Management Every IT project involves risks that systems analysts and project managers must address. A risk is an event that could affect the project negatively. Risk management is the process of identifying, analyzing, anticipating, and monitoring risks to minimize their impact on the project. Many projects failed due to; The developer did not identify all risks RISK The developer ignoring risks The developer did not prepare a ‘backup plan’ for risk The developer did not monitor risk. NO YES Risk Management (continued) Steps in risk management: A basic list would include the following tasks: Develop a risk management plan. A risk management plan includes a review of the project’s scope, stakeholders, budget, schedule, and any other internal or external factors that might affect the project. The plan should define project roles and responsibilities, risk management methods and procedures, categories of risks, and contingency plans. Identify the risks. Risk identification lists each risk and assesses the likelihood that it could affect the project. The details would depend on the specific project, but most lists would include a means of identification, and a brief description of the risk, what might cause it to occur, who would be responsible for responding, and the potential impact of the risk. Risk Management (continued) Analyze the risks. When assessing technical feasibility, an analyst must consider the following points: Qualitative risk analysis evaluates each risk by estimating the probability that it will occur and the degree of impact. Project managers can use a formula to weigh risk and impact values. Quantitative risk analysis is to understand the actual impact in terms of currency, time, project scope, or quality. Quantitative risk analysis can involve a modeling process called what-if analysis, which allows a project manager to vary one or more element(s) in a model to measure the effect on other elements. Risk Management (continued) Create a risk response plan. A risk response plan is a proactive effort to anticipate risk and describe an action plan to deal with it. An effective risk response plan can reduce the overall impact by triggering timely and appropriate action. Monitor risks. This activity is ongoing throughout the risk management process. It is important to conduct a continuous tracking process that can identify new risks, notice changes in existing risks, and update any other areas of the risk management plan. Risk Management Strategies Risk Transfers Accept that the risk MAY happen. Transferring the risk to a vendor or customer (who are aware of the risk but willing to face it if it comes). Accept that the risk MAY happen and take an alternative path to avoid Risk Avoidance the risk from happening. The original design may change. Accept that the risk WILL happen and take additional steps to reduce the Risk Reduction risk form occurring. May increase cost and delay in delivery time. Risk Acceptance Accept that the risk WILL happen and implement a total solution. Costly and time-consuming. Summary Requirement Engineering (RE) is a process of gathering, analyzing, and finalizing requirements for the project. During the RE, analysts use various techniques to collect data about the old system and the new system to be built such as interviews, surveys, observation, document reviews, and research. Analysts also can prepare the various type of questions during the RE including open- ended, close-ended, and range of questions. Risk management is the process of identifying, analyzing, anticipating, and monitoring risks to minimize their impact on the project. Steps in risk management include developing a risk management plan, identifying the risks, risk analysis, creating a risk response plan, and monitoring risks. Some strategies to handle project risks include risk transfers, risk avoidance, risk reduction, and risk acceptance.  The End System Planning Next Session: System Analysis