CSU - Dominguez hills
Popular in Course
verified elite notetaker
Popular in Department
This 10 page Study Guide was uploaded by smartwriter Notetaker on Sunday November 15, 2015. The Study Guide belongs to a course at a university taught by a professor in Fall. Since its upload, it has received 23 views.
Reviews for BSA400_Wk2_GatheringRequirements
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 11/15/15
1 Informationgathering (5 points). Describe the informationgathering methods that can be used in analyzing requirements. This is about how to gather requirements and not requirements themselves. The enterprise system development lifecycle is a complex, multifaceted, iterative process that demands meticulous attention to detail at each successive stage. Before design or implementation can occur, the groundwork must be laid during the analysis phase, in which the analyst, along with the rest of the development team, must gather their list of requirements for the new enterprise system. Several proven techniques exist, which, when used correctly; enable the analyst to achieve a comprehensive software requirements list, both efficiently and accurately. Existingsystem analysis/data collection, stakeholder interviewing, userlevel observation, questionnaires/surveys, and Joint Application Development sessions each have unique benefits and drawbacks, though when combined these techniques can collectively produce definitive results when applied effectively. It is important to remember that once initial data collection is completed, the remaining steps are not linear or static in nature. The order of these methods are interchangeable, depending upon the conditions of the project at hand. Before a development team can conduct interviews or perform onsite observations, they should focus their efforts on documenting the organization’s current systems and standard operating procedures (SOPs). The goal here is to collect data about the functionality of the company’s current software and manual labor processes by examining artifacts only, allowing the analysts to adequately prepare for oneonone contact with users and stakeholders. This can be achieved by examining user, operations, and procedural manuals for existing systems; along with the collection of sample input forms, reports, and software 2 screen layouts (Borysowich, 2011). During this investigation, analysts should take detailed notes that focus on those processes and systems that fall within the scope of the project, and then prepare a synthesis of their notes before proceeding to the next step of the analysis. The data collection output should give analysts a basic picture of the functional structure of the business, and help them to identify problems within the current system. Once data collection is complete, the development team will transition into a phase known as requirements elicitation, which may include stakeholder interviews, direct onsite observation, questionnaires and surveys; along with certain types of focus groups, such as Joint Application Design (JAD). The order in which analysts should apply these techniques is determined by each method’s individual strengths and weaknesses, relative to the state of the project. Zowghi and Coulin (2005) emphasize the organic nature of requirements elicitation in their article, entitled, Requirements Elicitation: A Survey of Techniques, Approaches, and Tools: It is generally understood that requirements are elicited rather than just captured or collected. This implies there are discovery, emergence, and development elements to the elicitation process. Requirements elicitation is a complex process involving many activities with a variety of available techniques, approaches, and tools for performing them. The relative strengths and weaknesses of these determine when each is appropriate depending on the context and situation (p. 1, para. 1). 3 Interviews are a critical stage of the requirements elicitation process, and should be conducted only after the analysts have completed a detailed stakeholder analysis. Stakeholders are individuals with a vested interest in the system or are in some way affected by the development and implementation of the system; including the customer, Clevel users (CEO, CIO, CFO, etc.), endusers, department managers, vendors, and other individuals “whose sphere of interest may extend to some part of the system operations” (Zowghi and Coulin, 2005, p. 4, para. 2). Subject matter experts (SMEs) and key user representatives should be identified during this process, enabling the analysts to prepare relevant questions for each interviewee. Stakeholder interviews may be conducted facetoface, by phone, or through webbased software with videoconferencing capabilities. Determination of the setting depends on the level of need for costefficiency, the location and availability of the participant, and project time constraints. Regardless of the setting, there are three basic types of interviews – structured, unstructured, or semistructured, the latter of which is generally comprised of a combination of the other two (Zowghi and Coulin, 2005). A semistructured interview is most common, and tends to yield higherquality information, as the interviewer is able to ask both open and closedended questions during the interaction. Participants should also be given the opportunity to voice complaints about the current system and to offer suggestions about future system requirements. The output from the interview process should then be compiled by the development team, and the resulting data employed to direct onsite observations and user questionnaire development. Observation is often used in conjunction with the interviewing technique, in which the analyst observes the live execution of existing 4 processes without causing direct interference (Zowghi and Coulin, 2005). Although this method can yield valuable data, observations are costly and results are questionable; due to the fact that users have a propensity to alter the way they perform daily tasks while under direct observation. During the initial stages of requirements elicitation, analysts often employ questionnaires to gather data from a large group of users. This technique is ideal for the rapid collection of data from geographically distant, hard to reach stakeholders, but to be effective, questions must be focused and readily understood by the participants. Questionnaires are limited in scope and lack the opportunity for followup questions by the designer, and are generally considered “more useful as informal checklists to ensure fundamental elements are addressed early on and to establish foundation for subsequent elicitation activities” (Zowghi and Coulin, 2005, p. 8, para. 2). The final requirements elicitation technique to be described is known as a Joint Application Development (or JAD) session. The JAD technique was developed by IBM in 1977, designed to involve all available and willing stakeholders to participate in an investigative discussion of both the problems to be solved within a system and the available solutions to those problems. Typical roles in a JAD session include a facilitator and recorder, Information Systems representatives, operational representatives, and the development team. With this technique, decisions can be made rapidly and issues resolved quickly as all impacted parties are represented during the session. The one downside to a JADstructured session is that, by nature, they normally focus more on the business side of operations, rather than on the software systems themselves. That being said, a comprehensive requirements elicitation effort should expand its 5 field of focus to include all aspects of an organization’s functional structure, making effective JAD sessions an integral part of the development process. Business process mapping methods (5 points). Identify which business process mapping methods should be used in analysis. An analyst will most certainly employ business process mapping methods in conjunction with requirements elicitation, during the analysis phase of any software development lifecycle (SDLC). Process mapping “is a procedure whereby the steps in a business process are clarified and documented in both written form and visually in a flow chart,” in order to improve efficiency and to reduce areas of waste within those processes ("University Of California", 2014, para. 1). Some of the more widely used business process mapping approaches include standard process mapping, service blueprinting, and business process reengineering, Depending on the type of organization the analyst is working with during the SDLC process, one or all of these methods may be conducive to a comprehensive analysis of business functionality. Standard business process mapping involves the creation of a workflow diagram to give the analysts a better understanding of a process or a series of parallel, interconnected processes. To construct this flowchart, the analysts must first determine boundaries; identifying where each process begins and ends. Each step of the process must then be listed and sequenced in the proper order, demonstrating the operational functionality of a daily business task. This could include the path that an airway bill takes from the time it is created until the point which freight is delivered, in an example of process mapping within a freight forwarding firm. A standard system model would then be applied to the flowchart, with appropriate symbols representing 6 inputs, outputs, processes, controls, and feedback; depending on the level of detail required. It is important to remember that this approach works for all levels of detail within an organization’s process hierarchy, from highlevel (containing little detail) to lowlevel (with the closest level of detail possible, including every minute step in a business process). Service blueprinting is a versatile and practical technique used for improving service based processes, as opposed to other goodsbased models. Blueprinting allows an analyst to clearly visualize service processes and delivery from the customer’s perspective, using a chart format employed to identify individual events in the service chain (Arizona State University, 2014). Finally, business process reengineering (BPR) is described by its creators as a “fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical measures of performance such as cost, quality, service and speed” (The Economist, 2009). According to Motiwalla and Thompson (2009), BPR methodology includes five major steps, being preparation, defining the “asis” process, mapping of “to be” processes based on best practices, the testing and measuring of new processes, and a final reevaluation of new procedures. Obviously, BPR is more than just a process mapping technique, as it goes several steps beyond basic diagramming to involve the actual retooling of the core business processes with the use of enterprise resource planning (ERP) software. This method, while effective, should only be used after a careful evaluation is made by the entire development team, with the final decision resting upon key stakeholders within the organization. 7 Business process mapping tools (5 points). Discuss which business process mapping tools should be used in documenting analysis. To facilitate the implementation of business process mapping, various software tools are commercially available to the development team, each with varying levels of computational ability. Small businesses can have their processes thoroughly mapped with flowcharting software like Microsoft Visio, while larger organizations may require more complex tools to adequately diagram multiple parallel activities that connect several departments within their operational structure. The Ben Graham Corporation, Oracle, and IBM are just three examples of business process mapping software makers on the market today. The analysts will need to determine the appropriate tool for their specific project based on the level of complexity it involves. The business mapping process is centered on flowcharts, used to diagram the sequence of events of people or automated systems involved in a complex process within a business’s operational structure. For small organizations, Microsoft Visio may prove to be an adequate tool for process mapping tasks. The tool allows analysts to create a basic workflow chart with specific events represented by symbols, connected in sequence from beginning to end. However, because Visio is based on freeform drawing techniques, it lacks the structured approach required for more complicated mapping projects. The Ben Graham Corporation produces slightly more powerful mapping technology, developed originally in the 1940’s for use by industrial and production based businesses. Ben Graham products differ from Visio in terms of structured flowcharting and the ability to publish output in chart or “play script” procedure format. These features are advantageous to 8 an analyst who is looking to map various levels of detail within an organization’s operation processes, and may be a better choice if cost is not the primary concern when choosing this type of software. For corporate organizations, analysts may want to consider enterpriselevel mapping tools such as those developed by Oracle and IBM. Oracle’s Workflow enables modeling, automation, and the rerouting of information according to userdefined rules, features that far surpass the capabilities of those process mapping technologies described thus far. Modeling allows an analyst, along with their team, to forecast and quantify increases in efficiency based on proposed changes to an existing system. This capability is invaluable during the SDLC process, as it illustrates the potential benefits and risks involved with implementing new ERP software. IBM’s business process management (BPM) software combines process modeling with realtime visibility into a business’s work in progress, allowing the development team to document increases or decreases in efficiency due to environmental conditions. This allows for more detailed reporting during the analysis phase of any project, therefore increasing the accuracy of the analyst’s evaluation. As the cost of either of these systems is considerably higher than those offered by Microsoft or Ben Graham Inc., the analysts will need to determine whether their project calls for such powerful tools before making a decision on which process mapping tool is appropriate for a specific task. Although the enterprise system development lifecycle is a complicated and daunting task, the process is made simpler through the use of a structured methodology and through the use of robust process mapping tools. By approaching the analysis phase with established, organic requirements elicitation techniques, the analyst is better equipped to handle ever 9 evolving 21 century organizational structures. These methods, when combined with an appropriate business process mapping technique and related tool, will result in a more detailed analysis and a stronger foundation for the latter stages of the SDLC process to be built upon. References Arizona State University. (2014). Retrieved from http://wpcarey.asu.edu/research/services leadership/servicesblueprinting 10 Borysowich, C. (2011, January). Systems analysis: Document existing system(s): Gather data. Toolbox.com, (), . Retrieved from http://it.toolbox.com/blogs/enterprisesolutions/systems analysisdocumentexistingsystemsgatherdata43880 The Economist. (2009). Retrieved from http://www.economist.com/node/13130298 Motiwalla, L. F., & Thompson, J. (2009). Enterprise Systems for Management . Upper Saddle River, NJ: Pearson Education University of California. (2014). Retrieved from http://ucpath.ucsc.edu/news events/events/FAQBusinessProcessMapping.html Zowghi, D., & Coulin, C. (2005). Requirements elicitation: A survey of techniques, approaches, and tools. In Engineering and managing software requirements (pp. 1946). Springer Berlin Heidelberg.
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'