How to document an existing system [requirements document]

One of the bigger challenges as an IT Consultant is when you are asked to help define and document an existing system. Here are some of the challenges, thoughts, and considerations on should have:

• The greatest challenge is balance between real requirements and system constraints.
• How can one balance what users of a real system expect, versus what they would have at the outset of the system. There is a balance to be maintained between the “real” requirements, which existed before the system was in place and those that now pop into the heads of the developers and users. The odds are they might not have said the system needs x, y, and z integrated functions until they have been using it for several weeks.
• The document must be instantly useable to guide future development and testing, which is hard. An existing system has existing users, which means there will be requests very soon to change the system (either corrections to bugs, or enhancements). These enhancements might have been deficiencies to the original system design, which did not have the guidance of the user base’s requirements.
• It HAS to be valuable in analyzing and engineering future system changes; if it doesn’t make sure that future changes don’t conflict with existing functionality, it is not worthwhile.
• Requirements documents are always a challenge to write, and to be useful in general. Let alone when the system is in place and being used.
• Is the client committed to using a requirements baseline? Will they maintain it? How will they do so? Who will maintain it and use it?