软件需求读书笔记_2006年3月30日

2006年3月30日

　　许多软件问题都源于收集、记录、协商和修改产品需求过程中的方式不当。

　　很少有人会甩给建筑商30万美金而不详细说明自己对房子的想法和要求。相反，他们会不厌其烦地提出各种细节要求。要对房子进行改造就得掏钱，购房者尽管不情愿，却都能理解。然而，在软件开发中遇到同样的问题时，人们却常常轻率地将其忽略。软件项目中40%～60%的缺陷都是由需求分析阶段的过失所致（Davis 1993；Leffingwell 1997）。对欧洲软件行业所做的大规模调查显示：确定和管理用户需求是问题最多的两个环节（ESPIPI 1995）。尽管如此，许多组织仍然没有采取有效手段来实施这两个必要的项目活动。由些导致的结果常常是用户和开发者之间产生需求的鸿沟――二者对产品需求的理解想去甚远。

　　软件或系统项目涉众（stake holder，产品或项目相关人员）的利益之间的相互作用在需求过程中表现得最为强烈。项目涉众包括：

• 客户：为达到其公司的业务目标而投资项目或购买产品。
• 用户：直接或间接与产品打交道，是客户的一部分。
• 需求分析员：负责编写需求并传达给开发团队。
• 开发人员：设计、实现和维护产品。
• 测试人员：确定产品的行为是否与预计的相一致。
• 文档编制人员：负责编写用户手册、培训资料和系统帮助。
• 项目经理：制定项目计划并带领开发人员获得成功。
• 法律人员：确保产品符合所有相关法规。
• 生产人员：制造包含该软件的产品。
• 市场营销、技术支持及其他与产品和客户打交道的人员。

　　如果处理得当，各方利益的相互作用将能够使产品获得成功，同时使客户感到满意，并使开发人员充满成就感；否则，就会导致误解、挫折和矛盾，从而降低产品的质量和商业价值。由于需求是软件开发和项目管理活动的基础，所以涉众必须承诺遵循有效的需求过程。

　　但是开发和管理需求绝非易事，没有任何捷径和魔法。由于很多组织被一些同样的问题所困扰，所以我们可以寻找共同的解决方法，以用于多种不同的情况。

　　如果你的项目中出现以下情况就应该去读读这本书（不要向我借噢！书和老婆一样，不借的！）

• 项目的前景（Vision）和范围（Scope）未曾明确定义。
• 客户太忙，没时间与需求分析员和开发人员一起讨论需求。
• 用户代理，如生产经理、开发经理、用户负责人或营销人员，自诩可以代表用户，其实他们不能准确说出用户的需要。
• 需求只存在于组织中那些所谓专家的脑子里，没有被记录下来。
• 客户坚持所有需求都很重要，不愿排出它们的优先次序。
• 开发人员在编码过程中发现需求有歧义，缺少足够的信息，只能去猜测。
• 开发人员与客户沟通时只关心用户界面，忽略了用户需要用软件去做什么。
• 客户签字确认了需求却又一直提出修改要求。
• 项目范围因接受需求变更而扩大，却没有相应地增加投入或减裁功能，进度因此被延误。
• 需求变更的请求被弄丢，开发人员和客户都不了解所有变更请求的状态。
• 开发人员按客户要求实现的功能无人问津。
• 需求规格说明（SRS）中的要求都实现了，客户却不满意。

　　做公司的一名产品经理，我是很有必要去认真地看看这本书了。上面说明的情况，在项目中间的确是经常出现。