如何写需求课件

如何写需求申和平2013年11月软件工程，从需求开始。如何写需求申和平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需求跟踪控制目录1.需求知识概述2.软件需求开发3.软件需求管理目录典型的软件开发典型的软件开发软件需求的重要性中国有句谚语：“好的开始就等于成功的一半”。项目遇困几大原因需求是制定项目计划的基础。需求规格说明是软件设计和软件实现的基础。需求规格说明是测试工作和用户验收的依据。需求规格说明是软件维护工作的依据。河的源头被污染，那么整条河也就被污染了。缺乏用户的参与。（13%）不完整规格说明。（12%）不断变更的需求。（12%）需求错误的代价软件需求的重要性中国有句谚语：“好的开始就等于成功的一半”。我们往往并不清楚究竟该做什么，却一直忙碌不停的开发。需求不清楚就进入编码阶段，期望以后修改，更多的情况下是编写边修改。软件调节和改变是很灵活的，任何需求的变更都可以很容易的在软件中反应出来。你是如此吗？这些认识多来自极小项目的开发经验，当你面对一个中大型项目时？你是如此吗？这些认识多来自极小项目的开发经验，当你面对一个中软件需求的定义IEEE软件工程标准词汇表（1977）中的需求定义：用户解决问题或达到目标所需的条件或权能。系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。一种反应上述所描述的条件或权能的文档说明。通俗地讲，需求来源于用户的一些需要，这些需要被分析、确认后形成完成的文档，该文档详细的说明了产品必须或应当做什么。软件需求的定义IEEE软件工程标准词汇表（1977）中的需求需求工程的定义所有与需求直接相关的活动通称为需求工程。其可大致分为需求开发和需求管理两个阶段。其中需求开发主要产生需求规格说明，需求管理主要是根据需求的变化对需求规格说明的内容及版本进行管理。需求工程的定义所有与需求直接相关的活动通称为需求工程。其可大软件需求的层次（1）软件需求的层次（1）软件需求的层次（2）业务需求表示组织机构或客户对系统或产品高层次的目标。它们在项目视图与范围文档中予以说明。描述组织为什么要开发一个系统。用户需求描述用户的目标，或用户要求系统必须完成的任务。用例、场景描述都是表达用户需求的有效途径。描述用户使用系统能做什么。功能需求定义了开发人员必须要实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。非功能需求描述了系统完成功能实现的补充约束条件。如系统必须遵从的标准、规范、合约、性能要求、设计或实现的约束条件及质量属性。软件需求的层次（2）业务需求表示组织机构或客户对系统或产品高软件需求的质量属性（1）外部质量，对用户很重要。正确性软件按照需求正确执行任务的能力。正确性无疑是第一重要的质量属性。健壮性是指在异常情况下软件能够正常运行的能力。健壮性有两层含义，一是容错能力，二是恢复能力。可靠性是指在一定的环境下和给定的时间内，软件不发生故障正常运行的概率。性能是指软件的响应能力。既要经过多长时间才能对某个事件做出响应，或者在某段时间内软件所能处理事件的个数。安全性是指防止软件被非法入侵的能力。既属于技术问题又属于管理问题。易用性是指用户使用软件的容易程度。兼容性是指不同产品或者新老产品相互交换信息的能力。软件需求的质量属性（1）外部质量，对用户很重要。正确性软件按软件需求的质量属性（2）内部质量，对开发者很重要。易理解性是指开发人员理解软件产品的能力。意味着所有的工作成果要易读易懂，可以提高团队开发效率，降低维护成本。开发人员只有在自己思路清晰的时候才可能写出让别人易读易懂的程序和文档。可理解的东西通常是简洁的。可测试性是指测试软件组件或集成产品时查找缺陷的简易程度，又称为可验证性。可维护性是指在软件中纠正一个缺陷或做一次更改的简易程度。可扩展性是指软件适应变化的能力。可移植性是指软件不经修改或稍加修改就可以运行于不同软硬件环境的能力。主要体现为代码的可移植性。可复用性是指一个软件的组成部分可以在同一个项目的不同地方甚至在不同的项目中重复使用的能力。有时不可避免地要对一些特定的属性进行取舍。软件需求的质量属性（2）内部质量，对开发者很重要。易理解性是优秀需求应具备的特征完整性每项需求都必须将所要实现的功能描述清楚。正确性每一项需求都必须准确地陈述其要开发的功能，符合需求来源。可行性每项需求在已知环境的权能和限制下可实施。可多方人员参与。必要性每项需求都能回溯至某项用户需求。划分优先级给每项需求分配一个实施优先级以指明它在产品中的重要程度。无二义性对所有需求说明的读者都只能有一个明确统一的解释。可验证性每项需求能够被验证。验证方法如测试用例、正规审查等。与实现无关性需求关注系统做什么，而不是怎么做。优秀需求应具备的特征完整性每项需求都必须将所要实现的功能描述需求开发的主要困难与对策（1）用户说不清楚需求问题：有些用户不知道需求是什么，或对需求只有朦胧的感觉，他当然说不清楚需求。还有些用户虽然心里明白想要什么，但却表达不清楚。策略：需求分析员不能以用户说不清楚需求为借口而草率地对待需求开发，无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。需求开发的主要困难与对策（1）用户说不清楚需求需求开发的主要困难与对策（2）态度问题问题：很多开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会找一堆用户的毛病，认为需求是用户的事情，不是我们的事情。策略：用户说不清楚需求或者需求发生变更都是常见的问题，我们可以设法解决的。开发人员不应该把这些问题当成借口。需求分析员的职责就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。需求开发的主要困难与对策（2）态度问题需求开发的主要困难与对策（3）知识技能欠缺问题：需求分析员缺乏应用域知识，应用域的知识是无边无际的，任何人都不可能是万事通。需求分析员可能是某一领域的专家，当他接手陌生的业务时，他可能是个无知者。策略：要勇于实践，不要逃避。还应当赶紧补习应用域知识，不论是通过自学还是培训的方式。可能的话，最好请既懂软件又懂应用域知识的行家来帮忙。需求开发的主要困难与对策（3）知识技能欠缺需求开发的主要困难与对策（4）双方误解需求问题：人们在交流的时候，经常会发生问非所求、答非所问的事情。有时用户会把开发人员的建议或答复想歪了，而用户表达的需求，不同的开发人员可能有不同的理解。策略：如果需求分析员误解了需求，那会导致后续的开发人员将错就错、白忙活。不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求，所以应当做好需求确认工作。需求开发的主要困难与对策（4）双方误解需求需求开发的主要困难与对策（5）开发人员写不好需求文档问题：需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。或者开发人员的写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。策略：把需求调查工作做好，提高开发人员的写作能力，多练习写文档。另外，企业提供合适的文档模板以及比较好的示例文档，也可有效降低写作难度。需求开发的主要困难与对策（5）开发人员写不好需求文档需求开发的主要困难与对策（6）用户需求变更频繁问题：在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。或者由于市场变化而导致产品需求发生变更。策略：做好需求变更控制。需求变更通常会对项目的进度、人力资源、经费产生很大的影响。需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。需求开发的主要困难与对策（6）用户需求变更频繁需求开发的主要困难与对策（7）合作关系问题：需求分析员不能与用户建立良好的合作关系。对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你。策略：出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流和沟通能力。对于重大复杂的项目，不能完全期望双方能够自发地建立起良好地合作关系。要使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。需求开发的主要困难与对策（7）合作关系需求分析员应备能力行业知识熟悉相关行业和领域的知识及产品。沟通能力善于双向交流，知道如何有效倾听和表达。分析能力能够以不同的角度和方式思考问题。组织能力需要处理获取和分析过程中收集到的大量杂乱的信息。写作能力需求开发的最终产物是需求规格说明文档。专业技术需要掌握如数据流图、用例图、实体关系图等建模分析工具。提问技巧很多需求是通过面谈和讨论得到。观察能力能够从不经意的闲谈或观察中发现重要信息。需求分析员应备能力行业知识熟悉相关行业和领域的知识及产品。沟2软件需求开发2.1需求获取2.2需求分析2.3需求规格说明2.4需求验证2软件需求开发2.1需求获取需求获取

