一、需求的背景
1.1、需求从何而来
1.2、需求实现流程
需求收集、需求评估、需求导入、需求开发、需求澄清、需求变更、需求实现、需求验证
1.3、需求分类
软件需求的分类（IEEE）：
功能需求：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
性能需求：速度、容量、吞吐率、负载、实时性
速度：系统的响应时间。PR1：所有的用户查询都必须在10秒内完成。
容量：系统所能存储的数据量。PR2：系统应该能够存储至少10万条销售记录。
吞吐量：系统在连续的时间内完成的事务数量。PR3：解释器每分钟应该至少解析5000条没有错误的语句
负载：系统可以承载的并发工作量。PR4：系统应该允许200个用户同时进行正常的⼯工作。
实时性：严格的实时要求。PR5：监测到病人异常后，监控器必须在0.5秒内发出警报
质量属性：可靠性、可用性、可维护性、可移植性、安全性、易用性
可靠性（Reliability）：在规格时间间隔内和规定条件下，系统或部件执行所要求能力的能力。
可用性（Availability）：软件系统在投入使用时可操作和可访问的程度或能实现其指定系统功能的概率
易用性（Usability）：与用户使用软件所花费的努力及其对使用的评价相关的特性。
QA6：使用系统1个月的收银员进行销售处理的效率要达到10件商品/分钟
对外接口：解系统和其他系统之间的软硬件接口。
约束：系统开发运行环境、问题的相关标准（法律法规、行业规定、企业规章等）、商业规则。
其他：安装需求、数据需求等。
1.4、参考定义
https://baike.baidu.com/item/%E8%BD%AF%E4%BB%B6%E9%9C%80%E6%B1%82/256136?fr=aladdin
https://baike.baidu.com/item/%E9%9C%80%E6%B1%82%E5%B7%A5%E7%A8%8B/1025898?fr=aladdin
https://www.cnblogs.com/fromchaos/archive/2011/05/04/2036760.html
二、需求收集导入
需求即业务痛点，针对目前的所处的阶段，业务所需要提升的功能模块，亦或者是业务所需要新增加的业务场景等。
1、业务提出痛点，战略执行业务不满足，需要增加的点；2、目前业务流程执行需要更改的点；3、目前业务操作中客户体验优化的点；4、业务竞标之后需要增删改的点；5、系统性能需求等。尽可能穷尽所有涉及的需求。
2.1、需求收集来源
市场
分析竞品
招标限制
客户调研
内部需求（从软件的生命周期考量）
提高内部代码可维护性
提高可测试性
提高生产效率
提高外部可维护性
如何收集
日常收集反馈
月度会议反馈记录
年度规划
2.2、需求导入
2.2.1、需求优先级
兴奋型：用户意想不到不到的需求，有了此类需求，用户的满意度会大大的提升，没有此类需求，用户满意度不会降低。
期望型：有此类需求用户的满意度会提升，如果没有此类需求用户的满意度会下降
基本型：有此类需求用户满意度不会提升，如果没有此类需求用户满意度会大幅度下降
无差异型：无论提供或者不提供此类需求，用户的满意度不会有差异
反向型：有此类需求用户的满意度反而会大大下降
可根据需求类型进行分类，找到优先级：基本型>期望型>兴奋型>无差异型>反向型
2.2.2、需求分析
收集到很多条需求之后怎么样进行分析找到最有价值的需求，且能为客户提供更完备的产品，需要从产研角度出发，按照优先级进行分析讨论。1、项目需求提出需求的技术可行性分析；2、需求技术实施方案分析确认；3、需求评审是否合理
2.2.3、需求排期
根据业务需求及技术可行性分析进行排序，促使业务参与敏捷活动，方便运用看板进行迭代，为后期版本规划做好铺垫。
排期的基础：1、发布日历；2、需求优先级；3、需求工作量评估。明确此三项，可建立项目需求池，每次迭代完成之后开需求排期会确认下一迭代需要开发的需求，确认好之后可转化为用户故事，进行管理，推进。
三、需求开发澄清
3.1、需求开发OR-DR-DS
3.1.1、OR产品需求
描述客户的应有场景
标准：谁在什么时候做什么事，做的频率，5W2H
解决客户什么问题，给客户带来什么价值
需求详细描述
3.1.2、DR设计需求
功能需求
用技术语言描述软件如何解决客户问题的（为系统描述与外部世界之间的联系）
标准：从客户的交互入手，最后软件呈现什么东西解决了客户问题
工具：（为需求建模，一图胜千言）利用Visio画出相关交互流程，保证考虑到所有细节场景
方案：参考现有产品和相关专家讨论
性能需求
速度、容量、吞吐率、负载、实时性
质量属性
考虑DFX需求（从软件的生命周期考量）
测试需求
生产制造需求
客户维护性需求
其他非软件
对外接口：解系统和其他系统之间的软硬件接口
考虑设计限制
3.1.3、DS设计规格
在SE设计好软件架构后，就可以根据DR设计需求分解到对应资源的设计规格（将需求分配给子系统）
所以在写设计需求时要画出对应软件架构图
3.2、需求编写指南
如何写出优秀的需求，这没有一个固定的讨论。
1）需求相关者的反馈是最好的老师
2）系统或者用户的角度
3）写作风格：清晰简洁、多用“应该”、避免用大段的叙述来描述多个需求、
4）细化程度：恰当的细化、一致的颗粒度
5）表述技巧：一看到长篇大论、密密麻麻的文字或看到相同的长串需求列表
6）避免歧义：模棱两可的词、边界值、
3.3、需求原型
通过原型来减少风险，软件原型是以试探性的方式逐步逼近解决方案
3.4、需求确认（澄清）
如果真的很想努力追求软件质量的最大化，团队应该对大多数需求进行审查。投入1小时的审查，可以避免10小时的劳动。
3.4.1、整体流程
准备工作（线上评审）-》审查会（用自己的话描述需求）-》返工（清除不清晰的需求）-》跟进（跟进悬而不决的问题和需求）-》准出条件
关于需求评审：
1、需求评审尽早开始，不必等到完全认为写完了就开始评审。
2、分配足够的时间
3、提供上下文
4、设置评审范围
5、限制重复审
6、对评审排优先级
需求评审面临的问题：
1、需求文档过长
2、审查团规模大
3、
3.4.2、缺陷检查清单
主要围绕：完整性、正确性、质量属性、组织及可追溯性、其他问题
四、需求变更验证
4.1、需求变更
开发过程中难免遇到业务需要变更需求，在敏捷项目中是拥抱变化的，故欢迎业务进行变更以便在市场中获得更大的收益，但是变更不是一味的只求边，这样开发根本无法执行开发任务，需进行评审走流程。
1、要建立需求变更的流程及审批：确认变更什么、变更影响、是否接受变更；2、开发过程中如要新增其他需求，需适当移走本次迭代的其他非紧急需求；3、变更之后的需求拉入本次迭代管理；4、如果增加需求没有在项目基线中，可协商进行二期开发，更好的控制预算；5、属于优化变更的需求也可以惊醒需求分析排期下一迭代。
4.2、需求验证
开发完成之后的需求经过测试验证，给出测试报告之后方可预上线，预上线中业务可以进行UAT验证，是否验收通过，验证通过即可上生产验证。
综上：业务需求提出到最后上线是一个生命周期，中会遇到很多的问题，需平衡各方资源，及时沟通，集业务、开发、测试共同努力达成共识输出满意度较高的产品。
五、好的需求标准
5.1、优秀需求所需要的特性
- 完备性
- 正确性
- 可行性
- 必要性
1、成功因素（来源于书籍《项目管理-软件需求最佳实践》）：用户参与15.9%，执行层参与13.9%，清晰的需求描述13%，合适的规划9.6%，现实的客户期望8.2%，较小的里程碑7.7%，有才能的员工7.2%，其他
5.2、好的需求带来的好处
1）需求中缺陷和交付产品中的缺陷更少
2）开发的返工减少了
3）开发和交付更快
4）不必要和无用的特性更少
5）减少成本追求
6）信息错误传递的现象减少了
7）范围蔓延减少了
8）项目混乱现象减少了
9）客户和团队成员满意度更高了
10）产品按照人们
5.3、坏的需求管理
1、需求返工
2、用户参与度不够
3、规划不当，项目需求规划的成本过于乐观。频繁的需求变更、需求遗漏、与用户沟通不足、低质量的需求规范和不完善的需求分析
4、用户需求蔓延
5、需求模棱两可，解决办法是不同视角的人来检查需求
6、镀金，开发人员加入自己的理解
7、忽视干系人
失败因素思考（来源于书籍《项目管理-软件需求最佳实践》）：沟通失真（参与达成一致），需求放大（多问为什么，寻找客户需求背后动机），项目经理的需求控制（以业务为线索来组织需求，基于“Why”的层面对需求建立高层次的认识），编码人员的断章取义（理解业务场景）
六、参考
https://blog.csdn.net/Follower_JC/article/details/84258287
https://www.jianshu.com/p/784274332104
2229
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
