Previous | Table of Contents | Next |
The IT Audit Professional should be careful when deciding how to allocate resources between the requirements definition phase and the remaining phases. Poorly defined requirements will almost certainly result in systems that do not meet the organizations objectives.
The IT auditor is likely to find that defining requirements is an iterative process. This is appropriate because most employees spend their time focused on how their work has to be done, and do not spend time considering new alternatives for that work. Their lack of experience with systems design makes it difficult to adequately define the requirements for an application.
Audit objectives: The audit objectives during the definition phase are to evaluate how well the end-user needs have been defined and translated into the requirements definition, and whether the appropriate internal controls have been included in the final requirements document.
These audit objectives are accomplished by participating in selected definition meetings and review draft and final requirements deliverables. In addition, the auditor may choose to look directly at the participants in the process and evaluate their individual performance.
The requirements definition phase refocuses the organizations attention from the needs and opportunities and on to the solutions. The systems analysts must identify the inputs, processes, and outputs that will meet the end-user needs as expressed in the initiation deliverables.
The analysts, or systems designers, usually spend most of the time in this activity involved with end users, other company personnel, and in certain cases third parties such as customers, attorneys, and the like. The IT auditor may be a direct party to the process, depending on the organization.
Once the requirements have been defined, there is another significant approval point, whether the magnitude of the project is great or small. The auditor should confirm what actions were approved as early as possible in the definition phase so that any deviations noted by the IT auditor that are not caught by the development process can be properly addressed.
The IT Audit Professional should find that the definition phase has another significant output: a much more specific plan for the remaining development effort. A preliminary plan had to be included in the initiation phase as part of the estimate of total project costs.
The final plan is dependent on the final requirements, as the definition process is likely to either have some changes or else just be better understood. It defines the goals and activities for all remaining project phases, including resource estimates, goals, and expected methods to the extent they are not identified in the standard systems development life cycle methodology.
The IT auditor is likely to find that there many more participants in the definition phase than in the initiation phase. Instead of a sample of end users all critical end users, should participate, along with all necessary systems analysts and other concerned parties.
Participants and Their Activities. The IT auditor is likely to find that the major participants and their activities are described in the paragraphs below.
Senior Management. If this is not done within the Project Steering Committee, then senior management will approve the initiation phase deliverable, consulting with other project participants as needed.
Project Steering Committee. This committee may approve the initiation phase deliverables if it is within their signing authority. This committee should also approve the project plan and requirements definition document.
Project Sponsor/Project Team. They will do the specific development of the project plans and provide the initial approval of the deliverable for the current phase.
Information Technology Manager. This person provides consultation and review of the project plan, functional requirements document, and data requirements document.
Security Specialist. This person selectively reviews project plan, functional requirements document, and the data requirements document.
Quality Assurance Specialist. This person reviews and evaluates the system decision paper, project plan, functional requirements document, and data requirements document, monitors compliance with the development methodology, and may even directly participate in the development of these items.
The IT Audit Professional may find the information and data most often included as deliverable information from this phase recorded on up to five different deliverable documents. Just as in the initiation phase, the number of deliverables is not significant provided the necessary information is present in the deliverables provided.
The IT auditor should also evaluate whether each phase includes a requirement that the original cost/benefit analysis be updated, and the updated information included in the deliverables. This is crucial if the organization is to have the opportunity to evaluate the reasonableness of proceeding with a particular project.
Most IT Audit Professionals are not accustomed to seeing this step in their organizations systems development methodology, because almost no company will discontinue a project once the initial approval has been given. The project scope may be altered, the timeline may be changed, but there are usually too many political considerations for a project to be stopped.
The IT auditor should consider challenging this situation, due to the increasing demand for development resources in a downsized and outsourced environment. The modern organization should be able to recognize an error and realize that scarce resources that could have more effect spent on another development project should be spent there.
One possible set of definition phase deliverables and the information they should most likely include are shown below.
The updated project plan: Any changes that were identified during the definition phase should be reflected in the original project plan, and the updated document should be sent to the original distribution so that those individuals have access to the updated information. As before, the updated project plan should outline the remainder of the development effort.
The Functional Requirements Document. This deliverable captures the detailed information that the systems developers will use as their guide for preparing input screens, coding the automated processes and interfaces, and defining required outputs.
The Security and Control Requirements Document. This deliverable identifies the specific security and control requirements for the application. These need to be identified in the requirements phase so that the security and control procedures can be implemented along with the application.
The Data Requirements Document. This deliverable should provide a detailed description of the data the application will require as an input, along with a similar description of the data that will be generated by the application and thus be available to end users and other applications.
The data requirements document should also describe the potential threats related to this data for use in defining access security, in formal risk analyses, and other uses that may be identified later. This is a good example of information that could be part of another deliverable, such as being included as an appendix to the data requirements document.
The IT Audit Professionals basic evaluation of the requirements definition phase will involve reviewing the previously developed deliverables along with the documents produced in the present phase. The IT auditor should also have the documented results of the initiation phase review available for reference.
The initial evaluation should bring the IT auditor up to speed with the status of the development project. If the phases are brief, the initial evaluation in this and later phases may not be necessary. It is more common for several weeks or months to elapse between the conclusion of one phase and the conclusion of the subsequent phase.
Previous | Table of Contents | Next |