The purpose of the preliminary investigation is to establish the user requirements, determine what alternatives may exist for the current system, and what factors may affect those alternatives. The project team for the preliminary investigation usually consists of the users, business analysts, and systems analysts. The number and type of participants will vary depending on the size and scope of the project.
The scope of the project is critical to the development of realistic solutions. A project's scope is defined as the boundaries within which the project team may propose solutions. The scope cannot incorporate business areas outside of the area being investigated, unless otherwise specified. For example, if a team was brought into an ice cream store to investigate the systems in that franchisee's store, the team cannot make recommendations that will require the franchisor, or suppliers to modify their respective systems. Only the systems internal to that particular ice cream store can be considered. If the store was large, and the team was asked to investigate the accounts payable system, they would not be empowered to recommend changes to any other system in the store. The scope of a project is limited to the project area, and can only affect other areas through the interfaces that may exist between the system being investigated and those other systems (such as, forms generated by this system for data input or output) .
Background gathering is vital to the understanding of a systems project. The background includes a short history of the organization, and of the business area under investigation. The background helps to establish both the nature of the enterprise, and the nature of the problem because it places the problem within the context of the organization and the organization's place within the external environment.
Some of the key points to look for when gathering background information are:
The vision of an enterprise is a statement of its intended purpose. All enterprises, whether they are for-profit, or not-for-profit, have a vision. Often this vision exists primarily in the mind of the owner, chief executive officer, or board, and has never been formalized in writing. This can lead to the vision becoming clouded as time goes by, and often results in the vision not being imparted to the general rank and file of the organization. When the vision is not clear, or understood, an enterprise can often flounder, or fail.
The mission of an enterprise is based on the vision, and is a set of statements, some long term and some middle term, that clearly addresses how the organization intends to fulfill the vision. The mission statement should be written, however, in practice it often remains verbal. When the mission is not written, the result can be confusion in the goals of the enterprise, and a sense of preparing to go nowhere. At the work unit level, business goals determine the short term plans for achieving the mission of the enterprise. These goals form the business functions from which the business processes will be determined. For more information on business functions, please attend the business function presentation.
It is critical for the problem to be properly identified. Often symptoms can be misinterpreted as problems because symptoms are most readily seen by the users. For example, a retailer may think that the reason for a decrease in sales is because customers are not buying as much at a time as they may have done in the past. However, upon investigating the situation it is discovered that the retailer changed to new cash registers that require more input, and the resulting increase in check out time has made customers wary of buying more items. The retailer saw a symptom, not the problem.
The problem definition should be written in the form: "The problem is that..."
The project objectives are tightly related to the problem definition. Once problem is properly identified, the project objectives can be developed to solve the problem. The project objectives are part of the user requirements, and indicate what the user wishes to accomplish. It is important that the project objectives be stated in a form that will permit a future evaluation, or audit of the new system. This is achieved by using a specific format termed "the terms of reference."
The terms of reference are a series of statements which are intended to solve the problem. Each term of reference must possess three features to be valid:
For a term of reference to be a benefit, it must provide an observable result. For example, "To increase sales..." Measurability provides a means of testing the observed result. For example, "To increase sales by 15%..." A time frame is necessary to establish how quickly the observable result will be achieved. For example, "To increase sales by 15% within one year."
User requirements are a combination of the project objectives and the various constraints that are placed on the project by the users and the environment. This includes:
Environmental factors are factors that can affect possible solutions. Before possible solutions can be generated, it is vital to consider what may restrict the spectrum of solutions. These factors are divided into three groups:
Organizational factors are inherent to the organization and its external environment. These will include:
People factors are dictated by the individuals within the organization. They include:
Technological factors represent the existing, planned, and possible technology that can form part of the solution. It is important to note that manual, and mechanical are technologies, as well as computer technology. Many analysts assume that computer technology is the answer, when there are occasions when computer technology should be removed in order to achieve the goals of the project. Technological factors include:
In the preliminary investigation, the alternative solutions are not given much detail. They are meant to explore the possibilities given the constraints of the environmental factors and the user requirements. They are general solutions, such as "A computerized database system may provide a solution," or "The addition of an adding machine to the equipment available to the cashier, may assist in reducing the cashing out time."
The context diagram, which is also known as a Zero Level Data Flow Diagram, is an important tool in understanding how the system interacts with its environment. This diagram consists of a box representing the system, and several external entities which interact with the system by providing input, or accepting output. These external entities are external to the system, not necessarily external to the enterprise. For example, a Supplier can be an external entity, and the Accounts Payable System (part of the enterprise) can also be an external entity of the Sales System.
Arrows, representing data flows, enter and leave the system. Each data flow is uniquely identified by a compound noun. Two data flows may only have the same name if they represent exactly the same data. At the level of the context diagram, the data is also compound. For example, the data flow "Invoice" may consist of data elements: Sold_to_Name, Sold_to_Address, Customer_Number, Line_Item, Item_Description, Item_Cost, Order_Quantity, Shipped_Quantity, and Shipping_Charges (obviously we could keep going on with more detail). On the Context Diagram, only Invoice will be shown. The details are given in a Data Dictionary which is built during the analysis stage (this is not included in the introductory systems analysis and design module).
For more information on how to develop a Context Diagram, please attend the Context Diagram presentation.
Before writing the recommendation, it is important to recall the purpose of the preliminary investigation. The principle question that the user is interested in having answered by the preliminary investigation is, "Is there sufficient evidence to believe that a new system may answer the problem? Why, or why not?" Using the information gathered during the preliminary investigation, make a recommendation to continue to the analysis phase, or to cancel the project, and provide reasons why the recommendation is being made.
The preliminary investigation report signals the end of the first phase. It is presented to the user, and if the user agrees with the recommendation of the report, the project proceeds, or ends, as recommended. The key to writing a good preliminary investigation report is to write the full report first, then summarize the entire report in the executive summary. The components of the report are: