Requirement
Elicitation or Gathering
There is a
difference of opinion among various Business Analyst regarding definition/
meaning of ‘Requirement Elicitation’ and ‘Requirement Gathering’. Some analysts
opine that ‘Requirement Gathering’ is a process where the requirements are
pretty much defined. Those defined requirements are ‘gathered’ or assimilated
into proper documents which can be forwarded for review and development. There
is no analysis per se. However, some other analysts opine that ‘Requirement
Elicitation’ is more about involvement with the business users for whom a
solution is being designed. "Elicitation" means gathering and
understanding information and analyzing the information to produce the
requirements.
Business analysts
who ‘gather requirements’ are recording existing requirements, whereas business
analysts who ‘elicit’ information are using their analytical skills to define a
solution and requirements to solve an expressed business problem.
Irrespective of the
difference in opinions, business requirement gathering is one of the foremost
and toughest responsibilities of a business analyst. The following problems are
mostly faced during requirement gathering sessions.
- Business Users – Precisely Lack of
communication between stakeholders themselves and between stakeholders and
actual users using the system:-
In my personal experience, the business users think whatever they wish
for should be provided. True, the solution should be catering to their
requirements but not to their wishes.
Also, stakeholders such as the management have vision for a system but
often oversee the fact that the actual users are more interested in using the
system and convenience of user is equally important.
- Vision – Need for a system:-
The management is has a clear view of vision. But that clear view is not
always promulgated to the actual business users. This paves way for conflicting
requirements.
I think an appropriate way for solving above problems, in my experience
so far, would be to first understand the vision from management and get initial
requirements from actual users who will be using the system. After gathering
the requirements, it was easy to sort the requirements according to the scope.
- When and where to freeze the requirements:-
Each time the requirements are sent for approval, often business users
come back with new requests. This majorly occurs when the business user has
interacted with other systems. To freeze the requirements, the best possible
way is to sort the requirements based on the defined scope and clearly freeze
those requirements which meet the scope. Once freezing the requirements, all
other requirements can be added later as part of enhancement.
4.
Problem of volatility:-
Volatility is defined as the changes in the requirements. The higher the
volatility in requirement gathering process, the higher the difficulty in
freezing the requirements. I think the appropriate way is to define a scope for
the first delivery and freeze the requirements accordingly after first few
initial sessions with actual users.
These were the
problems that were faced by me during requirement gathering process. Others may
have faced different issues. Some business users are definitely more accurate
in stating their requirements and this helps in quickly finishing the entire
process. But some are not. Business Analysts have to adapt on the fly to
finalize the requirements.
Sources:
Comments
Post a Comment
Please let me know your thoughts on this post.