如何写需求PPT课件

如何写需求,申和平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、感谢被会见者，并且给时间让他们询问一些他们自己关心的问题。处理访谈结果复查面谈记录，总结面谈信息，整理出内容要点，进行分类，整理成文档。,原型法-为什么要建立原型,原型作为一种需求工具，可明确并完善需求。原型作为一种设计工具，可用它优化系统易用性，评估可能的技术方案。原型作为一种构造工具，是产品最初的功能实现，可发展为最终产品。使用原型，发现并解决需求中的二义性、不完整性和不确定性问题。直观的原型，更易于理解，能更具体地思考问题。构建原型的目标是降低项目风险。,原型法-为什么要建立原型,软件开发早期，有时很难定义出确切的软件需求，提供详细的需求规格说明书。软件系统的很多具体细节往往是随着软件系统的建立而逐步明确的。这样，在需求分析阶段，分析人员常常得花大量时间去捕捉一些非常模糊的想法，并花大量时间以这种模糊的认识为基础去编写包括很多细节内容的需求规格说明书，因而需求规格说明书的一致性、准确性、正确性、有效性很难保证。常规的软件开发各阶段相互传递信息的唯一工具是文档。虽然文档内有很多形象的描述方法，如各种图表等，但它们毕竟是实际系统的抽象。即使在软件开发早期作出了明确的需求分析，其后每一个阶段的开发人员都不得不再花大量时间，在一定程度上，通过阅读文档重温前一阶段系统人员的工作。同时，由于这些阶段的系统人员一般不和客户作直接交流，因而，可能出现的情况是，需求分析中已经得到正确说明的问题，经过这些阶段中不同的系统人员的各种理解和加工后，在继续传递的过程中发生。在系统人员和客户面前，不存在一个实实在在的事物。这个实体可以充分表达系统人员对问题空间有关概念的理解程度和对目标系统的初步考虑，客户也可通过这个实体，阐明其对目标系统的要求和系统人员当前的一些理解错误。基于这些问题，信息系统开发需要更为实用的方法指导开发过程。原型法即是适应这种需要产生的一种信息系统开发方法。,原型法-好处,原型可以激活用户的思维，并促进需求对话。原型的早期反馈有助于涉众对系统需求理解达成共识。增加开发者之间的交流，帮助确定技术解决方案的可行性。有效的识别风险和解决风险，帮助进行风险管理。提高用户在软件开发中的参与程度。帮助需求工程师及早解决需求的不确定性。,原型法-类别,按照构建技术分类水平原型方法：仅实现选定功能所有层次中的某些特定层次。垂直原型方法：实现选定功能的所有层次。按照使用方式分类演示原型：主要用在启动项目阶段，让用户相信系统的开发是可行的。一般原型：主要用在分析需求阶段，用来阐明用户界面或者系统功能。试验原型：主要用在构建系统阶段，帮助开发者澄清构建相关技术问题。按照开发方式分类抛弃式原型：用最快速度，花最小代价，适用于不确定的需求。演化式原型：质量要求高，要易于扩展和改进，适用于清晰的需求。按照使用介质分类书面原型：也称低保真原型，是一种成本低、速度快且不涉及高深技术的方法。程序或工具原型：使用编程语言或专业工具创建。,原型法-风险,用户看到了一个正在运行的原型，得出产品几乎已经完成的结论，从而提出快速交付产品的不当要求。原型开发投入太多的工作，使得开发团队消耗了过多的时间和成本。,原型法-创建原型遵循原则,应该在项目计划中包括创建原型的任务。废弃型原型要尽量快速而经济，其中不应包括输入数据有效性检查、用于错误处理的代码或代码注释文档。对于已经理解的需求不要建立原型，除非是要研究设计方案。在原型屏幕显示和报告中使用看似真实的数据。不要期望用原型完全代替软件需求规格说明。,用户问卷调查,用户调查在市场调查领域应用非常广泛。优点：调查面比较宽，用户反馈多。缺点：不易深入。适用场景：所以当片面性矛盾比较突出时就可以采用用户调查的方式。比如存在大样本用户或存在跨地域的用户时。有时可以将用户访谈和用户调查结合使用。先调查后访谈：从问卷调查的结果中整理出一个关键点，然后选取一些用户代表进行有针对性的访谈。先访谈后调查：选取一些典型的用户，然后对访谈的结果进行整理。在这些基础上设计调查问卷。通过调查来验证用户访谈的结果是否具有普遍性。,用户问卷调查-调查问卷设计要点,1、注意问题篇幅和布局通常认为问卷不要让用户在回答时花太多的时间，一般不超过20分钟。换句话说，就是量不要超过3页。问题排列应该先易后难。另外，要有逻辑相关性的考虑。跳跃太大的问卷，往往会干扰答卷人的思路。从而降低了答卷的质量。2、注意问题类型的选择尽量选择开放性（简答题）或半封闭（多选题）的题型，少用封闭性题型（判断题）。研究表明，从信息收集的有效性来说，开放性问题效果最好。半封闭型问题次之，封闭型问题最差。,文档分析法,文档分析是专门针对文档进行需求获取的活动。其主要获取对象包括相关产品的需求说明书、客户需求文档、相关数据及流程说明等。其主要优点是能够详细、直观地对数据流细节进行了解和分析。缺点也比较明显，企业机构中，文档量通常非常大，由此容易使需求获取人员陷入文山书海中不能自拔，甚至引起误导。文档分析通常配合用户访谈或者用户调查期间开展。采用此策略的的目的是因为用户访谈或者用户调查难以获得数据方面的详细需求，你不能指望被访谈者或者被调查者能够记住相关数据细节。文档分析是研究、分析、细化数据的重要手段。,观察法,如果：用户说的和做的一致吗？用户难以描述他们是如何做的？用户描述的业务流程会否因为某些原因遗漏掉重要的信息？那么：看他们是怎么工作的。需求分析人员参与到他们的具体工作中，观察或体验业务操作过程及物理环境，根据实际的情况提问并记录，记录业务员操作过程及碰到的难题。观察法对于理解业务流程和获取真实的材料非常有效。,小组讨论法,小组讨论是指将与项目某个问题相关的人员聚集在一起开会讨论。优势是容易在内部取得对方案的认同，有利于项目的开展，在讨论会上每个相关人员都可发表自己的意见，保证了获取信息的全面性。,先确定好议题、内容、主讲人、参会人员、会议室、开会时间。事先将相关资料送达参与人员，让参与人员开会前先了解会议的整体背景和需讨论的问题，有利于会议的顺利开展。保证每个人都有发言时间，注意控制会议时间。会后将会议纪要发送给参会人员，取得对结果的认同。,需求获取常见困难,用户没时间或不愿花太多时间与开发人员进行交流或讨论。开发人员缺乏用户的业务常识，双方交流困难。用户与开发人员的背景不同、立场不同。普通用户缺乏概括性、综合性的表述能力。没有明确的用户。,需求获取实践经验,需求获取需要主动“获取”是一个主动性词汇，强调需求分析人员在整个过程中应该充分发挥主动性。主动表现为有计划性，针对不同的用户层次选择不同的方法。了解相关业务知识对业务系统的知识理解，是需求获取的基础。缺乏这一点，将无从着手或没有章法，难以发挥技巧的作用。捕获用户的隐性需求满足用户的显性需求是底线，隐性需求是培养用户忠诚度的最好武器，但隐形需求的度要把握好，并不是所有的需求都是受欢迎的。,需求获取实践经验,不要奢望一次将用户需求获取一般情况，不要指望一次或几次需求碰头会就会将用户需求全部获取。实际情况是前几次用户提出的问题比较少，后面越来越多，你会受不了。理解业务场景非常重要用户对需求的理解主要还是从自身的业务出发，他们能够提出的需求是基本需求，若仅停留在这一点上，会给系统开发带来许多问题。如能深入用户的工作实际环境，感受实际场景，能大大减少需求变更的可能。,需求获取实践经验,需求往往需要协商不同业务层面（甚至相同业务层面）的用户对同样的概念或流程存在理解差异时，在需求整理时应将这些差异明确标识出来，并展示给用户的高层领导，由他们决定如何消除这些差异，并将这些情况记录。学会复述在用户阐述了需求之后，用自己的语言再复述一遍，以确保沟通没有失真。多问几个为什么多问用户几个为什么，找到问答题的本质，理解用户的真实意图和深层目标。,2,软件需求开发,2.1需求获取2.2需求分析2.3需求规格说明2.4需求验证,需求分析目标（1）,需求分析的目标是对获取的需求进行分解、抽象，在此过程中消除需求矛盾、建立分析模型、创建解决方案，准确地回答系统必须做什么。,需求分析目标（2）,（1）分解分解是认识和解决复杂性事务的基本策略。将问题不断分解为较小的问题，直到每个最低层的问题都足够简单。无论采用何种分析法，分解都是必须采用的手段。,需求分析目标（3）,（2）抽象分解是一种自顶向下的方法，当按照任何一种线索进行分解时。就会破坏其它线索的完整性。例如，如果以业务为线索，就会发现数据需求分解后会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。此种情况出现时，可能会影响需求分析人员建立全面的理解，因此需要采用自底向上的方法进行抽象和提炼。例如将每个业务事件中的类进行抽象，抽取出共性的部分，建立针对整个系统的全局领域模型。,需求分析目标（4）,（3）消除矛盾在分析过程中，显然可能会发现有些需求是相互矛盾的、冲突的，由于是将收集的信息放在一个预先定义的结构中发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也能够知道它影响那些层面。寻找相应的人员，通过进一步需求获取来消除矛盾。,（4）建立分析模型通过软件建模，帮助我们按照实际情况或按照我们需要的模式对系统进行可视化，提供一种详细说明系统的结构或者行为的方法，给出一个指导系统构造的模板。对所有做出的决定实施文档化。,需求分析方法（1）,1、结构化分析方法（SA）：采用自顶向下、逐层分解的分析方法来定义系统的需求。以数据和功能为中心。,需求分析方法（2）,2、面向对象分析方法（OOA）：利用面向对象的概念和方法为软件需求建造模型。以对象为中心。,需求分析方法（3）,3、功能分解法：将系统看做若干功能模块的集合，每个功能又可以分解为子功能，子功能还可继续分解，分解的结果即是系统的雏形。,2,软件需求开发,2.1需求获取2.2需求分析2.3需求规格说明2.4需求验证,需求规格说明书概述,需求获取收集了需求信息，需求分析深入理解了需求信息并建立了能够满足用户需求的解决方案。需求规格说明则是将需求获取、需求分析的结果进行文档化的过程。在软件开发过程中，将分析的结果文档化是不可或缺的任务，也称为编写规约活动。需求规格说明书的完成（撰写完成、验证完成）标志着软件需求阶段告一段落。并将作为下一个阶段设（计开发阶段）的输入和重要依据。,需求规格说明书的作用,需求规格说明书文档可以成为各方人员之间有关软件系统的协议基准。需求规格说明书文档可以成为项目开发活动的一个重要依据。它可以成为软件估算和项目进度安排的基础，也可以成为开发人员判断设计、测试等工作