如何写需求,申和平 2013年11月,软件工程，从需求开始。,1. 需求知识概述 1.1 软件需求的重要性 1.2 软件需求基本概念 1.3 优秀需求应具备特征 1.4 需求开发的主要困难 1.5 需求分析员应备能力,2. 软件需求开发 2.1 需求获取 2.2 需求分析 2.3 需求规格说明 2.4 需求验证,3. 软件需求管理 3.1 需求版本控制 3.2 需求变更控制 3.3 需求跟踪控制,目录,典型的软件开发,软件需求的重要性,中国有句谚语：“好的开始就等于成功的一半”。,项目遇困几大原因,需求是制定项目计划的基础。 需求规格说明是软件设计和软件实现的基础。 需求规格说明是测试工作和用户验收的依据。 需求规格说明是软件维护工作的依据。,河的源头被污染，那么整条河也就被污染了。,缺乏用户的参与。（13%） 不完整规格说明。（12%） 不断变更的需求。（12%）,需求错误的代价,我们往往并不清楚究竟该做什么，却一直忙碌不停的开发。 需求不清楚就进入编码阶段，期望以后修改，更多的情况下是编写边修改。 软件调节和改变是很灵活的，任何需求的变更都可以很容易的在软件中反应出来。,你是如此吗？,这些认识多来自极小项目的开发经验，当你面对一个中大型项目时？,软件需求的定义,IEEE软件工程标准词汇表（1977）中的需求定义： 用户解决问题或达到目标所需的条件或权能。 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。 一种反应上述所描述的条件或权能的文档说明。,通俗地讲，需求来源于用户的一些需要，这些需要被分析、确认后形成完成的文档，该文档详细的说明了产品必须或应当做什么。,需求工程的定义,所有与需求直接相关的活动通称为需求工程。其可大致分为需求开发和需求管理两个阶段。其中需求开发主要产生需求规格说明，需求管理主要是根据需求的变化对需求规格说明的内容及版本进行管理。,软件需求的层次（1）,软件需求的层次（2）,软件需求的质量属性（1）,软件需求的质量属性（2）,有时不可避免地要对一些特定的属性进行取舍。,优秀需求应具备的特征,需求开发的主要困难与对策（1）,用户说不清楚需求 问题：有些用户不知道需求是什么，或对需求只有朦胧的感觉，他当然说不清楚需求。还有些用户虽然心里明白想要什么，但却表达不清楚。 策略：需求分析员不能以用户说不清楚需求为借口而草率地对待需求开发，无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。,需求开发的主要困难与对策（2）,态度问题 问题：很多开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会找一堆用户的毛病，认为需求是用户的事情，不是我们的事情。 策略：用户说不清楚需求或者需求发生变更都是常见的问题，我们可以设法解决的。开发人员不应该把这些问题当成借口。需求分析员的职责就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。,需求开发的主要困难与对策（3）,知识技能欠缺 问题：需求分析员缺乏应用域知识，应用域的知识是无边无际的，任何人都不可能是万事通。需求分析员可能是某一领域的专家，当他接手陌生的业务时，他可能是个无知者。 策略：要勇于实践，不要逃避。还应当赶紧补习应用域知识，不论是通过自学还是培训的方式。可能的话，最好请既懂软件又懂应用域知识的行家来帮忙。,需求开发的主要困难与对策（4）,双方误解需求 问题：人们在交流的时候，经常会发生问非所求、答非所问的事情。有时用户会把开发人员的建议或答复想歪了，而用户表达的需求，不同的开发人员可能有不同的理解。 策略：如果需求分析员误解了需求，那会导致后续的开发人员将错就错、白忙活。不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求，所以应当做好需求确认工作。,需求开发的主要困难与对策（5）,开发人员写不好需求文档 问题：需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。或者开发人员的写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。 策略：把需求调查工作做好，提高开发人员的写作能力，多练习写文档。另外，企业提供合适的文档模板以及比较好的示例文档，也可有效降低写作难度。,需求开发的主要困难与对策（6）,用户需求变更频繁 问题：在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。或者由于市场变化而导致产品需求发生变更。 策略：做好需求变更控制。需求变更通常会对项目的进度、人力资源、经费产生很大的影响。需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。,需求开发的主要困难与对策（7）,合作关系 问题：需求分析员不能与用户建立良好的合作关系。对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你。 策略：出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流和沟通能力。对于重大复杂的项目，不能完全期望双方能够自发地建立起良好地合作关系。 要使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。,需求分析员应备能力,2,软件需求开发,2.1 需求获取 2.2 需求分析 2.3 需求规格说明 2.4 需求验证,需求获取,需求获取就是进行需求收集的一个过程或者活动。它从人员、资料和环境中得到系统开发所需要的相关信息。我将从以下几个方面来讲述。,需求常见来源 需求获取内容 需求获取常用方法 需求获取常见困难 需求获取实践经验,需求常见来源,用户提交的需求文档。 与用户进行探讨。 现有系统的问题报告和改进要求。 观察或体验用户工作。 市场调查和用户问卷调查。 对同类产品或竞品进行分析。 对用户的工作情景进行分析。 行业专家的建议,需求获取的内容,明确业务需求 明确项目范围 明确业务流程和业务规则 明确数据定义 明确软件功能 明确质量属性 明确系统接口 明确设计和实现约束,需求获取常用方法,需求获取方法很多。每种方法有其各自优缺点，适用于不同的场合。需求获取人员需要了解各种方法的使用场景及优缺点，以便在不同的场合采取不同的方法开展需求获取工作。,用户访谈,用户访谈是实践当中应用最为广泛的需求获取方法之一。 优点：简单、直接、形式灵活、交流比较深入。 缺点：占用时间长，信息存在片面性。 应用场景：用户访谈在所有的需求获取中都被开发者广泛使用，需要注意的是访谈的目标和话题根据用户的不同而有所侧重。,用户访谈-话题类型（1）,用户访谈-话题类型（2）,用户访谈-话题类型（3）,用户访谈-时间安排,用户访谈尽量选择相对封闭的环境，一次访谈的时间一般不要超过1小时。下面是很多书籍中提供的一个参考时间安排。,用户访谈-记录工作,用户访谈期间将会产生大量的信息，免不了记录的工作。下面是很多经典的案例为我们提供了可参考的记录方式。,用户访谈-沟通技巧,多数情况下，应该事先制作访谈问卷发给被访谈者，罗列出要问的主要问题。被访谈者事前有这样的问卷，他有可能进行一些思考，不至于会谈时无话可谈或者无话不谈。 把握访谈方向，在整个访谈过程中，信息应该是从被访谈者流向访谈者，而不是相反。有资料认为，被访谈者与访谈者说话时间的比例应该是2:1。 不要问过长的问题，较长的问题应该将其拆分，采用递进的方法逐个解决。,用户访谈-提问顺序,访谈提问的顺序应该按业务逻辑组织。面对每一组问题，注意借鉴归纳和演绎方式。 金字塔结构（归纳：特定问题开始，通用问题结束） 被会见者需要对话题进行预热，通过逐步引导使被会见者打开话匣子。 会见者发现自己事先对事实的确认存在较大偏差。 会见者看上去不情愿讨论这个话题。 漏斗结构（演绎：通用问题开始，特定问题结束） 漏斗结构为开始一场面谈提供了一种容易而轻松的途径。 被会见者对这个话题有情绪，并且需要自由表达这些情绪的时候。 会见者事先对事实了解不多时。 用这种方式组织面谈能得出很多的详细信息 菱形结构（归纳演绎-归纳：特定问题开始，转向通用问题，特定问题结束） 使用菱形结构的主要优点是通过各种各样的问题保持被会见者的兴趣和注意力。一旦掌握了如何在正确的时间问正确的问题，就可以多样地选择问题的顺序。,用户访谈-计划安排,在用户访谈前，要有精心的计划安排，根据需求获取所处的阶段确定访谈的时间、人员和主题等，将访谈内容事前告知被访谈人， 避免访谈效率低下。针对不同的访谈人，要采用不同的方式和要点。,用户访谈计划安排模板,用户访谈-过程小结,准备访谈 阅读背景资料，确定面谈主题、目标、问题和被会见者。注意记得和被会见者联系并确认面谈的安排，不要迟到，着装正式。 主持访谈 开始尽量建立一个理想的氛围和环境来促进会见者和被会见者之间的交流和沟通 。 1、简要重申面谈的目标。 2、用一些非常一般的、轻松的、开放式的问题作为开始。 3、准备好笔记本、录音机或者其他记录设备，并礼貌地询问相关人员是否可以录音或者录像。 过程中通过提问和倾听来完成和被会见者的信息交流，按照计划控制面谈的进行，必要时进行适当的调整。 1、保持有礼貌的倾听。 2、保持面谈主题 、控制面谈过程。 3、观察被会见者。 结束时要表示感谢并回答被会见者提出的问题，保持与被会见者的亲善和信任关系 。 1、面谈应该在1小时内结束，并非要在提出所有关心的问题后才能结束面谈。 2、总结谈话的要点。 3、感谢被会见者，并且给时间让他们询问一些他们自己关心的问题。 处理访谈结果 复查面谈记录 ，总结面谈信息 ，整理出内容要点，进行分类，整理成文档。,原型法-为什么要建立原型,原型作为一种需求工具，可明确并完善需求。 原型作为一种设计工具，可用它优化系统易用性，评估可能的技术方案。 原型作为一种构造工具，是产品最初的功能实现，可发展为最终产品。 使用原型，发现并解决需求中的二义性、不完整性和不确定性问题。 直观的原型，更易于理解，能更具体地思考问题。 构建原型的目标是降低项目风险。,原型法-为什么要建立原型,软件开发早期，有时很难定义出确切的软件需求，提供详细的需求规格说明书。软件系统的很多具体细节往往是随着软件系统的建立而逐步明确的。这样，在需求分析阶段，分析人员常常得花大量时间去捕捉一些非常模糊的想法，并花大量时间以这种模糊的认识为基础去编写包括很多细节内容的需求规格说明书，因而需求规格说明书的一致性、准确性、正确性、有效性很难保证。 常规的软件开发各阶段相互传递信息的唯一工具是文档。 虽然文档内有很多形象的描述方法，如各种图表等，但它们毕竟是实际系统的抽象。即使在软件开发早期作出了明确的需求分析，其后每一个阶段的开发人员都不得不再花大量时间，在一定程度上，通过阅读文档重温前一阶段系统人员的工作。同时，由于这些阶段的系统人员一般不和客户作直接交流，因而，可能出现的情况是，需求分析中已经得到正确说明的问题，经过这些阶段中不同的系统人员的各种理解和加工后，在继续传递的过程中发生。 在系统人员和客户面前，不存在一个实实在在的事物。 这个实体可以充分表达系统人员对问题空间有关概念的理解程度和对目标系统的初步考虑，客户也可通过这个实体，阐明其对目标系统的要求和系统人员当前的一些理解错误。基于这些问题，信息系统开发需要更为实用的方法指导开发过程。原型法即是适应这种需要产生的一种信息系统开发方法。,原型法-好处,原型可以激活用户的思维，并促进需求对话。 原型的早期反馈有助于涉众对系统需求理解达成共识。 增加开发者之间的交流，帮助确定技术解决方案的可行性。 有效的识别风险和解决风险，帮助进行风险管理。 提高用户在软件开发中的参与程度。 帮助需求工程师及早解决需求的不确定性。,原型法-类别,按照构建技术分类 水平原型方法：仅实现选定功能所有层次中的某些特定层次。 垂直原型方法：实现选定功能的所有层次。 按照使用方式分类 演示原型：