Current Systems Analysis


"Only when the Systems Engineer can walk in the moccasins of the user does the engineer have a right to design a system for the user."
- Bryce's Law

The subject of current systems analysis is usually greeted with dismay or disdain by systems departments. There are many reasons for this. In many installations, the support of current systems takes more than 85% of the systems department's time, and the departments are more than ready to get on with new systems development and bury the old, non-working systems as quickly as possible. In cases where systems do not require a lot of maintenance, the systems department may find that the current systems are not giving management the kind of information it needs for effective decision making; these current systems become likely candidates for replacement.

However, there are some very legitimate reasons for documenting existing systems:


  1. The documentation process will make development personnel more knowledgeable about the enterprise's business. Users often complain that the systems people are ignorant or naive about the business, and usually there is some justification in this complaint. The process of capturing current systems will educate Systems Engineers in the business of the company.


  2. Documenting current systems will clearly show:


    • What information is being produced.


    • Who is using the information and how.


    • What data resources are being used (data, records, files, inputs, outputs).


    • What processing is being executed, and what is not.

    Quite often, user personnel do not use existing systems simply because they do not understand the purpose of the system or how it is to be used. If a system has been properly documented, perhaps only a few modifications are required as opposed to a major new development effort. Unless we understand clearly what the old system is doing, how can we design a new system to replace the old? How can we plan the conversion from the old to the new? Most of the current system contains resources that will be reusable for the new system. Data, records, files, inputs, outputs - most, if not all of these can be reused in systems development.

    Weaknesses and misusages of current systems will also be uncovered. Because of inadequate documentation, it is not unusual to see a good system be misinterpreted by users, including operations personnel. As a consequence, the system is only partially utilized and the benefits not fully realized.


  3. Programs and files which only serve the purpose of unnecessarily occupying computer storage space can be identified and removed.

Capturing current systems can be a huge undertaking. A single company can have hundreds of systems and sub-systems, and thousands of procedures and programs, some of which are very old. It is important to remember that the intent here is to ONLY IDENTIFY AND DESCRIBE THE CURRENT SYSTEM, NOT TO CORRECT DEFICIENCIES. Quite often, there is a temptation to try to correct an obvious problem at this stage. As a consequence, the task of capturing current systems takes longer and longer. When errors or problems are spotted they should be documented as future Modification/Improvements and not corrected as part of this effort.

How much definition is enough? Ultimately it is based on the organization's needs. No two companies will approach the problem in the same way. Their requirements will vary. However, simplicity is recommended when describing the various information resources.

Capturing current systems is an exercise in reverse engineering. Whereas, system design is a top-down effort, current systems analysis begins with an examination of the procedural flow and works up and down the system hierarchy.

What systems or sub-systems do you begin with? Start with those that provide operational information - those that are at the heart of the business operations. Those parts of the systems that provide policy and control information can be delayed until the operational systems have been captured, since they will require the same data created in the operational systems.

If you would like to discuss this with me in more depth, please do not hesitate to send me an e-mail.

Keep the faith.


Author: Tim Bryce is a writer and management consultant with M. Bryce & Associates of Palm Harbor, Florida and has over 30 years of experience in the field. He is available for lecturing, training and consulting on an international basis. He can be reached at [email protected]  Comments and questions are welcome.

His writings can be found at:
The "Management Visions" Internet audio broadcast is available at:

Copyright © 2008 by Tim Bryce. All rights reserved.



Copyright 2006-2023 by Modern Analyst Media LLC