软件需求分析第二章讲义.pptVIP

项目启动时要考虑的问题 Vision，愿景； Stakeholders，涉众； 投入 风险 可行性 名称 愿景（公司） 愿景（产品、项目） 如果仅允许一份文档、模型或工件来支撑项目，我会选择愿景文档——Philippe Kruchten 愿景文档回答的是这样的问题：在客户看来，为什么要开发这个系统？ 确定产品愿景与项目范围 业务（目标）需求位于需求链中的最顶层，这种需求定义了软件系统的愿景与范围。 用户需求和软件功能需求都必须符合业务需求设定的愿景和目标。 如果项目没有一个明确定义的方向，或者不能让每个人充分理解这个方向，就必然会走向失败。 产品愿景和项目范围 产品愿景( product vision)将所有涉众统一到一个方向上。愿景描述了产品用来干什么，它最终会是什么样子。 项目范围(project scope)确定当前的项目要解决产品长远规划中的哪一部分，范围同时定义了项目的限制。 愿景与范围文档 愿景与范围文档用于将业务需求收集整理到一个文档中，为后续的开发工作打好基础。进行商业软件开发的组织则常常创建市场需求文档(Market Requirements Documentation，简称MRD)。 业务需求 (1)背景 (2)业务机遇 (3)业务目标与成功标准 (4)客户与市场需求 (5)业务风险 愿景与范围文档 解决方案的愿景 (1)愿景声明 用一个简洁的愿景声明概括新产品的长期目标和意图。 (2)主要特性 为新产品的每一项主要特性或用户功能进行固定的、惟一的命名或编号，突出其超越原有产品或竞争产品的特性。 (3)假设与依赖 记录构思项目和编写前景和范围文档过程中涉众所提出的每一项假设。 愿景与范围文档 范围与限制 项目的范围定义了所提出的解决方案的概念和范围。 (1)第一个版本的范围 概述计划在产品的第一个版本中实现的主要特性。 (2)各后续版本的范围 要采用阶段性的开发方式，需要决定推迟实现哪些特性，并为后续的版本做出时间安排。 (3)限制与排除 定义项目包含的需求与不包含的需求之间的界线。 愿景与范围文档 业务背景 这一部分概述一些项目的业务问题，包括简要描述主要的涉众类别，以及说明项目的管理优先级。 (1)涉众简介 对每类涉众的说明都应提供如下信息： 从产品得到的主要价值或利益，产品如何才能产生较高的客户满意度。 可能对产品采取的态度。 感兴趣的主要特性和功能。 必须遵循的已知约束。 (2)项目优先级 要想更有效地进行决策，涉众必须就项目的优先级达成一致。 (3)操作环境 描述系统将用于什么环境，定义关键的可用性、可靠性、性能和完整性需求。 涉众 涉众与利益 涉众利益与需求 关键涉众的需求 对一个软件项目最关注的人员 用户(Users) 考虑的重点是产品的易使用性,功能 客户(Customers) 考虑的重点是产品的功能以及由此能产生的效益 开发人员(Engineers) 考虑的重点是产品的可开发性,技术细节 用户的特征 从产品可操作性出发思考问题 不一定是受到良好训练的工程师 了解产品操作环境 对产品技术、商务背景、限制不感兴趣 客户的特征 是用户的代理人。客户可能是同一组织内的系统工程组、市场组、其他职能部门。多数情况下可能是一个外部客户，如中国移动(CMCC),中国联通(Unicom),Services Provider(ISP) 对产品的性能，功能有本能的感觉 集中于产品的商务方面 关心产品合同与合法性等细节 客户不一定是受到良好训练的工程师 对产品的可操作性的知识并不全面 开发人员的特征 是受到良好训练的工程师 日常交流更善于使用专业术语 对产品的可操作性的知识并不全面 可能过分服从，也可能过于坚持己见 钟爱于技术完美性，疏忽商务上的作用 相互矛盾的业务需求 开发者希望为顾客提供一个激动人心、代表高科技新方向的完美产品。 客户需要的却只是一个简单的、可直接投入使用的系统。 用户则注重方便性和功能。 不同的目标、约束和成本因素构成了这三方的制衡关系，导致了不一致的业务需求。 涉众对项目的影响 协商、协调与权衡 如何权衡 排序 通过协商获得合理的期望 客户、用户对系统的期望 如何同用户一起构思系统的功能？ 关注涉众利益的一个显见优点 涉众利益、领域知识与创新 软件客户（用户）的权利法案 权利之一：要求需求分析员使用客户的语言 需求的讨论必须以客户的业务需求和业务工作为中心，使用客户的业务用语。 客户可以通过词汇表向需求分析员提供业务术语。 权利之二：要求需求分析员理解客户的业务和目标 通过与客户交流获得需求，需求分析员能够更充分地理解客户的业务以及如何让产品适合业务需求。 权利之三：要求需求