1、软件需求工程软件需求工程Software Requirements Engineering 第二章 客户的需求观 例子Contoso 制药公司的高级管理长官Gerhard,会见C o n t o s o公司的信息系统开发小组的新管理员C y n t h i a。“我们需要建立一套化学制品跟踪信息系统”，G e r h a r d说道。“该系统可以记录库房或某个实验室中已有的化学药品，这样，化学专家可以直接从楼下的某人那里拿到所需的药品，而不必再买一瓶新的。另外，卫生保健部门也得为联邦政府写些关于化学药品的使用报告。你们小组能在五个月内开发出该系统吗？”“我已经明白这个项目的重要性了，G e r
2、 h a r d”，C y n t h i a说，“但在我制定计划前，我们必须收集一些系统的需求。”G e r h a r d觉得很奇怪“你的意思是什么？我不是刚告诉你我的需求了吗？”“实际上，你只说明了整个项目的概念与目标，”C y n t h i a解释道，“这些高层次的业务需求并不能为我们提供足够的详细信息以确定究竟要开发什么样的软件，以及需要多长时间。我需要一些分析人员与一些知道系统使用要求的化学专家进行讨论，然后才能真正明白达到业务目标所需的各种功能和用户的要求。我们甚至并不需要开发一个新的软件系统，这样可节省许多钱。”G e r h a r d此前还从未遇到过与这位系统开发人员类似
3、的看法。“那些化学专家都非常忙”他坚持道，“他们没有时间与你们详细讨论各种细节，你不能让你的手下的人说明要做的系统吗？”C y n t h i a尽力解释从使用新系统的用户处收集需求的合理性。“如果我们只是凭空猜想用户要求，结果不会令人满意。我们只是软件开发人员，而并非化学专家。我们并不能真正明白化学专家们需要这个化学制品跟踪系统做些什么。我曾经尝试过，未真正明白这些问题就匆忙开始编码，结果没有人对产品满意。“行了，行了，我们没有那么多时间”G e r h a r d坚持道。“我来告诉你需求，请马上开始开发系统。随时将你们的进展情况告诉我。”问题分析：对不同层次需求（业务、用户、功能）的混淆所
4、致。G e r h a r d说明了一些业务需求，但他并不能描述用户需求，因为他并不是“化学制品跟踪系统”的实际使用者。只有实际用户才能描述他们要用此系统必须完成的任务。但他们又不能指出完成这些任务所有具体的功能需求。客户和开发人员的关系要求开发一个新信息系统的客户通常并不懂得从系统的实际用户处得到信息的重要性；市场人员在有了一个很不错的新产品想法后，也就自认为能充分代表产品用户的兴趣要求。直接从产品的实际用户处收集需求有着不可替代的必要性。导致项目失败的最主要的两个原因是缺乏用户参与和不完整的需求以及不完整的规格说明。1.客户的涵义通常意义下，客户是指直接或者间接从产品中获得利益的个人或者组
5、织。软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者或是获得产品所产生结果的人。客户的划分 上层需求业务需求，代表采购、支付或投资软件产品的这类客户，他们有义务说明业务需求。他们应阐明产品高层次概念和将发布产品的主要业务内容。下层需求用户需求，必须从使用产品的用户处收集，因此这些用户（通常称最终用户），构成了另一种软件客户。说明业务需求的客户有时候将代替用户说话，但通常他们根本无法准确说明用户需求。因为信息系统、合同或是客户应用程序开发，业务需求应来自风险承担者，而用户需求则应来自产品的真正使用者、操作者.不幸的是，这两种客户可能都觉得他们没有时间与(收集、分析与编
6、写需求说明)需求分析者讨论。有时客户还希望分析人员或开发人员无须讨论和编写文档就能说出用户的需求。除非遇到的需求极为简单，否则不能这样做。如果你的组织希望软件成功，那必须要花上数天时间来消除需求中模糊不清的地方和一些使程序人员感到困惑的方面。2 客户和开发人员的合作关系 客户是敌人！矛盾产生的客户是上帝！衣食父母客户是朋友！工作中、工作之余的伙伴，朋友。互相帮助建立正确建立正确的客户观的客户观优秀的软件产品是建立在优秀的需求的基础之上。而高质量的需求来源于客户和开发人员之间有效的交流和合作。1、软件客户需求权利书：列出了十条关于客户在项目需求工程实施中与分析人员，开发人员交流时的合法要求。2、
7、软件客户需求义务书：列出了十条关于客户在需求过程中应承担的义务。软件客户需求权利书1.要求分析人员使用符合客户语言习惯的表达。2.要求分析人员了解客户系统的业务及目标。3.要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。4.要求开发人员对需求过程中所产生的工作结果进行解释说明。5.要求开发人员在整个交流过程中保持和维护一种合作的职业态度。6.要求开发人员对产品的实现及需求都要提供建议，拿出主意。7.描述产品使其具有易用、好用的特性。8.可以调整需求，允许重用已有的软件组件。9.当需要对需求进行变更时，对成本、影响、得失（t r a d e-o ff）有个真实可信的评估。10.
8、获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。软件客户需求义务书1.给分析人员讲解业务及说明业务方面的术语等专业问题。2.抽出时间清楚地说明需求并不断完善。3.当说明系统需求时，力求准确详细。4.需要时要及时对需求做出决策。5.要尊重开发人员的成本估算和对需求的可行性分析。6.对单项需求、系统特性或使用实例划分优先级。7.评审需求文档和原型。8.一旦知道要对项目需求进行变更，要马上与开发人员联系。9.在要求需求变更时，应遵照开发组织确定的工作过程来处理。10.尊重需求工程中开发人员采用的流程（过程）。3 签约 重要性：为所开发产品的需求签定协议是客户与开发人员关系中的重要部分
9、。有的作为合同的一部分（附件）是开发人员设计变成测试的依据重大需求变更需增加开发费用是项目验收的最重要标准是双方解决分歧的起点，和最终结果形成的依据3 片面或错误认识 客户代表经常把“签约”看作是毫无意义的。“他们要我在一张纸的最后一行文字下面签上名字，于是我就签了，否则这些开发人员不开始编码。”这种态度将来会带来麻烦，譬如客户想更改需求或对产品有不满时。“不错，我是在需求上签署了名字，但我并没有时间去读完所有的内容。我是相信你们的，是你们非要让我签字的。”同样的问题也会发生在仅把签约看作是完成文档的管理人员身上。一旦有需求变更出现，他便指着软件需求规格说明说道：“但你已经在需求上签约了，所以
10、这些便是我们所要开发的。如果你想要别的什么，你应早些告诉我们。”签约的涵义：1、不可能在项目早期就预知所有的需求，而且毫无疑问需求将会出现变更。需求上签约是终止需求开发过程的正确方法=项目的一个里程碑2.签约是建立在一个需求协议的基线上，需求规格说明上的签约应该这样理解：“我同意这份文档表述了目前我们对项目软件需求的了解。进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们要重新协商成本、资源和项目工期任务等”。3.达成一定共识，减少矛盾,给初步的需求开发工作画上双方都明确的句号，会有助于形成一个持续良好的客户与开发人员的关系，为项目成功奠定基础。小结 1、软件需求的定义（有多种理解，以IEEE为主）。2、理解软件需求的层次以及各部分组成关系。3、优秀需求的特性和给工程实施带来的好处。4、需求工程中需求开发和需求管理关系和层次。5、理解客户含义以及客户的层次。6、了解客户和开发人员之间关系以及客户需求权利书和义务书的基本内容。
