继续根据上一篇的软件业务价值流图来学习总结，本篇我们关注价值流图的最开端也是最基础的环节：需求管理。
需求 - - 开发模式 - - 变更 - - - 版本控制 - - - 环境管理 - - - 持续部署 - - - 监控反馈
| |
- - - 持续集成 - - - 自动化测试 - - -
需求管理属于产品管理领域，是整个持续交付过程的起始点。它的目标是将IT产品的特性和需求以合理的层级结构来划分，并依托特定系统来承载和维护，确保每一条需求都能够清晰的指导后续开发过程形成最终的价值，并且整个需求的生命周期有记录可追溯。清晰良好的需求管理视图是频繁迭代的基础和保障，能够明确每个迭代的计划范围和验收标准。
首先声明需求管理中的常用概念：“功能”、“特性” 和 “需求” 。
“功能” function：是从公众角度对IT产品进行的通俗描述，可常见于产品宣传、资料手册中，不能直接指导研发过程（非技术语言）；
“特性” feature：是从专业角度对IT产品进行的技术阐述，通常与产品软件的模块架构相呼应，可形成设计文档指导研发过程；一般可划分为“特性域”和“特性”两个层级；特性的结构设计需要对产品的软件架构有深入的认识和掌握；
“需求” requirement：是从管理角度对功能/特性的变化进行承载和细化跟踪；可以视为变更流程的一种，可对应到实际软件代码和测试用例的变更；一般可划分为“原始需求”、“系统需求”两类，分别对应“功能”、“特性”的变更（分配需求或story则属于特性变更的细化子项）；
在将IT产品的功能转化为合理层级结构的特性和需求后，就可以将这些特性和需求信息录入相关系统（Jira或专业的需求管理系统），并与研发的版本控制库对接，使每一条需求都能和对应的代码/用例关联起来。
然后我们描述一下需求管理的基本流程：
从市场或内部收集对IT产品功能的意见，形成原始需求 ==》产品架构师对原始需求进行评审和解读，按照特性的维度分解为相应的系统需求并挂靠至对应特性下面 ==》按照敏捷的迭代周期对未完成的系统需求进行计划制定，并分解为相应的分配需求或story ==》分配需求或story指定相应的开发owner进行开发测试，并完成代码和用例的更新 ==》sprint结束时完成本轮版本的验证，关闭相关分配需求或story，然后关闭对应系统需求并更新对应特性信息。
有了基本的需求管理框架后，就应考虑具体的开发模式，此处在敏捷理论中已经讨论得比较详细，所以仅摘抄几点关键部分：
sprint需求规划 ==》特性驱动测试 ==》测试驱动开发 ==》结对编程 ==》开发测试融合 ==》 站会+看板 ==》 频繁迭代
最后提一下变更管理。软件研发的过程其实就是变更的过程，变更管理可分为 需求变更管理和缺陷变更管理两类，分别对应特性和bug的管理。 需求变更管理一般与承载特性和需求信息的系统一体，注重变更请求的审核和影响领域的跟踪，保障变更全生命周期可追溯。与变更管理紧密相关的就是版本控制技术，下一篇我们继续总结版本控制和环境管理部分。