需求获取就是进行需求收集的一个过程或者活动。它从人员、资料和环境中得到系统开发所需要的相关信息。我将从以下几个方面来讲述。需求常见来源需求获取内容需求获取常用方法需求获取常见困难需求获取实践经验需求获取需求获取就是进行需求收集的一个过程或者活动。需求常见来源用户提交的需求文档。与用户进行探讨。现有系统的问题报告和改进要求。观察或体验用户工作。市场调查和用户问卷调查。对同类产品或竞品进行分析。对用户的工作情景进行分析。行业专家的建议需求常见来源用户提交的需求文档。需求获取的内容明确业务需求明确项目范围明确业务流程和业务规则明确数据定义明确软件功能明确质量属性明确系统接口明确设计和实现约束需求获取的内容明确业务需求需求获取常用方法

需求获取方法很多。每种方法有其各自优缺点，适用于不同的场合。需求获取人员需要了解各种方法的使用场景及优缺点，以便在不同的场合采取不同的方法开展需求获取工作。1、用户访谈2、原型法3、观察法4、文档分析5、需求专题讨论6、用户问卷调查需求获取常用方法需求获取方法很多。每种方法有其各自优用户访谈用户访谈是实践当中应用最为广泛的需求获取方法之一。优点：简单、直接、形式灵活、交流比较深入。缺点：占用时间长，信息存在片面性。应用场景：用户访谈在所有的需求获取中都被开发者广泛使用，需要注意的是访谈的目标和话题根据用户的不同而有所侧重。用户访谈用户访谈是实践当中应用最为广泛的需求获取方法之一。用户访谈---话题类型（1）开放式话题封闭式话题被会见者对答复的选择是开放和不受限制的，他们可能答复两个词，也可能答复两段话。在希望得到丰富，具有一定深度和广度的信息时，开放式问题比较合适。答案有基本的形式，被会见者的回答是受到限制的，如选择题、判断题等。例如：1、你对屌丝一词有什么看法？例如：1、呼叫中心一月平均接到多少个电话？2、下列哪个信息对你最有用？用户访谈---话题类型（1）开放式话题封闭式话题被会见者对答用户访谈---话题类型（2）开放式话题封闭式话题优点被会谈者感觉更自在和感兴趣；可获得丰富的细节；允许更多的自发性；可以收集被会谈者使用的词汇；对没采用的进一步的提问有启迪作用；可以在没有太多准备的情况下进行；节省时间；切中要点；保持对面谈的控制；快速探讨大范围问题；得到贴切的数据；缺点可能产生太多不相干的细节；面谈可能失控；会花费大量时间才能获得有用的信息量；可能使会谈者看上去没有准备；会谈者比较厌烦；得不到丰富的细节；不利于建立友好关系；用户访谈---话题类型（2）开放式话题封闭式话题优点被会谈者用户访谈---话题类型（3）开放式话题对比项封闭式话题低数据的可靠性高低使用的时间效率高低数据的精度高广数据的广度和深度窄多需要的面谈技能少难分析的难易度易用户访谈---话题类型（3）开放式话题对比项封闭式话题低数据用户访谈---时间安排阶段任务占用时间备注开场白陈述预先对问题的考虑和理解5-15分钟聚焦本次访谈的话题，明确访谈的范围和层次预先计划问题寻找问题的答案25-30分钟主体工作，关键部分即兴问题扩大需求信息量20-30分钟注意导向，不要跑题太远总结总结访谈内容5-10分钟访谈者向被访谈者复述主要问题的答案用户访谈尽量选择相对封闭的环境，一次访谈的时间一般不要超过1小时。下面是很多书籍中提供的一个参考时间安排。用户访谈---时间安排阶段任务占用时间备注开场白陈述预先对问用户访谈---记录工作用户访谈期间将会产生大量的信息，免不了记录的工作。下面是很多经典的案例为我们提供了可参考的记录方式。记录方式优点缺点建议自己做笔记直接、简单、灵活容易走神记重点要点，并确认专人做笔记精力集中在访谈上容易产生记录偏差访谈结束时让记录人员向双方做简要陈述录音免受记录工作影响信息易失真记录大纲和关键信息录像免受记录工作影响难以操作用户访谈---记录工作用户访谈期间将会产生大量的信息，免不了用户访谈---沟通技巧多数情况下，应该事先制作访谈问卷发给被访谈者，罗列出要问的主要问题。被访谈者事前有这样的问卷，他有可能进行一些思考，不至于会谈时无话可谈或者无话不谈。把握访谈方向，在整个访谈过程中，信息应该是从被访谈者流向访谈者，而不是相反。有资料认为，被访谈者与访谈者说话时间的比例应该是2:1。不要问过长的问题，较长的问题应该将其拆分，采用递进的方法逐个解决。用户访谈---沟通技巧多数情况下，应该事先制作访谈问卷发给被用户访谈---提问顺序访谈提问的顺序应该按业务逻辑组织。面对每一组问题，注意借鉴归纳和演绎方式。金字塔结构（归纳：特定问题开始，通用问题结束）被会见者需要对话题进行预热，通过逐步引导使被会见者打开话匣子。会见者发现自己事先对事实的确认存在较大偏差。会见者看上去不情愿讨论这个话题。漏斗结构（演绎：通用问题开始，特定问题结束）漏斗结构为开始一场面谈提供了一种容易而轻松的途径。被会见者对这个话题有情绪，并且需要自由表达这些情绪的时候。会见者事先对事实了解不多时。用这种方式组织面谈能得出很多的详细信息菱形结构（归纳—演绎-归纳：特定问题开始，转向通用问题，特定问题结束）使用菱形结构的主要优点是通过各种各样的问题保持被会见者的兴趣和注意力。一旦掌握了如何在正确的时间问正确的问题，就可以多样地选择问题的顺序。用户访谈---提问顺序访谈提问的顺序应该按业务逻辑组织。面对用户访谈---计划安排在用户访谈前，要有精心的计划安排，根据需求获取所处的阶段确定访谈的时间、人员和主题等，将访谈内容事前告知被访谈人，避免访谈效率低下。针对不同的访谈人，要采用不同的方式和要点。访谈主题访谈要点期望部门访谈人访谈时间备注用简短的话概述提取关键点指定理想的访谈对象用户方联络人指定用户方联络人指定用户访谈计划安排模板用户访谈---计划安排在用户访谈前，要有精心的计划安排，根据用户访谈---过程小结准备访谈阅读背景资料，确定面谈主题、目标、问题和被会见者。注意记得和被会见者联系并确认面谈的安排，不要迟到，着装正式。主持访谈开始尽量建立一个理想的氛围和环境来促进会见者和被会见者之间的交流和沟通。1、简要重申面谈的目标。2、用一些非常一般的、轻松的、开放式的问题作为开始。3、准备好笔记本、录音机或者其他记录设备，并礼貌地询问相关人员是否可以录音或者录像。过程中通过提问和倾听来完成和被会见者的信息交流，按照计划控制面谈的进行，必要时进行适当的调整。1、保持有礼貌的倾听。2、保持面谈主题、控制面谈过程。3、观察被会见者。结束时要表示感谢并回答被会见者提出的问题，保持与被会见者的亲善和信任关系。1、面谈应该在1小时内结束，并非要在提出所有关心的问题后才能结束面谈。2、总结谈话的要点。3、感谢被会见者，并且给时间让他们询问一些他们自己关心的问题。处理访谈结果复查面谈记录，总结面谈信息，整理出内容要点，进行分类，整理成文档。用户访谈---过程小结准备访谈原型法---为什么要建立原型原型作为一种需求工具，可明确并完善需求。原型作为一种设计工具，可用它优化系统易用性，评估可能的技术方案。原型作为一种构造工具，是产品最初的功能实现，可发展为最终产品。使用原型，发现并解决需求中的二义性、不完整性和不确定性问题。直观的原型，更易于理解，能更具体地思考问题。构建原型的目标是降低项目风险。原型法---为什么要建立原型原型作为一种需求工具，可明确并完原型法---为什么要建立原型软件开发早期，有时很难定义出确切的软件需求，提供详细的需求规格说明书。软件系统的很多具体细节往往是随着软件系统的建立而逐步明确的。这样，在需求分析阶段，分析人员常常得花大量时间去捕捉一些非常模糊的想法，并花大量时间以这种模糊的认识为基础去编写包括很多细节内容的需求规格说明书，因而需求规格说明书的一致性、准确性、正确性、有效性很难保证。常规的软件开发各阶段相互传递信息的唯一工具是文档。

