4 Issues in Requirements Elicitation

　　4、需求捕获的问题

　　Eliciting requirements need not be like pulling teeth … but sometimes it is. The problem is lack of preparation by the software engineer and lack of interest by the organization or person requesting the work. One would think that the customer would be very interested， since the software to be built solves a problem that the customer has. But often， the customer expects the developer to "know" and has little interest in spending time doing "computer stuff." A mistake， no doubt， but reality none the less. One can use the Requirements Elicitation Success Measurement checklist to identify where your project stands as far as the success of the requirements elicitation is concerned. For this checklist， the more questions that elicit a negative response， the higher the risk that the requirements elicitation will fail.

　　需求捕获不象是拔牙…但也比较类似。常见的问题是，软件工程师缺乏准备，同时需要该产品的组织或个人缺乏兴趣。一般大家都会认为客户会对产品很感兴趣，因为该产品会解决客户面临的问题。但通常客户希望开发人员已经知道相关知识或不愿意耗费时间为软件产品提供基础材料。无疑，这些观点是错误的 ，但是客观存在的。可以使用需求捕获列表来验证你的项目在需求捕获方面进展如何。在这个列表中，越多问题的答案是否定的，那么需求捕获失败的可能性就越高。

　　Requirements engineering consists of activities like requirements elicitation， specification and validation.

　　需求工程包括的活动有需求捕获，需求定义和需求验证。

　　The hardest single part of building a software system is deciding what to build… … No other part of the work so cripples the resulting system， if done wrong. No other part is more difficult to rectify later.

　　开发软件系统最艰难的部分在于确定要开发什么。而这一部分又最可能导致系统的失败，最难以在后继的工作中加以矫正。

　　Issues involved in this problem area include：1. Achieving requirements completeness without unnecessarily constraining the system design 2. Analysis and validation difficulty 3 Changing requirements over time

　　在需求的问题上有这样一些观点：

　　1、到达需求的完整性会束缚系统设计。

　　2、需求分析和验证比较困难。

　　3、改变需求会消耗额外的时间。

　　Many requirements errors are passed undetected to the later stages of the life cycle and correcting those errors during or after implementation phase is found to be extremely costly.

　　许多未被发现的需求错误被传递到生命周期的后继阶段，在后继阶段更正这些错误将花费更多。

　　Problems of RE can be grouped into three categories：。 Problems of scope， in which requirements may address too little or too much information。 Problems of understanding o Users have incomplete understanding of their needs o Analysts have poor knowledge of problem domain o Ease of omitting “obvious” information o Conflicting views of different users o Vague and un-testable requirements e.g. “user friendly” & “robust”

　　Problems of volatility i.e. changing/evolving nature of requirements

[1] [2] [3] 下一页