Case Study On System Requirement Modeling

The part of the job of the analyst in identifying a business need that looks interesting and enjoyable to me would be engaging the stakeholders (organization management, sponsors/champions, and system users among other stakeholders) in identifying the various business requirements. This, in my view, is one of the crucial areas because it would allow me as an analyst to understanding the state of an existing system and determine how a new system would impact on the business performance of an organization. Without a clear picture of the business requirements, there is a high likelihood that a new system would not bring the anticipated results. I would use my interviewing skills to get the different perspectives of the stakeholders as an initial step in system development. It is clear to me that interviewing, as a method of gathering business requirements, is sometimes cumbersome and time consuming. However, I am of the view that with the right skills in conducting interviews, an analyst can be able to probe deeper on issues and challenges of an existing system and the specifications that a new system is expected to meet. I would achieve this through conducting individual interviews, joint interviews as well as forming focus groups.

As part of our MIS 4163 class, we are going to work in a project that will prepare a system design for the application we select. Our team, the Purple Pirates, is a team composed of 5 people. We have selected to put together the design for a service order and invoicing application for an auto repair business. We have named our project ARS which stands for Auto Repair System.

Another way of successfully gathering information is by building a prototype or model of the system, so that users can test or get an idea of what the finished product will be like. With this they can determine issues, problems, or inconsistency with the system. Another important part of gathering information is organizing it so that it can be understood and put to proper use. I propose categorizing the requirements into functional requirements, operational requirements, technical requirements, and transitional requirements. The functional requirements define how the user thinks the system is functioning overall, the operational requirements define what background processes need to be executed in order for the system to work optimally over a period of time, the technical requirements define what technical issues that must be addressed in order to successfully implement the system, and the transitional requirements define the processes or steps needed to implement the system smoothly and successfully. ("Mind Tools", 2012).

The commonly used methods of observation, interviews, etc., can help analysts pinpoint exact requirements based on user input and business processes. According to Charvat (2003), “One of the biggest benefits of a proper user requirements specification is that you'll be able to plan and estimate your project correctly, decreasing the chance of cost and time overruns.” The analyst must listen to the employees and gain a thorough understanding of all business processes before establishing the new system requirements.

3. A Use Case is developed to support requirement specification. It is a detailed description of specifications in its simplest form using Realtime scenarios of the functionality requirements between the actors and

The information system’s requirements in the systems planning phase are based on a case summary, potential interview questions, and the systems analyst’s experience in systems planning. One must not only generate requirements based specifically on what users’ state they want or need. Analysts must also generate requirements based on insight into the overall organization and project goals.

Requirement Analysis: collect the business needs, document the requirements, and help team members to prepare Functional and enhancement Specification Document and Technical detail design document.

For this project, you will design a system for the organization of your choosing. This could be for a current or former employer or some fictitious organization (Banks Against Blight LLC). The system you design might be data storage, telecommunications, e-commerce, accounting information, manufacturing process system, inventory management, or some other system approved by your instructor.

Requirement elicitation and analysis was done in series of steps. Firstly, we carefully read and analyzed the product description to identify project context. After this stakeholders of the system and the roles of these stakeholders were identified. Raw requirement for the system were identified on the basis of the

System analysts use prototyping, modeling and computer-aided engineering tools. Modeling makes a graphical representation of a process. Prototyping is the creation of a working model of the information and its components. Systems analysts use the CASE tools to perform systems development tasks. Three system development methods are structured analysis, which is a common method that is very widely used, object-oriented, is a more recent method that a lot of analysts like, and agile methods, these include the latest trends in software

Business requirements are the set of requirements collected by the business analyst or project manager pertaining to an organization’s vision and goals. The requirements should be well written and defined at a high level, additionally, business problems should be clearly understood before developing the requirements. ECO-Trans, a company that provides technology for transportation services, is working on improving their current system, the ECO-Stream. ECO-Stream uses metrics collected from the transportation network, including road configuration, maximum speeds, traffic, and speed delays. Some business requirements that Varga, ECO-Trans’ project manager, can implement are:

(a) A data model to explain its functional requirements and to produce a formal description

The first information gathering technique to be used will be the review of existing documentation and current system reports. The existing documentation can provide insight into the functions and internal processing of the current system. The system reports are an effective method for the analyst to learn about the existing system and business functions. The reports can also show some of the procedures that the users are currently familiar. The existing documentation and reports are also good to use as discussion tools in another information gathering technique of conducting user interviews.

The interview session has been done by include an open-ended and closed-ended question which are related to the implemented project. Next, sampling technique is executed by system analyst who does evaluation to the current system or prototype. These processes give feedback in evaluation form that filled after tested the system. Lastly, observation is performed by using questionnaire form. According to Burch (1992), the questionnaire is analyzed and transform into structured form that easy to understand. After all information has been collected, structuring of system requirement takes place. It focused on development process modeling which perform “graphically representing the process, or actions, that capture, manipulate, store, and distribute data between a system and environment” (Hoffer, George, & Valacich, 2012, p. 182). In this step, Data flow diagram (DFD) is structured by system analyst using special tools and techniques to create a decision table. According to Hoffer, George and Valacich (2012), decision table is a “diagram of process logic where the logic is reasonably complicated” (p. 200). This table is useful to help system analyst to make a decision toward the project. Then all information’s gained from this phase are documented in System Analysis Report (SAR) that acts as a guideline or reference to the future system development project (Burch, 1992).

The requirements gathering and analysis phase is the most critical phase for the overall success of the project because this phase helps “identify and capture stakeholder requirements using customer interviews and surveys” (Smith, 2016). In order to successfully capture software requirements from the stakeholder, developers need to conduct conference meetings to understand the capabilities of the software. This conference meeting usually takes place only once, so it is essential that developers collect all the information required for the software during the elicitation requirement meeting. For developers to be successful in collecting all the required information, it is a