第5章 切削加工基本知识.doc

软件需求 软件需求（第3版） 第 第1章 软件需求的本质 - -? PAGE 36?- - -? PAGE 37?- 第Ⅰ部分 软件需求的3W（什么、为什么和谁） 第1章 软件需求的本质 第2章 从客户角度审视需求 第3章 需求工程优秀实践 第4章 业务分析师 第1章 软件需求的本质 “喂，Phil吗？我是人事部的Maria。我们在使用你开发的人事系统时遇到一个问题。有位职员刚刚把她的名字改成Sparkle Starlight，但我们无法在系统中改。你能帮个忙吗？” “那么她是结婚了，随老公姓Starlight？” “没有，她没结婚，只是改名字了，”Maria回答道，“问题就出在这里。好像我们只能在某人婚姻状况发生变化时才能在系统中改名。” “好吧，是，我从来没想过有人可能会改自己的名字。当初我们在讨论系统的时候，你可没告诉过我有这种可能性。” Phil答道。 “我以为你知道任何人随时都可以合法更改名字呢，”Maria回应道，“我们得在星期五之前解决这个问题，否则Sparkle就领不到工资了。你可以在此之前修复这个bug吗？” “这不是什么bug，好吗？！” Phil反驳道，“我从没想过你们需要这项功能。我现在正忙着做一个新的绩效评估系统。你所说的问题我只能在月底修复，但周五之前肯定不行，抱歉。下次如果再有类似情况，请早点告诉我，并请提供书面材料。” “那我怎么和Sparkle说呢？”Maria追问道，“如果她领不到工资，会很难过的。” “嗨，Maria，这不是我的错，”Phil抗议道，“如果当初你早提醒我你需要能够随时更改某人的姓名，这种事情就不会发生。你不能因为我没猜透你的想法就怪我。” Maria怒了，但又无可奈何，只好厉声说：“是，你说的都对！好吧，这种破事儿让我对电脑简直是恨之入骨。问题解决好了，就马上打电话告诉我，可以吗？” 如果你是以上对话中的客户一方，就会明白无法使用软件系统来完成一项基本任务多么令人沮丧。你会痛恨自己得求着开发人员，因为关键变更请求最终掌握在他们手中。另一方面，开发人员也很沮丧，因为他们只有在系统开发完成之后才会明白用户期待有哪些基本功能。对于开发人员来说，更恼火的是，得中断手头的项目去修正以前已经完成的系统（因事先未被明确告知而疏忽的需求）。 软件中的很多问题大多数来源于人们了解、记录、协商和修改产品需求的方法不当。就Phil和Maria这个例子而言，问题就包括：信息收集不正规；功能隐晦；对假设功能有理解上的分歧；需求指定不明确以及变更过程不正规。很多研究表明，软件产品中发现的缺陷有40%～50%是在需求阶段埋下的“祸根”（Davis 2005）。在具体说明客户需求和管理客户需求过程中用户输入不足和有误，是造成项目失败的罪魁祸首。尽管证据确凿，但很多组织仍然在实行这些没有什么成效的需求方法。 在软件项目中，所有干系人的利益交接点主要集中在需求方面。（更多干系人方面的内容，参见第2章）这些干系人包括客户、用户、业务分析人员和开发人员等。如果处理得当，这种交接既可以让客户满意，又能鼓舞开发人员。若处理不当，则会引发误解和摩擦，最终降低产品质量和业务价值。正是由于需求是软件开发和项目管理活动的基础，因此所有干系人都应该致力于需求实践活动，这是打造一流产品的前提。 但开发和管理需求确实很难！既没什么捷径，也没有任何灵丹妙药。另外，很多组织都在朝着一个目标努力，要找到一种能适应不同情景但又有共性的技术。本书后面将讲到很多这样的实践。这些实践假定你正在开发一种全新的系统。但是，它们中的多数也可用于改进、替换以及重构项目（详见第21章），还可以用于融合商业现成品的（COTS）打包解决方案项目（详见第22章）。即使项目团队遵循敏捷开发过程渐进式构建产品增量，团队也要理解每一个增量所涉及的需求（详见第20章）。 本章将帮助你： 理解软件需求领域所用的一些关键术语； 区分产品需求和项目需求； 区分需求开发和需求管理； 警惕可能出现的与需求相关的一些问题。 给自己的需求把把脉 要想对组织中现有的需求实践做一次快速体检，就对比下列问题，看看有多少条出现于你最近的项目中。如果其中有三四条以上与你的经历相符，那么本书就是为你量身定做的。 从来没有清晰制定过项目的业务目标、愿景和范围。 客户太忙，没有时间与分析师或开发人员共同处理需求。 团队无法与用户代表直接互动，不理解他们的具体需要。 客户认为所有的需求都很关键，因此没有对需求排定优先级。 开发人员在写代码时遇到了模棱两可或者遗漏的信息，所以只能靠猜。 开发人员与干系人沟通的重点集中于用户界面展示或者特性，并没有关注用户要使用软件完成的具体任务。 需求从来没得到过客户的认可。 客户认可了某个发布或者迭代的需求，但事后又不断更改。 不断接受客户的需求变更请求