Few companies will permit taking the time to completely stop and fully document a system with a heavy weight documentation process. So the analyst needs to start with a lightweight process for documenting features and requirements rapidly.

Features tend to be readily apparent in the implementation of a system. However, the underlining requirements and rationale for the features are not as apparent.  

First the analyst can document features and sub-features quickly using a feature tree diagram (based on the Fishbone Diagram).  This helps organize features hierarchically.  Most features are evident by examining the user interface. However, doing a cursory code review can uncover other less noticeable features as well as business rules associated with many features.  When you find business rules, be sure to document them.  Once feature identification is deemed to be complete the requirements should be documented in list form or in a database so that they can be mapped to business rules and, more importantly, to the requirements that will be documented.

The next step is to identify the requirements which led to the inclusion of the features in the first place. This will allow the team to avoid requirement conflicts in the future. Since we've already stated that time is a luxury it makes sense to use agile techniques to document the requirements rapidly.  User stories are great for such a case. Reach out to the end users of the system and ask them what they use the system for, how they use it and why they use it in the manner they do.  How does the system create value for them?  Construct a quick set of high level User Stories to document the What and Why.  These are your requirements.

The User Stories don't have to be completely detailed out all at once. Create simple 1-3 sentence User Stories representing each requirement.  Along with the user stories, acceptance tests and business rules should be associated to each, but this can be done on an ongoing basis as more is learned about the system through future iterations and updates. 

Once the features have been identified and the user stories have been created, the analyst can map the two together reasonably well.  The organization now has a reasonable understanding of the requirements of the system and can avoid conflicting requirements in the future.