If you don't know what you've got to do, you'll either do nothing or do the wrong thing. Equally, having an ill-defined requirement is as bad, if not worse, than having no requirement at all. We've all seen the swing cartoon!
Requirements Analysis, Requirements Capture, Requirements Definition - there all the same thing but with different names (I will use Requirements Analysis or RA from here). If you don't do one expect some very odd results, some large expenses and some angry people. Ultimately, and I've seen it happen, the system may simply not get completed.
Do yourself a favour, if someone recommends that you carry out a requirements analysis, take the time, pay the money and as Nike would say "Just Do It!" But here are my words of warning - Do It Properly!
What should you expect?
Depending on the complexity of what you are attempting to address (please refer to project scoping) an RA can take a few days to several weeks. (To be honest with you, if its going to take several weeks you should really consider whether your scope is correct.)
From the outset all the stakeholders should be invited to a presentation during which they will learn what the project is attempting to achieve, and if a technology has already been chosen, what the technology is, and is not, capable of providing.
Once everyone knows what is to be achieved, they will be more focussed when you get to speaking to them on and individual or small group basis which is the next step. During these meetings/interviews the analyst or consultant will be seeking to understand the processes of managing identities for individuals, departments and how the systems involved handle the data particularly how it is stored and what interfaces are available to work with the data.
The consultant or analyst will likely discuss whether the current processes are defined and documented or whether they have evolved. It is not unknown for processes to require redefinition or formal agreement within the organisation as part of the project. Be prepared for some interesting conversations between various groups within the organisation that may result in improvements to the processes before any automation takes place.
A high-level design is what comes from a requirements analysis. It is not until technical designs are completed that any detail regarding data flows and data transformations, operating systems, hardware and network will be available.
And finally ...
... you should expect to agree and accept every requirement. Failure to agree and accept each and every requirement just brings us back to odd results, extra cost and angry people.
I have carried out numerous Requirements Analysis for organisations in the Finance, Media, Telecommunications, Local Government, Manufacturing and Education markets.