(CEN)第三章需求获取讲稿.ppt

权利之四：听取对需求工作成果的解释 需求分析员也许会使用不同的示意图来配合SRS文本对需求进行描述。 权利之五：得到需求分析员和开发人员的尊重 合作能够帮助双方认清对方面临的问题。 参与需求开发过程时，客户有权要求需求分析员和软件人员尊重他们的想法，并且珍惜他们为项目成功所付出的时间。 权利之六：听取开发人员对于需求及如何实现需求的想法和 备用方案 需求分析员应该了解客户现有的系统为何不能很好地满足他们的业务流程需要，从而保证新的系统能够更高效满足新需要。 如果被提出的新特性、用户需求或功能性需求都在范围之外 ， 也许你的工作就完成了。 如果被提出的新需求优先级都很低，也许你的工作已经完成了。 如果用户提出的新功能都是可以“在产品生命周期的某个时刻”加入，而不“属于我们当前正在讨论的特定产品”，你的工作也许已经完成了 在自动售货管理系统例子中，矛盾： 开发人员希望使用较先进的开发技术和工具为用户建立高科技系统，这可能导致成本增加。 零售商需要一个操作简单和价格便宜的系统。 而开发商则需要具有便利和良好性能以及利润较多、成本较低的系统。 四、前景与范围文档 前景与范围文档用于将业务需求收集整理到一个文档中，为后续的开发工作打好基础。进行商业软件开发的组织则常常创建市场需求文档(Market Requirements Documentation，简称MRD)。 下页中的图给出了前景和范围文档的一个模板。 业务需求 (1) 背景 (2) 业务机遇 (3) 业务目标与成功标准 (4) 客户与市场需求 (5) 业务风险 解决方案的前景 (1)前景声明 用一个简洁的前景声明概括新产品的长期目标和意图。 (2)主要特性 为新产品的每一项主要特性或用户功能进行固定的、惟一的命名或编号，突出其超越原有产品或竞争产品的特性。 (3)假设与依赖 记录构思项目和编写前景和范围文档过程中涉众所提出的每一项假设。 范围与限制 项目的范围定义了所提出的解决方案的概念和范围。 (1)第一个版本的范围 概述计划在产品的第一个版本中实现的主要特性。 (2)各后续版本的范围 要采用阶段性的开发方式，需要决定推迟实现哪些特性，并为后续的版本做出时间安排。 (3)限制与排除 定义项目包含的需求与不包含的需求之间的界线。 业务背景 这一部分概述一些项目的业务问题，包括简要描述主要的涉众类别，以及说明项目的管理优先级。 (1)涉众简介 对每类涉众的说明都应提供如下信息： 从产品得到的主要价值或利益，产品如何才能产生较高的客户满意度。 可能对产品采取的态度。 感兴趣的主要特性和功能。 必须遵循的已知约束。 (2)项目优先级 要想更有效地进行决策，涉众必须就项目的优先级达成一致。 (3)操作环境 描述系统将用于什么环境，定义关键的可用性、可靠性、性能和完整性需求。 五、确定项目范围的好处是： 1）可以判断用户所提出的需求信息是否对项目合适。如果不合适，则给予拒绝。因此，当用户提出新的需求和改变需求时，作为开发人员首先必须认真地考虑这是否包含在项目范围之内。 2）有些用户需求信息可能是建议，这些建议是项目之外的，但可能有价值。因此可适当改变项目范围来适应这样的需求。但在改变范围之前，需要考虑进度、时间和资源等，否则容易影响需求工程中其他工作。 3.4 寻找、聆听与理解用户需求 3.4.1 寻找用户需求 要获得客户的需求，应采取以下步骤： 确定用户需求的来源。 确定产品的不同用户类型。 挑选出每一类用户和其他涉众的代表并与他们一起工作。 商定谁是项目需求的决策者。 （1）几种典型的软件需求来源： 与潜在用户进行交谈和讨论 要想知道某个新软件的潜在用户的需求，最直接的方式莫过于向用户了解。 描述现有产品或竞争产品的文档 这类文档可能也会描述产品必须遵循的企业或行业标准，以及法律和法规等。 系统需求规格说明 同时包含硬件和软件的产品具有一个高级的系统需求规格说明，用于描述整个产品。 现有系统的问题报告和改进要求 客户服务和技术支持人员也是需求的重要来源。 市场调查和用户问卷调查 这类调查能够从广大的潜在用户那里收集到大量的数据。 观察用户如何工作 让需求分析员观察现有系统的用户或将要推出的系统的潜在用户如何进行工作。 用户工作的情景分析 在确定用户需要借助系统完成哪些工作之后，需求分析员就能推导出用户完成这些工作必需的功能性需求。 事件和响应 列出系统必须响应的外部事件和正确的响应。 （2）用户分类 可以根据前面这些差异将用户分为若干不同的用户类(user class)。 同一用户可以属于多个用户类。 下图：涉众、客户和用户的层次结构 注意：不要忽视间接或次要用户类。 1）提出目标需求的用户。 能支付