For something quick all you say you need to do is define the problem ... I find out what problem they are having, a quick description then go to that department and work with the users.

I'd sit with some people, watch their work flow and have them comment as they were doing something ... what they don't like and what they wished would happen.

So, Observation and questions, comments would be my first choice for actually seeing the problem and taking notes.

I'd find out what they want fixed or created and write requirements and functional stuff (UI / UX,  etc.... talk to your technical people for technical specs.

Draw up some prototype to show the users and ask for approval or changes.

Work with development teams.

I would say A & B but if only one option is needed, I would go with B.  This is because the question does not state what type of documentation exists (if any).  You can observe users do work and conduct their business without requiring their attention.  

You will be able to identify the 'types of things' they deal with (aka business entities) such as customers, accounts, widgets, orders, complaints.  

You will surely also come across functionally significant attributes (customer.name, order.status, widget.model number, acccount.number) just but listening to your users go about their business.  

You will even hear many business rules (ex: We cannot approve a new account until you we have a copy of your photo id.)  Observation is a good place to start but relying on observation alone to infer business rules will most likely lead to a disaster. 

At one point in the project, the customer will be forced provide feedback.  If they don't make the time during product design then they will, unfortunately and eventually, provide their feedback when they start using the system and it doesn't work they way the expected.

Adrian