《腾讯从概念到产品-需求分析过程》课件.ppt

* Good News：天下文章一大抄 在一个产品系统中，性能需求是可以Copy的 第一份性能需求是重点，大家一起作 之后的需求文档往往只需改变： 性能指标 可扩展性 易用性 可延展性 安全性 兼容性 可维护性 可移植性 可编程性 可靠性 可测试性 这里简简单单几句话要求， 让开发同事、设计师作半年…… * 需求规格说明书 * 没有高质量的需求 软件就象一个巧克力的盒子 你不会知道你将要得到什么 * 高质量需求叙述的特性 正确 可行性 必要性 优先权 明确 可证实 * 高质量需求叙述的特性 1/6 正确： 每个需求必须精确描述要交付的功能。 正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。 只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的猜测。 * 高质量需求叙述的特性 2/6 可行性： 在已知的能力、有限的系统及其环境中每个需求必须是可实现的。 为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，这个开发人员应能检查 在技术上什么能做什么不能做 哪些需要需要额外的付出或者和其他的权衡。 在抽象阶段应该有市场人员参与。 * 高质量需求叙述的特性 3/6 必要性： 每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。 每个需求源于你认可或者具有授权的原始资料 跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户（特别是Boss）的意见。 如果你不能标识出处，可能需求只是个镀金的例子，没有真正的必须。 * 高质量需求叙述的特性 4/6 优先权： 为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。 客户或其代理都应有强烈的责任建立优先权。 如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时， 项目经理将不能起到作用。 优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。 Must Have, Nice To Have, Can Delay * 高质量需求叙述的特性 5/6 明确： 需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。 自然语言极易导致含糊。要避免使用一些对于SRS作者很清楚但对于读者不清楚的主观词汇，如： 用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。 每写一个需要都应简洁，简单，直观的采用用户熟知的语言，不要采用计算机术语。 检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部分预期的特性。 * 高质量需求叙述的特性 6/6 可证实： 看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。 如果需求是不可验证的，决定需求是不是正确的实现就成了判断的事。 需求之间不一致，不可行，不明确也能导致不可证实。 任何需求如果说产品将要支持什么也是不可证实的。 * 高质量需求说明书的特征 完整 一致性 可修改性 可追踪 * 高质量需求说明书的特征 1/4 完整： 不应该遗漏要求和必需的信息。 完整性也是一个需求应具备的。 发现缺少的信息很难，因为根本不存在。 在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。 在需求抽象上，应用Use Case方法会发挥很好的作用。 能够从不同角度察看需求的图形分析模型也可以检查出不完整性。 使用TBD（to be determined）标准标志已知的缺失 当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。 如“Vista表现” * 高质量需求说明书的特征 2/4 一致性： 一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。 需求中的不一致必须在开发开始前得到解决。 只有经过调研才能确定哪些是正确的。 修改需求时一定要谨慎 如果只审定修改的部分，没有审定于修改相关的部分，就可能导致不一致性。 * 高质量需求说明书的特征 3/4 可修改性： 当每个需求的要求修改了或维护其历史更改时，你必须能够审定SRS。 每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。 通过良好的组织可以使需求易于修改，如： 将相关的需求分组，建立目录表，索引，以及前后参考 Feature List.xls 是很好的工具 * 高质量需求说明书的特征 4/4 可追踪： 应能将一个软件与其原始材料相对应 如高级系统需求，用例，用户的提议等。 能够将软件