第二章节需求工程过程资料.pptVIP

风险躲在需求的迷雾之后 　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”?　　分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”?　　经理觉得奇怪：“我不是刚告诉你我的需求了吗？”?　　分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”?　　经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”?　　分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”?　　经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。” 优秀的团队遇到糟糕 的需求 需求问题导致的主要后果是返工——重复做您认为早已做好的事情。 返工的成本占了总开发成本的30%～50，而对于返工的情况，70%～80%是因需求错误引起的。 从图可以看出，在项目末期才发现缺陷，对其进行改正的成本要比在缺陷刚产生不久时修改的成本高得多。 镀金问题 开发人员为产品添加了一项需求说明中没有提到的功能，他认为“用户肯定会喜欢的”。这就是所谓的“镀金问题(gold plating)”。 开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定。 要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。 过于抽象的需求 营销人员或经理经常喜欢只给出一个粗略的说明，他们希望开发人员在开发过程中充实它。 这种方式对研究性项目或需求特别灵活的项目或许管用，但是需要紧密合作的团队，而且仅限于开发小型系统。 大多数情况下，这种做法的结果是使开发人员受挫，让客户失望。 忽略了某类用户 用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。 因此，多数产品都拥有不同的用户群。如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。确定所有用户群后，还要保证获得各类用户的需求 。 第二部分 需求工程过程 需求工程: 对问题域及需求做调查研究和描述,设计将满足那些需求的解系统的特性并用文档说明. 需求获取 需求分析 规格说明 人机接口 需求验证 需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复。 需求开发过程 需求开发是一个迭代的过程 需求工程的推荐方法 列出了近50种方法，分别属于7个类型，它们可以帮助大部分项目开发团队更好地完成他们的需求工作。 知 识 技 能 开发者也应该了解产品应用领域中的基本概念和术语。 培训需求分析员 所有将要成为分析员的团队成员都应该接受需求工程方面的基本培训。 熟练的需求分析员应具备以下特点： 耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工程技术。 对用户代表和管理者进行软件需求培训 参与软件开发的用户应该接受一到两天的需求工程方面的培训。 对开发人员进行应用领域的相关培训 为了帮助开发人员对应用领域有一个基本的理解，可以安排一个研讨课程，内容是客户的业务活动、术语和产品的目标。 创建项目术语表 定义应用领域专业名称的术语表可以减少误解。 需求获取 需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。 需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。 需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。 需求获取 第1章讨论了需求的三个层次：业务，用户和功能。在项目中它们在不同的时间来自不同的来源，也有着不同的目标和对象，并需以不同的方