Understanding Requirements - Requirements Engineering and Management for Software Development Projects - page 27

feedback and survey of VARS needs to be analyzed to remove duplication and
the feasibility of implementation.
2. Feedback/Surveys from tech support staff—Support staff is in the field and
are the first contact with the customers/end users. They would receive issues,
concerns and suggestions for improvement from the customers. Most product
organizations would have a formal mechanism to capture this kind of infor-
mation during their interaction with customers. When we contemplate a product
upgrade, we need to collate all such feedback and conduct a formal survey to
elicit any further suggestions from the field staff to comprehensively capture all
the expertise gained by the field support executives. The feedback and survey
results can be analyzed to finalize upgrade requirements.
3. Customer/market surveys—Customers are the only people in the supply
chain that can provide first-hand feedback. All others can only provide second-
hand feedback. Therefore, we need to conduct customer surveys. These would
validate the feedback obtained from VARs and field support staff.
4. Personal interviews—We need to conduct personal interviews to validate the
findings of various surveys conducted as well as to uncover any biases or
prejudices that have crept into our survey results. We conduct personal inter-
views on a sampling basis using stratified sampling technique.
5. Freezing of requirements—Once we have collected feedback/survey results
from VARS, field support staff and customers, we analyze the results to con-
solidate the requirements and eliminate duplicates. We select the requirements
for the product upgrade based on their feasibility. Then we document the
requirements conforming to organizational standards and subjecting the docu-
ment to the rigor of configuration and change management.
Project development scenario—The end result of software development either
in the product development or project development is a software product. Then
why should we distinguish product development and project development? The
way I distinguish project development from product development is based on the
use of the end product. In the project development scenario, the end product is
proposed to be used by one customer or one set of end users within one organi-
zation. The end product of product development on the other hand, is proposed to
be used in multiple locations, in multiple organizations, and by different sets of
end users. Because of this distinction, the process of obtaining and finalizing
requirements assumes different levels of importance. In a product development
scenario, we need to spend much more time on finalizing requirements because
any mistake committed during this phase would have a strategic impact on the
final success of the product and the survival of the organization itself. Since the
project is for one customer, the preferences of that customer assume paramount
importance. In the project development scenario, we do not have VARS or field
support staff or multiple customers to cater to. We have only one customer and one
set of end users to whom we should listen to and satisfy them through our software
product. In this scenario, we have two classes, namely in-house project and out-
sourced project. In the in-house project, the end product would be used within the