Elicitation and Gathering of Requirements - Requirements Engineering and Management for Software Development Projects - page 51

3.11 Pitfalls in Requirements Elicitation and Gathering

Requirements management is one of the concern areas of the software develop-
ment. It is also one of the major causes of the failure of the software development
projects. Assuming that requirements in the context of software development are
understood in their right perspective, the following are the pitfalls in elicitation and
gathering of requirements :

1. Untrained personnel being used as Business Analysts is one major pitfall.
Originally Systems Analysts (individuals from the software development fra-
ternity who began as programmers and are promoted over a period of time)
were capturing project requirements. Presently, Business Analysts who are
from functional domains are capturing project requirements. Of course, the
breed of Systems Analysts is not extinct. When Systems Analysts capture
requirements, design considerations creep in and when Business Analysts
capture requirements, budgetary and domain considerations creep in. In the
present day, Business Analysts are drawn straight out of business management
colleges and put on job. This is one major concern. A new-entrant fresh-out-of-
college, even with training on requirements management, would not be able to
capture requirements in their entirety. Either a Systems Analyst or a Business
Analyst, should have put in a few years of working experience in their
respective fields, before imparting training and putting them on requirements
elicitation and gathering activity. This is one major pitfall in requirements
elicitation and gathering.
2. Bringing in consideration of software design while capturing project
requirements—This is another major pitfall especially when the requirements
capturing is carried out by Systems Analysts. Requirements capturing is con-
cerned with ''what'' needs to be achieved and design is concerned with ''how''
to achieve it. Mixing ''how'' with ''what'' causes us to miss some vital infor-
mation that is essential to fulfill the core functionality of the proposed software
product. When capturing the project requirements, we need to take a user's
view point. Often times, because of their proximity to software development,
the Systems Analysts tend to view the requirements from the software point of
view. When this happens, we tend to fit the requirements to the software where
as what we ought to be doing is simply capturing the requirements. Whether the
captured requirements fit the possible software design is to be considered
during requirements analysis stage. We tend to forget that software is proposed
to be developed to fulfill the performance of a set of selected business processes
but not to give a software product and tell the users to fit their working to the
software. This approach of bringing in the design considerations into require-
ments

capturing inhibits the users from giving their view point

comprehensively.
3. Bringing in the considerations of time and budgetary concerns during the
process of elicitation and gathering of requirements—Business Analysts,
especially in COTS product implementation products, take this excuse to