I am reading about requirements analysis as a stage of requirements engineering. I have been having difficulties finding a clear list of the tasks in which the requirements analysis is in charge of. In the whole process of requirements engineering, where does requirements analyst role begin and where it end?
closed as too broad by gnat, Dynamic, GlenH7, MichaelT, Bart van Ingen Schenau Mar 23 '14 at 16:45
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.
There rarely is a single "Requirements Analyst" position. This is mostly done by either "Business Analysts" or in more Agile processes by the Developers.
Requirements Analysis usually takes place after Requirements Elicitation or Gathering. It means structuring and checking the "raw" list of requirements. It can also mean scoping and cutting down the list. Prioritisation and logical coherence checking should be performed as well. Just be aware of the danger of analysis-paralysis, i.e. trying to understand every single requirement in full detail even though it might not be possible and thus never actually going into the design phase. Also be aware not to impose design restrictions in this phase as the requirements documentation should be agnostic of the actual implementation.
In traditional processes the resulting artefact of the Requirements Analysis is a full Software Requirements Specification (SRS, e.g. IEEE 830). Use Case diagrams, Entity-Relationship Models or other models are usually devised in that phase.
In iterative/incremental processes Requirements Analysis is performed during each iteration and usually less document heavy.
A good book on that topic is Karl Wiegers' Requirements Engineering (2).