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

I gave these examples to enunciate the difference between ''elicitation'' and
''gathering'' of requirements in the context of software development. Elicitation is
to obtain by enquiry. Elicitation is the first hand collection of the information from
either the individuals performing the business processes or by observation. On the
other hand, gathering connotes that something is already available, scattered or
lying around and that it is there to be collected. Thus, gathering, basically, is
collecting information from secondary sources which are published materials,
records, process documents and so on. In requirements management, both elici-
tation and gathering techniques are used to collate information to analyze and
finalize requirements for the proposed software product. Even in organizations that
do not use documented processes to guide the performance of business processes,
Business Analysts need to refer to formats and templates for gathering information
about the formats of the reports and enquiries to be included in the proposed
software product.
The following are some of the documents that we study to gather project
requirements :
1. Organizational records—These are logs of activities carried out in the orga-
nizations. They give information for the design of database, maximum lengths
to be provided for various fields, the size to which the data can grow over a
period of time and so on. The following information becomes available from
organizational records:
a. Number of tables that may have to be designed—each type of record can
roughly correspond with a table in a database. Sometimes, for example a
purchase order in a material management application, can spawn out to
more than one table.
b. Number and type of fields in various tables—each column in a record can
roughly correspond with a filled in table. It is also common in manually
maintained records to include more than one data item in one column (such
as address) against a row, in which case, each distinct data item corre-
sponds to a field.
c. Maximum lengths for each of the fields—Often times, the end users specify
the average length for a field than the maximum that may occur. Records
are one good source to determine the maximum length necessary to hold
data in a field.
d. Relations between various tables—study of records would reveal the
information drawn from other records which could help in determining the
relations between tables in the database.
e. Size of tables—the number of records gives an idea of the number of
records and the time frame in which they accumulated. Extrapolating these
numbers, we can determine the size to which each table can grow over a
period of time. This information coupled with the organization's data
retention policies can help us determine the database growth strategies.