一、需求背景1.1、需求来自何处1.2、需求实现过程需求收集、需求评估、需求引入、需求开发、需求清晰化、需求变更、需求实现、需求验证
1.3、需求分类软件需求分类(IEEE ) :
功能要求：与系统主要工作相关的要求。 也就是说，用户希望系统执行的活动，而不考虑物理约束。 这些活动有助于用户完成任务。 功能要求主要表现为系统与环境之间行为的交互。
性能要求：速度、容量、吞吐量、负载、实时性
速度：系统响应时间。 PR1 :所有用户查询必须在10秒内完成。
容量：系统可以存储的数据量。 PR2 :系统应该至少能保存10万条销售记录。
吞吐量—系统在连续时间内完成的事务数。 PR3 )解释器应该每分钟至少分析5000个无误的句子
负荷：系统上可搭载的同时工作量。 PR4 :系统应该允许200个用户同时进行正常工作。
实时性：严格的实时要求。 PR5 :监测患者异常后，监护仪必须在0.5秒内报警
质量属性：可靠性、可用性、可维护性、可移植性、安全性、易用性
“可靠性”(Reliability )系统或部件在规格的时间间隔内和规定条件下执行所要求能力的能力。
“可用性”(Availability )是软件系统在开始运行时可操作和可访问的程度，或者是能够实现指定系统功能的概率
易用性(Usability ) :用户为使用软件所付出的努力，以及与使用评估相关的特性。
QA6 )使用系统一个月的收银台负责人进行销售处理的效率达到10商品/分钟
对外接口：解开系统与其他系统之间的硬件和软件接口。
约束：系统开发运行环境、问题标准(法律法规、行业规定、企业规则等)、商业规则。
其他：安装要求、数据要求等。
1.4、参考定义https://baike.baidu.com/item/软件需求/256136？ fr=aladdin
https://baike.baidu.com/item/需求工程/1025898？ fr=aladdin
3359 www.cn blogs.com/from chaos/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需求（从软件的生命周期考量）
测试需求
生产制造需求
客户维护性需求
其他非软件
对外接口：解系统和其他系统之间的软硬件接口
考虑设计限制
在SE设计好软件架构后，就可以根据DR设计需求分解到对应资源的设计规格（将需求分配给子系统）
所以在写设计需求时要画出对应软件架构图
如何写出优秀的需求，这没有一个固定的讨论。
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
https://www.jianshu.com/p/4e2766f35bf6
https://zhuanlan.zhihu.com/p/81093014