需求体系化还能做什么？

需求体系化还能做什么？

今天做特性树的建设，根据最新的几个需求把他们对应的特性创建起来，重点关注场景的部分。做得过程中也越来越有感觉，利用现有的东西，把场景进行合适粒度的拆分非常重要。和香约好了明天一起逐步去重构部分场景，结合她的丰富的业务知识，梳理特性树的同时，也是学习业务知识的过程。

今天想明白一个问题，需求体系化不仅仅是特性树的建设，知识体系的建设，还需要包含需求的端到端完整的流程的可视化和可追溯的管理，还包括更高质量端到交付这整个环节中涉及到的用例管理，用例设计等一系列的东西。而需要建设这一整个体系，自然少不了工具链的整合和支撑，用工具把所有与需求和特性，用例相关的信息全部进行整合。能够达到:

• 有新的需求过来后，从流程上能做到很顺畅的需求传递和扭转，以及需求的完整信息各个环节可追溯。
• 从需求分析上，BA能保证，新需求对已有特性的影响，尤其是场景的新增和修改能快速，完善的评估出来。
• 从质量保证上，QA能做到简单快速准确的把波及到的用例挑出来进行验收测试。
• 从开发实现上，DEV能基于现有架构和实现得到对当前系统影响最小的最佳解决方案。
• 从外场和外部支持上，防火墙人员能从需求体系中，快速准确的找到他们所需要的FAQ，我们甚至可以抽取一些典型的的外部支持FAQ供用户使用和查阅。

需求实例化之场景拆分&方案编写

俊哥这两周做需求穿刺，BA在做需求实例化的过程中，我们之前重点关注两个部分:场景和初步的实现方案。在充分了解特性的现有验收场景和用户需求的情况下，比较容易做需求实例化。但关于需求实现方案的部分，就需要有开发同学更多的介入，尤其是存量复杂系统，越是需要了解代码架构和现有实现的基础上去谈需求的具体实现方案，且不必要一开始涉及太多细节，从大方向上去把控，把更多的自由度留给开发同学就很好。
因此，在做需求研讨的过程中，BA、QA和DEV三种角色必不可少。

图片发自App