需求调研及管理培训.ppt

* * * 需求管理流程 研发人员分析需求后编写研发计划后将计划上传至相应需求单号下，并发邮件周知，如果后续计划有所修改也要将新计划上传至相应需求单号下并周知，并做好版本控制，要求文档命名格式如下： 《xx省_xxx项目研发计划v1.0》（后续修改计划文档名称中版本号递增，如v1.1） 研发人员开始概要设计文档编写，测试人员开始测试用例编写 研发人员组织概要设计评审，产品管理人员和测试人员参与 测试人员组织测试用例评审，研发人员和产品管理人员参与 研发人员开始详细设计文档编写，并组织详细设计评审 研发人员开始代码开发 研发人员完成开发，提交测试部测试 对于项目定制化开发的需求，研发人员完成需求开发后直接将补丁包上传至相应需求单号下，并添加任务注释，由项目方人员自行处理后续工作；对于产品化开发需求，研发人员完成需求开发后交由测试部测试后走公司公共产品部产品发布流程 为什么要写好需求描述 为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，?使之成为整个开发工作的基础； 一旦写错，研发人员有可能要做大量重复工作； 糟糕的需求描述不能指导产品管理人员写出标准的需求规格说明书； 明确的需求分析说明书可以指导测试人员编写测试计划，指导研发人员编写研发计划 需求描述的六大特征 Your site here 3、必要性 5、明确性 1、正确性 4、优先权 6、可证实性 2、可行性 高质量需求描述的其他特征 Your site here 3、可修改性 1、完整性 4、可追踪性 2、一致性 高质量的需求不仅是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性，期望性能的非功能性需求。 Your site here 完整性 不应该遗漏要求和必需的信息。可以使用以下方法来实现： 将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。 通过应用用例图来抽象化需求，能够从不同角度查看需求的图形分析模型，也可以检查出不完整性。 Your site here 一致性 避免与软件中其他的需求或高级别的系统需求发生冲突。 注意：修改需求时一定要谨慎，如果只审定修改的部分，没有审定与修改相关的部分，就可能导致不一致性。 Your site here 可修改性 当每个需求的要求修改了或维护其历史更改时，必须能够审定需求，也就是说每个需求必须相对于其他需求有其单独的标识和分开的说明，便于清晰的查阅。可以将相关的需求分组，建立目录表，索引，以及前后参考，也即将需求按性质进行分类。 Your site here 可追踪性 应能将一个软件与其原始材料相对应，如高级系统需求、用例、用户的提议等 Your site here 编写需求的方法总结 句子和段落要短； 采用主动语气； 使用正确的语法，拼写，标点； 使用术语，要保持一致性，并在术语表或数据字典中定义它们； 避免包含多个需求的长的叙述段落，努力正确地把握细化程度； 尽量避免在一个需求中使用“和”or“或”，密切关注是否多个需求合并成了单个需求。 如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了；如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。 案例分析：主帐号信息同步管理功能 【功能描述】 {为在4A系统实现对主帐号的统一管理，4A系统需从UUM侧同步主帐号的相关信息。数据同步接口要求满足广东移动统一用户管理系统设计(UUM)规范，该模块采取《UUM数据同步接口使用指南》中“同步方式一”设计}，可满足系统闲时定时增量同步和相关人员手动增量同步操作。 其中，定时增量同步在每10分钟自动执行；手动增量同步操作只有主帐号管理人员和4A系统管理人员能够执行。如果同步失败，应该是可以主动以电子邮件方式提示主帐号管理人员，并有系统日志记录。 属于需求背景，最好单独说明，不要放在功能描述中。 这是同一个需求的两种实现方式，测试人员编写测试用例需要覆盖到，建议使用“分层目录”方式具体说明 什么是增量同步？ 描述模糊，闲时是对定时同步而言还是对手动同步而言？怎样才算闲时？如何衡量？体现了需求的不可证实 要避免像“应该”的这类不确切的词。这个功能是能实现还是不能实现？体现了需求的不准确性 此处为何只提示主帐号管理员？体现了需求的不准确性 Your site here 【输入】 同步执行时4A系统将根据组织机构和主帐号现行同步状态决定是否调用UUM提供的 webservice接口获取异动数据； 到底现行状态如何才可以决定是否调用同步操作呢？体现了需求的不完整性 功能描述中提到实现主帐号信息同步操作的两种方式是“定时同步”和“手动同步”，而这