The analysis phase involves analyzing end-user business requirements and refining project goals into defined functions and operations of the intended system. A good start is essential and the organization must spend as much time, energy, and resources as necessary to perform a detailed, accurate analysis. The three primary activities involved in the analysis phase are:
1. Gather business requirements.
2. Create process diagrams.
3. Perform a buy versus build analysis.
1. Gather Business Requirements
Perhaps, the most crucial component of the analysis phase is the development of business requirements. Business requirements are the detailed set of business requests that the system must meet to be successful. At this point, there is little or no concern with any implementation or reference to technical details. For example, the types of technology used to build the system, such as an Oracle database or the Java programming language, are not yet defined. The only focus is on gathering the true business requirements for the system. A sample business requirement might state, “The system must track all customer sales by product, region, and sales representative.” This requirement states what the system must do from the business perspective, giving no details or information on how the system is going to meet this requirement.
The Software Engineering Institute (SEI) defines the objective of requirements management as ensuring customer requirements are the focus of the project from inception to delivery. Any changes must be tracked with corresponding updates made to project documents and plans. Requirements management is the process of identifying, documenting, communicating, tracking, and managing project requirements as well as changes to those requirements. It is not a single point in time occurrence, but rather must be an ongoing process that stays in lockstep with the development process. Losing sight of requirements is often the first step on the road to over-budget, late projects that do not meet specifications, or end up cancelled. The most important step in deciding project requirements is obtaining user input on written business requirements. Gathering business requirements is basically conducting an investigation in which users identify all the organization’s business needs and take measurements of these needs.
A solid understanding of user requirements helps to define application capabilities throughout the project’s life cycle. Projects in which users or user groups have a good understanding of their true needs have a better rate of return and lower risk than those that have broader requirements. Often, users find it difficult to articulate their true needs or the IT team misinterprets them. This leads to a compromise during this phase whereby questions remain unanswered and a communication gap develops between the user community and the IT team. It is essential that the project manager, together with the development team, get the business requirements right! The requirements definition document contains the final set of business requirements, prioritized in order of business importance. The system users review the requirements definition document and determine if they will sign off on the business requirements.
Sign-off is the system users’ actual signatures indicating they approve all of the business requirements. One of the first major milestones on the project plan is usually the users’ sign-off on business requirements.
2. Create Process Diagrams
Once a business analyst takes a detailed look at how an organization performs its work and its processes, the analyst can recommend ways to improve these processes to make them more efficient and effective. Process modeling involves graphically representing the processes that capture, manipulate, store, and distribute information between a system and its environment. One of the most common diagrams used in process modeling is the data flow diagram.
A data flow diagram (DFD) illustrates the movement of information between external entities and the processes and data stores within the system. Process models and data flow diagrams establish the specifications of the system. Computer-aided software engineering (CASE) tools are software suites that automate systems analysis, design, and development. Process models and data flow diagrams can provide the basis for the automatic generation of the system if they are developed using a CASE tool.
3. Perform a buy versus build analysis
An organization faces two primary choices when deciding to develop an informa tion system: (1) it can buy the information system from a vendor or (2) it can build the system itself. Commercial off-the-shelf (COTS) software is a software package or solution that is purchased to support one or more business functions and information systems. Most customer relationship management, supply chain management, and enterprise resource planning solutions are COTS. Typically, a cost-benefit analysis forms the basis of the buy versus build decision.
Three key factors an organization should also consider when contemplating the buy versus build decision are: (1) time to market, (2) corporate resources, and (3) core competencies.
Weighing the complex relationship between each of these three variables will help an organization make the right choice. When making the all-important buy versus build decision consider when the product must be available, how many resources are available, and how the organization’s core competencies affect the product. If these questions can be definitely answered either yes or no, then the answer is easy. However, most organizations cannot answer these questions with a solid yes or no. Most organizations need to make a trade-off between the lower cost of buying a system and the need for a system that meets all of their requirements. Finding a system to buy that meets all an organization’s unique business requirements is next to impossible.
