So, who is the requirements analyst? He has to perform several roles at once. He has to be a translator, since he is responsible for capturing the requirements expressed in the language of the user or customer (typically a non-technical language) and translating it to the language understood by the technical project resources.
"The car must be really fast"
"The car shall be able to travel at a speed of up to 100 mph"
She has to be a keen observer, since she has to observe the work performed by the user from the user's rather than from the technical resource's perspective.
The requirements analyst has to be an interpreter of the work to be performed; in other words he should be able to reveal the essence of work, not its incarnation.
"The bottle opener must be rectangular in shape"
"The bottle opener shall be able to open bottles with both round and rectangular necks"
Very frequently the requirements analyst is someone who invents better ways of performing the work described by the user.
“The dryer should have different drying cycles to accommodate for different types of loads”
“The dryer shall have three different drying cycles (small, medium and large)”
“The dryer shall have a dryness sensor that will shut the device down once the laundry is completely dry”
Requirements analyst is also a scribe who should be able to record the results of her analysis in the form of stakeholder-understandable requirements specifications and analysis models that are necessary, verifiable, attainable, unambiguous, complete, consistent, traceable, concise and prioritized.