虽然文档内有很多形象的描述方法，如各种图表等，但它们毕竟是实际系统的抽象。即使在软件开发早期作出了明确的需求分析，其后每一个阶段的开发人员都不得不再花大量时间，在一定程度上，通过阅读文档重温前一阶段系统人员的工作。同时，由于这些阶段的系统人员一般不和客户作直接交流，因而，可能出现的情况是，需求分析中已经得到正确说明的问题，经过这些阶段中不同的系统人员的各种理解和加工后，在继续传递的过程中发生。在系统人员和客户面前，不存在一个实实在在的事物。

这个实体可以充分表达系统人员对问题空间有关概念的理解程度和对目标系统的初步考虑，客户也可通过这个实体，阐明其对目标系统的要求和系统人员当前的一些理解错误。基于这些问题，信息系统开发需要更为实用的方法指导开发过程。原型法即是适应这种需要产生的一种信息系统开发方法。原型法---为什么要建立原型软件开发早期，有时很难定义出确切原型法---好处原型可以激活用户的思维，并促进需求对话。原型的早期反馈有助于涉众对系统需求理解达成共识。增加开发者之间的交流，帮助确定技术解决方案的可行性。有效的识别风险和解决风险，帮助进行风险管理。提高用户在软件开发中的参与程度。帮助需求工程师及早解决需求的不确定性。原型法---好处原型可以激活用户的思维，并促进需求对话。原型法---类别按照构建技术分类水平原型方法：仅实现选定功能所有层次中的某些特定层次。垂直原型方法：实现选定功能的所有层次。按照使用方式分类演示原型：主要用在启动项目阶段，让用户相信系统的开发是可行的。一般原型：主要用在分析需求阶段，用来阐明用户界面或者系统功能。试验原型：主要用在构建系统阶段，帮助开发者澄清构建相关技术问题。按照开发方式分类抛弃式原型：用最快速度，花最小代价，适用于不确定的需求。演化式原型：质量要求高，要易于扩展和改进，适用于清晰的需求。按照使用介质分类书面原型：也称低保真原型，是一种成本低、速度快且不涉及高深技术的方法。程序或工具原型：使用编程语言或专业工具创建。

