Previous | Table of Contents | Next |
Functional Requirements
The functional requirements document is the blueprint for an applications development project. It should contain, directly or by reference, all of the basic information to execute the remainder of the project. This information also needs to be presented clearly to provide for effective tasks and avoid the confusion that leads to lost time and wasted resources. Functional requirements information can be grouped into the following four categories:
The final delivered document must be carefully reviewed and approved before the actual development begins. The functional requirements study is often the most difficult part of a project, consistent with its being the most important. It asks that specialists in three disciplinesbusiness operations, finance, and information technologywork effectively with each other. These specialists will need to work with managers, accountants, and users at all levels who understand the companys true needs to establish these requirements and review the functional requirements document.
Application Documentation
The total investment in an application is at risk if that application is poorly documented, or not documented at all. People cannot be expected to know and remember everything they might possibly need to know to use, operate, and maintain a complex system. When they need to refer to the application documentation, it is most often to solve a problem, and at a time when that problem needs to be fixed. If programmers/analysts need to repair or improve an application, they will need comprehensive technical information about the programs and their interrelationships. This type of information also helps when new personnel, whether technical or end user, are being trained. Adequate documentation usually includes:
Current Technology
Systems development projects should always include time to consider using proven technology, new technology, or both. IT management must keep up with technological innovations that might improve the effectiveness of its application base systems and should use this technology whenever it passes the appropriate cost-benefit test.
Hardware Acquisitions
Requirements should be clearly defined before any hardware is acquired. When possible, applications should be designed to operate on existing equipment. The IT auditor should confirm that, throughout this process, application development projects should be driven by the companys information needs and the overall costs and benefits involved.
Training
Effective training can greatly reduce the tension often associated with major changes in the workplace besides being necessary for operating and using the system. Some positions will change, and sometimes it is impossible to know in advance which ones and to what extent. Training, counseling, and familiarity with the system can greatly smooth the transition and minimize resistance to change. In addition, training is important to ensure that the applications potential is realized to the companys benefit, and to avoid the tendency of many people who prefer to do things the same as in the past.
Acceptance Testing
Acceptance testing is conducted by the end users before a system is placed in operation to ensure that it will perform as designed. Acceptance testing plans should be prepared by the end users, or at least, someone that was not involved in development, to increase the probability of getting valid results. If the developer prepares the acceptance testing planparticularly if the developer misunderstood the requirements or if there was an error in the final function requirements deliverablethen there is a very high risk that the test plan will not detect the resulting error in the application.
Acceptance testing should always be a formal and well-documented process, with the applications complexity driving the degree of the final documentation. The testing plan should indicate the elements needed to perform the testing, how the tests will be performed, and how the results will be recorded.
Errors, problems, and even simple questions that arise during acceptance testing should be categorized as either needing resolution or not. If an item needs resolution, then the implementation should not proceed until it has been resolveddefined as passing the relevant acceptance testing procedures.
Implementation
Senior management is ultimately responsible for knowing that new applications are developed and tested before implementation to reduce any risk to the overall continuity of the company. They may delegate this responsibility to an IT Steering Committee, but it should never fall below the IT Project Manager level.
The IT auditor should ensure that this responsibility is not delegated to his or her own department. It may be flattering to be asked to participate in every application development project, but this philosophically compromises the auditors independence. The IT auditor should only participate to the extent needed to reach a conclusion on the controls in the SDLC methodology, to opine on a particularly sensitive project, or to bridge the gap until the company can build effective controls into its processes.
The IT auditor should also remember that it is unrealistic to try and eliminate every potential problem prior to implementation. Some unanticipated problems may occur, and provisions need to be made for resolving these problems as they arise.
The IT auditor should evaluate the companys decision on whether to use parallel processing in the acceptance testing and implementation phases of a project. Parallel processing may be required in many high-risk situations, but there is no doubt that it can produce new applications that are very reliable. The primary parallel processing advantage is that everyone can see if the new application can at least duplicate the existing application. Its disadvantages include its cost, double work for the technical and end users, and potential disruptions to regular work activity.
Quality Control Review
The SDLC methodology should include a review by an individual who has technical knowledge but is not close to the project. This review should focus on problem areas and omissions, but may also take the time to consider better ways of accomplishing the applications work. The independent reviewer should use a checklist to ensure that nothing is missed and to document all relevant points.
(Note: Workpaper I-3-1 provides self-assessment questions for each of the critical general control areas described in this part.)
Previous | Table of Contents | Next |