来到做产品的第4年，工作中常常听到这样的声音：
“我这里有一个需求要紧急做一下”
“过来讨论一下这个需求”
“这是个伪需求，我们不必耗费这么多时间”
“它真的看上去那么简单吗”
“这个需求我没明白，我们再讨论一下”
“不是说好就这些需求了吗？怎么又变更了？还新增了这么多？”
关于需求的撕逼也从未停歇，软件行业、互联网行业，每个从业者每天都会许多需求打交到，为此我们开了数不尽的三方会议，数不尽的评审会议，加班出方案、设计、开发，可是需求呢？似乎并未越辩越明，产品也在一次又一次的多方妥协下推着向前......
需求出了问题会造成大量的加班返工，对代码进行迭代的代价更高，不仅是资源的浪费，还会挫伤团队士气，对需求有足够的认识团队才能开发出适合的产品。
需求是一种极其重要的投资。
我们大都知道，需求软件开发和软件管理活动的基础，打造一流产品的前提，从业人员都应该致力于需求实践活动。
那么需求究竟是什么？它包含了那些内容？我们又应该如何管理它？为什么这样做？相关的人员？
带着这问题开启本书的分享，这也是这本书的行文逻辑，围绕着需求的三问作者将会帮助我们改进所使用的需求流程，更好地收集和分析需求、编写和确认需求规范以及在整个软件开发周期中管理需求。
第一章 软件需求本质
需求的定义
我们平日工作能耳熟能详有关需求的字眼：用户需求、软件需求、业务需求、功能需求、系统需求、产品需求、项目需求、用户故事、特性或者约束条件，计算机编程技术已经兴起了很多年头，但从业者仍对“需求”定义争执不休，在作者看来没有必要延续这种争执，，在团队中最重要的是在定义上达成共识，这里他也列出了需求定义的参考：
Flan Sommerville and Pete Sawyer(1997)所提出的观点：需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。
需求的层次
过往的经验中，当我来到一个新的团队，在查阅需求文档和原型设计时，虽然有部分关于功能和交互的说明，但光看这些文档我往往不太了解用户要完成什么任务，这些内容我都是在测试人员协助我体验产品走流程时才清楚的。
业务需求：开发产品的组织或者获取产品的客户所需的高层次业务目标。（组织为什么要执行系统，希望获得的业务收益，关注点在于组织或提出系统要求的客户有哪些业务目标。比如航空公司希望减少柜台的工作人员）
用户需求：描述系统在特定条件下展现的行为。（描述了用户使用产品必须完成的任务，用户满意度最为关键的产品特性或特征，通过用例、用户故事、时间响应表来表示）
功能需求：特定用户群必须能够用系统所完成的目标或任务，或者是用户期望有的产品属性（产品在特定条件下所展示出来的行为，主要描述开发人员需要实现的功能以满足用户需求）
非功能需求：质量属性（易用性、安全性、性能）、设计和实现约束、外部接口、系统运行的环境（平台、可移植性、兼容性、约束）、监管和发行许可、地域的影响，保证这些内容都纳入需求分析中，功能之外的需求强调的并不是系统要做什么，其重点在于系统做得有多棒。
书中更有典型案例，帮助我们理解需求的层次。p11（pdf-p36）
平时工作中，我们多接触产品说明文档，其实就是软件需求规范说明（srs），大多描述的是产品的功能需求，用于开发、测试、质量保障、项目管理和相关项目功能。所以才会出现当一个新人进入团队，接手一个已经迭代几版的项目时会不清楚业务及用户需求的问题，在以后的工作中我们就可以分这些层次描述需求说明，确保团队中每个人都对产品需求有清晰的认识。
需求工程
需求工程涵盖了需求开发和需求管理，需求开发又包括：获取-分析-规范说明-验证。
需求获取涵盖需求发现的所有活动，例如访谈、研讨会、文档分析、原型等。（识别确定用户群、理解用户任务和目标及相关的业务目标、应用的环境、客户对产品的预期）
分析需求涉及深入并准确理解每个需求，然后将各个需求以不同的方式表达出来。 （分析收集到的信息——进行区分、细分——引出功能需求、质量属性 —— 将需求分配给系统架构所定义的软件组件？？——协商优先级）
需求规范说明以一种连贯并结构清晰的方式来表达和存储收集到的需求知识。（ 这一步就主要是编写文档和图表了，以便团队及相关利益关系人阅读、检查和使用。）
需求验证是指确认需求信息是正确的，能使开发人员制定出能满足业务目标的解决方案。（交付相关文档和设计前解决所有问题，开发验收测试和标准???能满足客户需要达成业务目标）
这些过程都不是以一个简单的线性顺序来实施的，需求开发过程中需要反复考量。
没有“完美的”需求
需求管理主要是为了预测和协调实际存在的变更，最小化对项目的破坏。（确定基线、通过评审的需求、计划发布——评估可能的变更——保持需求与项目同步——需求之间的关系和依赖——跟踪对应的设计、代码、测试）p16（pdf-41图表阐释了需求开发和管理的区别）
常见的需求风险p18-20
用户参与度不够
规划不当
用户需求蔓延
需求模棱两可
镀金
忽视干系人
我们可以通过书中列举的这些问题，检视自己所在的项目中是否存在同样的问题，并尝试用书中给出的方法予以解决，如持续的保持与用户沟通，我个人近期负责小程序的医学题库，联系到了以前的学医的同学，了解他们如何考职称的，网上刷题的意愿以及练题的习惯，对产品设计都有很多帮助。
第一章不仅仅包含以上提到的内容，看的过程中甚至觉得每个字都是重点，这里只列出了个人认为重要的小节。
第二章 从客户角度审视需求
客户和干系人
作者特别提出了干系人这个概念，是指积极参与项目的某个人、群体或组织，它们可能会受项目过程和结果的影响或影响项目的过程和结果。潜在的干系人涵盖很广，从直接用户到项目团队内人员，都可以是干系人。
为一个项目寻找潜在干系人的时候，应该广撒网以免忽略一些重要的群体。然后将候选干系人列表缩小为核心人选，这些人能够带给你所需的信息，确保你理解所有项目的需求和约束，使团队能够交付正确的解决方案。
书中的反例：如没有在项目前期确定会受系统影响的全部干系人，到了交付时期，可能就会存在功能上的偏差，导致项目延期。
所有干系人共享的同一个目标：构建一个既实现业务价值又可以使所有干系人受益的产品。客户和开发团队要基于这个目标进行通力合作。
客户既有权利也有相应的义务和责任 p26（pdf-51）
书中详细介绍了客户的权利和义务，我们在进行需求沟通前，可以多和客户讨论这些权利和义务（如：用客户的语言沟通、需求变更、收到满意的产品；向分析师或产品分享业务知识、尊重需求可行性的评估、尊重开发流程等），更好推进需求沟通过程。否则就会出现：
“我需要xxxx功能，什么时候能做好？”这样尴尬的情况。
或许我们没有和客户科普这些知识，直接开始了需求开发，但摩擦和冲突总会在需求沟通中出现不是吗？所以倒不如一开始让他们了解并接受这些权利和义务。
建立尊重需求的企业文化
有的团队并不尊重需求开发，认为这并不是非做不可，但是不重视需求开发的代价是显而易见的：出现意料之外的返工、延期或软件品质低劣。必须让每个人都了解公司和客户之间曾经因为需求问题而经历的痛苦。
和开发测试人员一起评审需求，让这些“眼尖”的人提前加入需求评审，开发人员经常能够提供其他人想不到的信息，比如如何用更简单的方式完成任务：什么功能实现起来非常耗时；哪些是不必要的设计约束；是否有遗漏的需求，比如异常处理；如何利用技术创造机遇，等等。
领导必须理解这一点：组织需要把高效业务分析和需求工程能力作为自己的战略性核心竞争力。
对需求达成一致
客户：承认需求描述了他们的需要
开发：承认理解需求并且认为它们是可实现的
测试：承认需求是可验证的
管理层：承认需求可以达成他们的业务目标
但我们要明白大多数时候，我们不可能在项目早期知道所有的需求，而且需求也会随着时间变化。
书中也提到在达不成共识时，先小心的推进项目，并持续与干系人保持沟通，要让他们知道如果要改变需求也有一个成熟的流程。
以上是第二章的主要内容，还是一样，内容很多，都是非常值得借鉴的经验，书中也不止都是概念和经验之谈，每章最后都给出了行动表、可以实践的实例，让我们着眼于行动。
第三章 需求工程优秀实践
为了应对每个项目的挑战，我们需要一个专业的技能工具箱，里面积累了各种开发需求、管理需求的技能。这样的临时方案很难取得好的结果。作者列出这些需求工程优秀实践丰富我们的工具箱。
这些实践不会普遍适用于所有的情况，要想应用好这些实践，需要利用判断力、常识和经验。即使是最佳实践，资深业务分析师也要根据适当的情况慎重选择、应用和采纳。
针对不同部分的需求，最好实施不同的实践。举个例子:针对客户端来说，使用用例（use case）或用户界面原型会有帮助，但对服务器端来说，接口分析则更有价值。
获取：
定义产品愿景和项目范围：愿景和范围文档里面包含了产品的业务需求，可以使干系人对产品有一致的理解，范围界定了哪些功能应该（或不应该）出现。
分析：
需求分析包括需求的精炼——使所有干系人都能够理解并检查出错误、遗漏以及其他缺陷；将概要需求分解成更细、粒度层次更合适的需求，建立原型，评估可行性以及协商优先级。其目标是产出符合质量和精确性要求的需求，项目经理就可以提供合理的项目计划，技术人员也可以进行下一步的设计、构建以及测试。
需求建模：通过图表的方式将需求可视化。模型可以揭示出错误的、不一致的、缺失的或是冗余的需求。这样的模型包括数据流图、实体关系图、状态转移图、状态表、会话图和决策树等（Beatty and Chen 2012）。更多关于建模的信息请参见第5章、第12章和第13章。
规范说明：
明确需求来源：需求来源确定了需求的合理性，通过记录对应的干系人，可以在变更需求时通知他们。
记录业务规则：包括公司政策、政府法规、标准和算法。与项目需求相互独立，存在周期比项目更长。有些规则会引申出功能需求，反过来又会强化这些规则，所以要定义这些需求及其对应的规则之间的链接关系。更多信息请参见第9章。
记录非功能需求：思维必须跳出功能的局限，才能想到让产品成功的一些质量特性。这些特性包括性能、可靠性、易用性、可修改性等。同样，要记录外部接口需求、设计和实现上的约束、国际化方面的考虑及其他的非功能需求。更多信息请参见第14章。
验证：
验证保证需求的正确性、展示期望的质量特性并满足用户需要。
测试需求：为需求写测试，要你考虑系统是否正确实现系统功能。记录特定情况下产品的预期行为；与客户一起走查，确保它反应了用户的真实期望；与需求相对应，确保没有需求被遗漏；
模拟需求：用商业工具来模拟计划中的系统。迅速搭建一个可运行的系统模型，让用户与模拟系统交互来验证需求和作出设计决策。
需求管理：
建立需求变更流程：变更流程应当定义如何提出、分析和解决需求变更。缺陷跟踪工具可以支持这种变更控制流程。第28章。
维护一个需求跟踪矩阵：维护一个需求可跟踪矩阵把每个功能需求与设计、实现它的代码以及验证它的测试相互联系起来。第29章。
本章作者从7个方面简单介绍了需求工程的优秀实践，想要具体了解这些内容可以详细查阅书中对应的章节，这里仅按需求分析和管理列出了本人以前工作没注意到和不够了解的方法。
以上就是《软件需求》第一部分的分享，除了前三章，作者单独列出第四章介绍了业务分析师，我们以后单独分享。
网友评论