原型法---类别按照构建技术分类原型法---风险用户看到了一个正在运行的原型，得出产品几乎已经完成的结论，从而提出快速交付产品的不当要求。原型开发投入太多的工作，使得开发团队消耗了过多的时间和成本。原型法---风险用户看到了一个正在运行的原型，得出产品几乎已原型法---创建原型遵循原则应该在项目计划中包括创建原型的任务。废弃型原型要尽量快速而经济，其中不应包括输入数据有效性检查、用于错误处理的代码或代码注释文档。对于已经理解的需求不要建立原型，除非是要研究设计方案。在原型屏幕显示和报告中使用看似真实的数据。不要期望用原型完全代替软件需求规格说明。原型法---创建原型遵循原则应该在项目计划中包括创建原型的任用户问卷调查用户调查在市场调查领域应用非常广泛。优点：调查面比较宽，用户反馈多。缺点：不易深入。适用场景：所以当片面性矛盾比较突出时就可以采用用户调查的方式。比如存在大样本用户或存在跨地域的用户时。有时可以将用户访谈和用户调查结合使用。先调查后访谈：从问卷调查的结果中整理出一个关键点，然后选取一些用户代表进行有针对性的访谈。先访谈后调查：选取一些典型的用户，然后对访谈的结果进行整理。在这些基础上设计调查问卷。通过调查来验证用户访谈的结果是否具有普遍性。用户问卷调查用户调查在市场调查领域应用非常广泛。用户问卷调查---调查问卷设计要点1、注意问题篇幅和布局通常认为问卷不要让用户在回答时花太多的时间，一般不超过20分钟。换句话说，就是量不要超过3页。问题排列应该先易后难。另外，要有逻辑相关性的考虑。跳跃太大的问卷，往往会干扰答卷人的思路。从而降低了答卷的质量。2、注意问题类型的选择尽量选择开放性（简答题）或半封闭（多选题）的题型，少用封闭性题型（判断题）。研究表明，从信息收集的有效性来说，开放性问题效果最好。半封闭型问题次之，封闭型问题最差。用户问卷调查---调查问卷设计要点1、注意问题篇幅和布局文档分析法

