Once a project has been determined to be desirable, it is time to start the detailed information gathering processes. That information is then documented and approved, feeding the next phase in the SDLC process, design.
The purpose of analysis is to gather data on the existing system, determine the requirements for the new system, consider alternatives, and conduct a feasibility study of the solution. The primary output of the analysis phase is a detailed list of the system requirements. Data collection is the first part of analysis. The goal is to understand the data inputs and outputs for the system. There are various sources for data collection. For example, internal sources such as users and managers, organization charts, procedure manuals, reports, and business process flow charts. Other data may be external such as customers, suppliers, government agencies, and competitors.
Collecting data through a report is fairly straight-forward; however, extracting information from people is often a bit more challenging. Some of the ways to solicit information are; direct interviews, observation, surveys and questionnaires. Interviews can be structured where the interview questions are determined ahead of time or unstructured where it is more of a conversation that flows as it would naturally. If the unstructured approach is used, the interviewer should be sure to cover all the important topics and not get lost in the conversation. With observation, the analysis team or member directly sits with a system user to observe that user in the use of the system. This method is very helpful in that the observer is able to see how that user does his/her day-to-day job using the system. This is also helpful to uncover gaps in the way that one user may use the system differently than another one. Questionnaires are a good approach when users are spread across geographical areas and direct interview or observation are not feasible.
Prototypes are made for all kinds of things. When a new submarine is designed, a wooden prototype is built to scale about 10 feet long; it is then put through water dynamics tests to see if it would be seaworthy. In IT development, a prototype may only be a drawing, to see if the users are friendly to the look of it and to see if it has the buttons and so on that the users need for an opening screen. Other times a prototype is more functional (just without error codes, bells, whistles and fancy GUI) to see if the design idea is what the customer is looking for. The trouble with a functional prototype is that it’s expensive to develop — and if you are a vendor this is done before the contract is signed, so if the customer cancels the deal, this is labor unpaid. But if you are IT in-house, it’s a great idea.
E-commerce is the trade and/or sale of goods or services using the World Wide Web. The customer only sees a Web page s/he can access from his/her browser. Behind that is the selling company’s network. A Web server housed at the company communicates with the Internet to send out the site page. Information clicked on or entered by the customer is downloaded to this server and converted to regular data saved on a data server. From the data server, the seller collects and acts on the request. From the internal server, the seller can send e-mail and upload order status to the Web Server.
Requirements: You need to determine the functions of the proposed application, and any hardware that may be necessary to make the new system work. And you need to separate functions of the software, then determine if EACH requirement is mandatory or optional to achieve the goals. For instance, the manufacturing process module might be:
(1) determine the amount of raw materials needed to build each individual product [mandatory – needed to track inflow and outgo of inventory of raw material]
(2) track products produced [mandatory – need to know what inventory has been used up]
(3) decrement inventory needed for each produced product [mandatory – need to know inventory levels in real time];
(4) determine uncharacteristic changes in inventory usage [optional – algorithm can be difficult to determine “uncharacteristic”]
(5) determine low-inventory reorder levels [optional – can be input manually]
(6) automatically reorder specified amounts at reorder level [optional – may change regularly].
Measures of success
Measurement of success is a method to measure the effectiveness of the project, not the efficiency of the project team. Therefore time tables and meeting the budget do not count here. It in part involves the ROI. You need to find those things that save labor time or efficiency that can be quantified — numbers of transactions currently being processed, amount of inventory being recorded in per hour, number of products being manufactured, number of sales per day. Determine what types of these things you can ‘count’ now, and how many are proposed to be the result of the new system, How much labor time and/or money will this save in increased production/sales/efficiency?
Feasibility
A Project Feasibility Study is an exercise that involves documenting each of the potential solutions to a particular business problem or opportunity. Feasibility Studies can be undertaken by any type of business, project or team and they are a critical part of the Project Life Cycle.
When to use a Feasibility Study?
The purpose of a Feasibility Study is to identify the likelihood of one or more solutions meeting the stated business requirements. In other words, if you are unsure whether your solution will deliver the outcome you want, then a Project Feasibility Study will help gain that clarity. During the Feasibility Study, a variety of ‘assessment’ methods are undertaken. The outcome of the Feasibility Study is a confirmed solution for implementation.
Technical feasibility — can the project be achieved with the current systems in place?
Operational feasibility — can the project track/manage/perform the operations (processes) it is proposed to do?
Economic feasibility – can the project be performed within a reasonable budget?
- Research the business problem or opportunity
- Document the business requirements for a solution
- Identify all of the alternative solutions available
- Review each solution to determine its feasibility
- List any risks and issues with each solution
- Choose a preferred solution for implementation
- Document the results in a feasibility report
Statement of scope and goals
The statement of goals; shows an understanding of what the business process is that is desired these goals are listed. Scope, on the other hand is more specific — without expected results or promotional prose. For instance, the scope for a goal of ‘tracking incoming inventory’ could be to the following effect: Set up bar coding process for received materials to electronically enter received shipments directly into database. From here, the requirements can be determined.
COPYRIGHT 2001: BONNIE-JEAN ROHNER. All rights reserved.
The Academic 