文档分析是专门针对文档进行需求获取的活动。其主要获取对象包括相关产品的需求说明书、客户需求文档、相关数据及流程说明等。

其主要优点是能够详细、直观地对数据流细节进行了解和分析。缺点也比较明显，企业机构中，文档量通常非常大，由此容易使需求获取人员陷入文山书海中不能自拔，甚至引起误导。文档分析通常配合用户访谈或者用户调查期间开展。采用此策略的的目的是因为用户访谈或者用户调查难以获得数据方面的详细需求，你不能指望被访谈者或者被调查者能够记住相关数据细节。

文档分析是研究、分析、细化数据的重要手段。文档分析法文档分析是专门针对文档进行需求获取的活动。观察法如果：用户说的和做的一致吗？用户难以描述他们是如何做的？用户描述的业务流程会否因为某些原因遗漏掉重要的信息？那么：看他们是怎么工作的。需求分析人员参与到他们的具体工作中，观察或体验业务操作过程及物理环境，根据实际的情况提问并记录，记录业务员操作过程及碰到的难题。观察法对于理解业务流程和获取真实的材料非常有效。观察法如果：小组讨论法小组讨论是指将与项目某个问题相关的人员聚集在一起开会讨论。优势是容易在内部取得对方案的认同，有利于项目的开展，在讨论会上每个相关人员都可发表自己的意见，保证了获取信息的全面性。先确定好议题、内容、主讲人、参会人员、会议室、开会时间。事先将相关资料送达参与人员，让参与人员开会前先了解会议的整体背景和需讨论的问题，有利于会议的顺利开展。保证每个人都有发言时间，注意控制会议时间。会后将会议纪要发送给参会人员，取得对结果的认同。小组讨论法小组讨论是指将与项目某个问题相关的人员聚集需求获取常见困难用户没时间或不愿花太多时间与开发人员进行交流或讨论。开发人员缺乏用户的业务常识，双方交流困难。用户与开发人员的背景不同、立场不同。普通用户缺乏概括性、综合性的表述能力。没有明确的用户。需求获取常见困难用户没时间或不愿花太多时间与开发人员进行交流需求获取实践经验需求获取需要主动“获取”是一个主动性词汇，强调需求分析人员在整个过程中应该充分发挥主动性。主动表现为有计划性，针对不同的用户层次选择不同的方法。了解相关业务知识对业务系统的知识理解，是需求获取的基础。缺乏这一点，将无从着手或没有章法，难以发挥技巧的作用。捕获用户的隐性需求满足用户的显性需求是底线，隐性需求是培养用户忠诚度的最好武器，但隐形需求的度要把握好，并不是所有的需求都是受欢迎的。需求获取实践经验需求获取需要主动需求获取实践经验不要奢望一次将用户需求获取一般情况，不要指望一次或几次需求碰头会就会将用户需求全部获取。实际情况是前几次用户提出的问题比较少，后面越来越多，你会受不了。理解业务场景非常重要用户对需求的理解主要还是从自身的业务出发，他们能够提出的需求是基本需求，若仅停留在这一点上，会给系统开发带来许多问题。如能深入用户的工作实际环境，感受实际场景，能大大减少需求变更的可能。需求获取实践经验不要奢望一次将用户需求获取需求获取实践经验需求往往需要协商不同业务层面（甚至相同业务层面）的用户对同样的概念或流程存在理解差异时，在需求整理时应将这些差异明确标识出来，并展示给用户的高层领导，由他们决定如何消除这些差异，并将这些情况记录。学会复述在用户阐述了需求之后，用自己的语言再复述一遍，以确保沟通没有失真。多问几个为什么多问用户几个为什么，找到问答题的本质，理解用户的真实意图和深层目标。需求获取实践经验需求往往需要协商2软件需求开发2.1需求获取2.2需求分析2.3需求规格说明2.4需求验证2软件需求开发2.1需求获取需求分析目标（1）需求分析的目标是对获取的需求进行分解、抽象，在此过程中消除需求矛盾、建立分析模型、创建解决方案，准确地回答系统必须做什么。需求分析的目标问题域描述整个领域现状是这样运作的现实世界规格说明要构建的系统是这样运作的计算世界需求用户希望事情能这样子运作问题域解系统需求分析目标（1）需求分析的目标是对获取的需求进行分解、抽象需求分析目标（2）（1）分解分解是认识和解决复杂性事务的基本策略。将问题不断分解为较小的问题，直到每个最低层的问题都足够简单。无论采用何种分析法，分解都是必须采用的手段。分解策略说明业务流程为主线是目前比较流行的方法，主要按照业务的角度考虑分解方法。此方法特别适合管理信息系统（MIS）、联机事务处理系统。分解：目标系统主题域业务事件业务活动业务步骤。程序结构为主线是需求分析最常用的分解方法。适合于问题域比较清晰，问题不算复杂的情况。分解：目标系统子系统功能模块子模块功能点。基于数据适合数据仓库之类的项目。分解：目标系统主题域主题类逻辑数据物理数据。基于场景对于决策支持系统、面向用户的嵌入式系统分解：目标系统关注点场景集合使用场景任务。需求分析目标（2）（1）分解分解策略说明业务流程为主线是目前需求分析目标（3）（2）抽象分解是一种自顶向下的方法，当按照任何一种线索进行分解时。就会破坏其它线索的完整性。例如，如果以业务为线索，就会发现数据需求分解后会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。此种情况出现时，可能会影响需求分析人员建立全面的理解，因此需要采用自底向上的方法进行抽象和提炼。例如将每个业务事件中的类进行抽象，抽取出共性的部分，建立针对整个系统的全局领域模型。需求分析目标（3）（2）抽象需求分析目标（4）（3）消除矛盾在分析过程中，显然可能会发现有些需求是相互矛盾的、冲突的，由于是将收集的信息放在一个预先定义的结构中发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也能够知道它影响那些层面。寻找相应的人员，通过进一步需求获取来消除矛盾。（4）建立分析模型通过软件建模，帮助我们按照实际情况或按照我们需要的模式对系统进行可视化，提供一种详细说明系统的结构或者行为的方法，给出一个指导系统构造的模板。对所有做出的决定实施文档化。需求分析目标（4）（3）消除矛盾（4）建立分析模型需求分析方法（1）1、结构化分析方法（SA）：采用自顶向下、逐层分解的分析方法来定义系统的需求。以数据和功能为中心。常用工具功能数据字典（DD）模型的核心，对数据流图、实体关系图、状态变迁图中的所有数据对象的描述。数据流图（DFD）用于功能建模，描述系统中数据流程的图形工具，它描述了将系统的逻辑输入转换为逻辑输出所需的加工处理过程。实体关系图（ERD）用于数据建模，描述数据的定义、结构和关系。状态变迁图（STD）用于行为建模，描述系统接收哪些外部事件，以及在外部事件的作用下状态迁移情况。函数过程需求分析方法（1）1、结构化分析方法（SA）：采用自顶向下、需求分析方法（2）常用工具（UML）功能用例图说明角色和使用场景之间的关系，描述用户与系统如何交互。类图描述业务实体、实体特性以及实体之间的关系活动图说明业务流程，以及业务活动的步骤顺序图描述参与交互的对象及对象之间消息交换的顺序。构件图描述构件的结构及他们之间的服务接口状态图描述事件如何改变对象生命周期2、面向对象分析方法（OOA）：利用面向对象的概念和方法为软件需求建造模型。以对象为中心。对象对象对象需求分析方法（2）常用工具（UML）功能用例图说明角色和使用需求分析方法（3）3、功能分解法：将系统看做若干功能模块的集合，每个功能又可以分解为子功能，子功能还可继续分解，分解的结果即是系统的雏形。常用建模工具功能功能分解图在一个图内自上而下集中显示系统的功能分解结构，更加直观的展现大量过程之间的层次关系。需求分析方法（3）3、功能分解法：将系统看做若干功能模块的集2软件需求开发2.1需求获取2.2需求分析2.3需求规格说明2.4需求验证2软件需求开发2.1需求获取需求规格说明书概述

需求获取收集了需求信息，需求分析深入理解了需求信息并建立了能够满足用户需求的解决方案。需求规格说明则是将需求获取、需求分析的结果进行文档化的过程。在软件开发过程中，将分析的结果文档化是不可或缺的任务，也称为编写规约活动。需求规格说明书的完成（撰写完成、验证完成）标志着软件需求阶段告一段落。并将作为下一个阶段设（计开发阶段）的输入和重要依据。需求规格说明书概述需求获取收集了需求信息，需求分析深需求规格说明书的作用需求规格说明书文档可以成为各方人员之间有关软件系统的协议基准。需求规格说明书文档可以成为项目开发活动的一个重要依据。它可以成为软件估算和项目进度安排的基础，也可以成为开发人员判断设计、测试等工作的进行是否正确的依据。需求规格说明书文档可以成为有效的知识资产。该资产可以帮助新加入的团队成员快速融入项目，可以帮助更好地将软件产品移交给新客户，也可以帮助开发者更好地进行其他类似项目或者后续增强项目的开发。需求规格说明书的作用需求规格说明书文档可以成为各方人员之间有需求规格说明活动流图需求规格说明活动流图需求规格说明书写作风格写作风格说明自然语言使用结构合理的自然语言来描述需求。优点：易于编写和阅读，不需要掌握特定的技巧。缺点：不够严谨，歧义性强，表达能力弱。图形化模型在表述时能够给读者提供更强的视觉效果，同时能够使问题更加聚焦。优点：可视化、聚焦性、易于理解。缺点：编写和阅读的人都需要能够正确地理解模型。形式化描述对于逻辑性很强，精度要求很高的场合，形式化描述是一种不错的选择。优点：严谨、精确。缺点：编写和阅读的人都会感到很困难。建议：以自然语言为主，辅以图形化模型，需要的地方少量使用形式化规格描述。需求规格说明书写作风格写作风格说明自然语言使用结构合理的自然需求规格说明书的写作

一般由项目经理负责组织需求规格说明书的写作。SRS的写作没有放之四海而皆准的标准。一般可以考虑按如下开展。制定模板：按照项目的具体应用环境、用户情况、系统特点、公司通用模板构建一个新模板（先制定一个模板，然后让各方人员一起来讨论完善）。写作指南：当需求规格说明由多个人员共同完成时这是非常必要的，否则在合稿时将将会处于崩溃。因为每个人写作的方式、文笔、对问题的理解都存在差异。需求规格说明书的写作一般由项目经理负责组织需求规格说关于写作指南对文档大纲尽量细化（某某负责哪些部分的撰写，在什么时候完成）。对文字、图表、标题等格式做出规约（例如不允许使用四级标题等）。定义术语表，避免术语不一致、错误术语、冗余术语、方言问题。避免歧义词汇，例如可接受的、不应该、有效的、充分的、若干等。避免干扰文本，比如

“上一句话是指…”、这个、那个…..关于写作指南对文档大纲尽量细化（某某负责哪些部分的撰写，在什优秀需求规格说明书的特性特性说明正确性文档内的所有需求都具有正确性。无歧义文档内的所有需求都是无歧义的。可验证文档内的所有需求都是可验证的。完备性描述了所有的需求，包括功能、性能、约束、质量属性、对外接口及待解决问题。一致性不能同高层次的需求相冲突，同一层次的不同需求之间也不能互相冲突。优先级根据重要性和稳定性，建立需求的优先级。可跟踪可向前跟踪、向后跟踪。可修改