软件需求分析（北邮PPT课件）

软件工程模型与方法 Models&Methods of Software Engineering第四章 软件需求分析修佳鹏 2009 BUPT TSEG软件工程模型与方法 Models&Methods o2本章内容本章内容u4.1 什么是软件的需求u4.2 软件需求分析的目标和任务u4.3 软件需求分析建模的原则和方法u4.4 软件需求工程u4.5 软件需求分析过程 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心本章内容4.1 什么是软件的需求 2009 BUPT TS3本章目标本章目标u为何要进行软件的需求分析？u软件的需求分析处于软件生命周期的那个阶段？起到什么作用？u怎样才能做好软件需求分析？u软件需求分析的过程和步骤是什么？u软件需求分析的最终结果是什么？2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心本章目标为何要进行软件的需求分析？2009 BUPT T44.1 什么是软件的需求什么是软件的需求u4.1.1 需求的定义u4.1.2 需求分析失败案例 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.1 什么是软件的需求4.1.1 需求的定义 2009 54.1.1 需求的定义需求的定义u需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。uBoehm 给出软件需求的定义：研究一种无二义性的表达工具，它能为用户和软件人员双方都接受，并能够把“需求”严格地、形式地表达出来。u“需求、设计、编程、测试四者究竟哪个环节最重要？”首先，每个环节都是很重要，任何一个环节出现问题，都会导致软件的质量问题。但是，从风险管理的角度来看，需求是软件产品的起源，因而是最重要的一个环节。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.1.1 需求的定义需求来源于用户的一些“需要”，这些“需64.1.2 需求分析失败案例需求分析失败案例u某大型的电信设备供应商，案例中涉及6个部门A,B,C,D,E和F，它们之间的关系如下图所示：F客客户户E：网管软件承包商：网管软件承包商D销销售售机机构构A：增值业务研发机构：增值业务研发机构C：项目管理机构：项目管理机构B：核心平台研发机构：核心平台研发机构一年前，B研制了一种数据接入服务器的原型。B对A讲：“我们的接入服务器前途很好，请你们帮助开发网管软件（属于增值业务范畴），大家合作把产品做好，一起发财。”D对B和A讲：“你们把接入服务器和网管软件做好，我们负责卖，挣了钱大家一起分。”2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.1.2 需求分析失败案例某大型的电信设备供应商，案例中涉74.1.2 需求分析失败案例需求分析失败案例uA觉得机会难得，于是向C申请立项。u立项后，A把项目外包给专业做网管软件的公司E，期望半年内完成。u由于接入服务器是B的，于是A和E就派开发人员到B处搞需求分析。uB的接入服务器并不成熟，老在变，三方折腾了好久，最终E用了一年时间把接入服务器的网管软件做出来了。uE把网管软件交付给A，A付清了E的开发费用，再把网管软件交付给D，D再卖给客户F（某地电信局）。uF对D讲：“你们的网管软件不是我们想要的东西，等你们把软件改好后我们再付钱。”uD赶紧对A讲：“兄弟阿，货已经出手了，但是不对路，请赶紧把它改好，不然大家都没钱赚。”uA很愤怒，怨天不公：“我们辛苦了一年，又花了很多钱，可是产品做完了却没人要，岂有此理！”2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.1.2 需求分析失败案例A觉得机会难得，于是向C申请立项84.1.2 需求分析失败案例需求分析失败案例u祸不单行的是，C来找A的麻烦：“你们的项目延期半年多了，经费也用光了，请尽快结束项目。”uA的那位项目经理为此每天愁眉苦脸，他的上司请来几位参谋商量对策，设法把事情搞定。u大家挖空心思只想出一个馊主意：既然套子是B下的，那么就把套子还给B。要设法把“那么好”的网管产品转让给B，只要B能给我们成本费，以后就跟B拜拜。u这个案例的问题根源在于进行软件开发之前没有搞清楚网管软件的需求，这都是B,A,E闭门造车惹的祸。u最可悲的是，相关责任人关心的是如何把事情“完成”，而不是深刻了解用户的具体需求。u这种类似的事情在软件开发行业中经常发生而且还会继续发生，最主要的是每发生一次就损失大量的人力和物力。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.1.2 需求分析失败案例祸不单行的是，C来找A的麻烦：“94.2 软件需求分析的目标和任务软件需求分析的目标和任务u需求分析是一项必须的软件工程活动。它在系统需求分析和软件设计之间起到桥梁的作用：它使得软件开发人员在系统分析的基础上深入描述软件的功能和性能、指明软件和其他系统元素的接口，建立软件必须满足的约束条件。它允许软件开发人员对关键问题进行细化，并构建相应的分析模型：数据、功能和行为模型。分析模型成为设计模型的基础，需求规格说明书也为软件测试人员和用户提供了软件质量评估的依据。它能准确表达用户对系统的各项要求。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.2 软件需求分析的目标和任务需求分析是一项必须的软件工程104.2 软件需求分析的目标和任务软件需求分析的目标和任务u软件需求分析的对象是用户要求。u其任务是要准确地定义新系统的目标。回答系统必须“做什么”的问题并编制需求规格说明书。u作为目标系统的参考，需求分析的任务就是借助于（业务）系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。软件开发的目标需求分析的目标 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.2 软件需求分析的目标和任务软件需求分析的对象是用户要求114.2 软件需求分析的目标和任务软件需求分析的目标和任务u（1）获得当前系统的物理模型：分析、理解当前系统（人工处理或原计算机系统）是如何运行的，了解其组织机构、输入输出、资源利用情况和日常数据处理过程。u（2）抽象出当前系统的逻辑模型：在理解当前系统“怎样做”的基础上，抽取其“做什么”的本质。u（3）建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，明确目标系统到底要“做什么”，进而从当前系统的逻辑模型导出目标系统的逻辑模型。u（4）对逻辑模型的补充：包括说明目标系统的用户界面、系统细节和性能限制等。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.2 软件需求分析的目标和任务（1）获得当前系统的物理模型124.3 需求分析建模的原则和方法需求分析建模的原则和方法u4.3.1 数据建模u4.3.2 功能和行为建模u4.3.3 问题划分 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.3 需求分析建模的原则和方法4.3.1 数据建模 2013需求分析的三元模型需求分析的三元模型u需求分析方法的一组操作性原则是：1.问题的信息域必须被表示和理解。2.软件将完成的功能必须被定义。3.软件的行为（作为外部事件的结果）必须被表示。4.描述信息、功能和行为的模型必须被划分，使得可以用层次的方式揭示细节。5.分析过程应该遵从自顶向下，逐层细化的原则。u需求分析的三元模型：数据模型第1条原则功能模型第2条原则行为模型第3条原则 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心需求分析的三元模型需求分析方法的一组操作性原则是：20014需求工程的指导性原则需求工程的指导性原则 u首先要正确地理解问题，再建立分析模型。u记录每个需求的起源及原因，保证需求的可回溯性。u开发一个能使用户能够了解人机交互过程的原型。因为对软件质量的感觉经常基于对界面“友好性”的感觉。u使用多个需求视图。建立数据模型、功能模型和行为模型，为软件工程师提供三种不同的视图，增加识别不一致性的基础。u给需求赋予优先级。紧张的开发时间要求尽量避免一次性实现每个软件需求，应采用迭代增量的开发模型。u努力删除歧义性。因为大多数需求以自然语言描述，存在歧义性的可能性，正式的技术评审是发现并删除歧义性的一种有效方法。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心需求工程的指导性原则 首先要正确地理解问题，再建立分析模型。154.3.1 数据建模数据建模u信息域包含三个不同的数据和控制视图：信息内容和关系；信息流；信息结构。信息流表示了数据和控制在系统中流动时变化的方式 信息内容表示了个体数据和控制对象；数据和控制对象可和其他的数据和控制对象关联 信息结构表示了各种数据和控制项的内部组织 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.3.1 数据建模信息域包含三个不同的数据和控制视图：信息164.3.2 功能和行为建模功能和行为建模u功能模型：功能模型：对进入软件的信息和数据进行变换和处理的模块，它必须至少完成三个常见功能：输入、处理和输出。u行为模型：行为模型：大多数软件对来自外界的事件做出反应，这种刺激反应特征形成了行为模型的基础。行为模型创建了软件状态的表示，以及导致软件状态变化的事件的表示。u功能模型和行为模型的作用如下：模型能够帮助软件开发人员快速准确的理解系统所涉及的信息、功能和动态行为；模型可成为后期软件设计的基础，为软件设计人员提供了设计软件功能的视图化表示；模型能够成为软件测试和软件评审的重要依据 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.3.2 功能和行为建模功能模型：对进入软件的信息和数据进174.3.3 问题划分问题划分u需求问题域涉及面广泛而且复杂，以至于难以进行整体理解。为此，需要将这样的问题划分为易于理解的子问题，并建立各子问题间的关系以使得可以完成整个功能。u软件的信息、功能和行为域可以被划分。u在本质上，划分将问题分解为其构成成分。在概念上，建立信息或功能的层次结构表示，通过进行自顶向下的分析，进而暴露更多的细节问题，并在各层次上进行各功能元素的分配。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.3.3 问题划分需求问题域涉及面广泛而且复杂，以至于难以184.4 软件需求工程软件需求工程u软件的需求分析是一系列复杂的软件工程活动，为了便于对需求进行更好的管理，人们把所有与需求直接相关的活动通称为需求工程。需求工程需求工程需求开发需求开发需求变更控制需求变更控制需求管理需求管理需求确认需求确认需求跟踪需求跟踪需求获取需求获取需求分析需求分析需求定义需求定义用户需求说明书软件需求规格说明书需求跟踪矩阵 需求评审报告 需求变更控制报告 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.4 软件需求工程软件的需求分析是一系列复杂的软件工程活动194.5 软件需求分析过程软件需求分析过程u4.5.1 软件需求获取的对象及注意事项u4.5.2 需求获取u4.5.3 需求类别u4.5.4 需求分析与综合u4.5.5 需求建模u4.5.6 编制需求分析文档u4.5.7 需求确认u4.5.8 需求分析评审 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5 软件需求分析过程4.5.1 软件需求获取的对象及注意204.5.1 软件需求获取的对象及注软件需求获取的对象及注意事项意事项u需求获取的对象：用户u“用户”（user）是一种泛称，它可细分为：“客户”（Customer）：掏钱买软件的用户“最终用户”（End user）：真正操作软件的用户“间接用户”（或称为关系人）如果软件是面向企业用户的，那么客户与最终用户通常不是同一个人。如果软件是面向个人用户的，那么客户与最终用户通常是同一个人。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5.1 软件需求获取的对象及注意事项需求获取的对象：用户21软件需求获取的注意事项软件需求获取的注意事项u用户无法清晰地表达需求本身不清楚要做什么知道做什么却表达不准确需求分析员的职责就是设法搞清楚用户真正的需求。u双方或多方对需求的理解往往存在歧义u需求会经常发生变化：避免由于沟通不充分而发生的变更；欢迎因环境变化造成的变更；需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心软件需求获取的注意事项用户无法清晰地表达需求 2009 B224.5.2 需求获取需求获取目的目的获取用户（客户与最终用户）的需求信息，经过分析后产生用户需求说获取用户（客户与最终用户）的需求信息，经过分析后产生用户需求说明书。明书。角色与职责角色与职责需求分析员调查、分析用户的需求，客户与最终用户提供必要的需求信息。需求分析员调查、分析用户的需求，客户与最终用户提供必要的需求信息。启动准则启动准则需求分析员已经确定需求分析员已经确定输入输入任何与用户需求相关的材料任何与用户需求相关的材料主要步骤主要步骤第一步：准备调查第一步：准备调查第二步：调查与记录第二步：调查与记录第三步：分析需求信息第三步：分析需求信息第四步：撰写用户需求说明书第四步：撰写用户需求说明书第五步：需求确认第五步：需求确认输出输出用户需求说明书用户需求说明书结束准则结束准则需求分析员已经撰写完成用户需求说明书，确保无拼写、排版等错误。需求分析员已经撰写完成用户需求说明书，确保无拼写、排版等错误。并确保用户需求说明书的内容无二义性，且涵盖了所有的用户需求。并确保用户需求说明书的内容无二义性，且涵盖了所有的用户需求。度量度量需求分析员统计工作量和上述文档的规模，汇报给项目经理。需求分析员统计工作量和上述文档的规模，汇报给项目经理。u需求获取流程：2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5.2 需求获取目的获取用户（客户与最终用户）的需求信息23需求获取的准备工作需求获取的准备工作u需求获取的准备工作围绕三项展开：调查什么？通过什么方式去调查？“何人”在“何时”调查？u首先，应起草需求调查问题表，将重点锁定在该问题表内，否则调查工作将变得漫无边际。u其次，应当确定需求调查的方式，比如：与用户交谈，向用户提问题。参观用户的工作流程，观察用户的操作。向用户群体发调查问卷。与同行、专家交谈，听取他们的意见。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心需求获取的准备工作需求获取的准备工作围绕三项展开：20024需求获取的记录需求获取的记录u准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息，建议采用表格的形式，如下图：需求标题需求标题1 1调查方式调查方式调查人调查人调查对象调查对象时间、地点时间、地点需求信息记需求信息记录录基本要素如基本要素如“是什么是什么”、“为什么为什么”等等 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心需求获取的记录准备工作完毕后，需求分析员按照计划执行调查。在25需求获取注意事项需求获取注意事项u如果与用户约好了时间，切勿迟到或早退。要注意礼节，尽可能获得用户的好感，并为下次打扰他们埋下伏笔。u需求分析员应事先了解用户的身份、背景，以便随机应变。u需求调查应该先了解宏观问题，再了解细节问题。u如果双方气氛融洽，可以采用灵活的访谈形式，轻易不要打断用户的谈话。当双方对某些问题的交流合乎逻辑地结束后，即可继续讨论问题表中的其它问题。u尽可能避免为用户添麻烦，但也不能怕给用户添麻烦而降低需求调查的力度。u避免片面地听取某些用户的需求而忽视其它用户的需求。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心需求获取注意事项如果与用户约好了时间，切勿迟到或早退。要注意26撰写用户需求说明书撰写用户需求说明书u对收集到的所有需求信息进行分析，消除错误，归纳与总结共性的用户需求。u按照规定的文档模板撰写用户需求说明书，调查过程中获取的需求信息可以作为用户需求说明书的附件。u之后应当邀请同行专家和用户一起评审用户需求说明书，尽最大努力使用户需求说明书能够正确无误地反映用户的真实意愿。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心撰写用户需求说明书对收集到的所有需求信息进行分析，消除错误，27用户需求说明书与用户需求说明书与软件需求规格说明书的区别软件需求规格说明书的区别u前者主要采用自然语言来表达用户需求，其内容相对于后者而言比较粗略，不够详细。u后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，软件需求是软件系统设计的直接依据。u两者之间可能并不存在一一映射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整软件需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据软件需求规格说明书来开发当前产品。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心用户需求说明书与软件需求规格说明书的区别前者主要采用自然语284.5.3 需求类别需求类别u功能需求功能需求：列举出所开发软件在功能上应做什么，这是最主要的需求。u性能需求性能需求：给出所开发软件的技术性能指标，尤其是系统的实时性和其他时间要求，如响应时间、处理时间、消息传送时间等；资源配置要求，精确度，数据处理量等要求。u环境需求环境需求：是对软件系统运行时所处环境的要求。在硬件方面，采用什么机型、有什么外部设备、数据通信接口等等。在软件方面，采用什么支持系统运行的系统软件（指操作系统、网络软件、数据库管理系统等）。在使用方面，需要使用部门在制度上、操作人员的技术水平上应具备什么样的条件等等。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5.3 需求类别功能需求：列举出所开发软件在功能上应做什294.5.3 需求类别需求类别u可靠性需求：指软件的有效性和数据完整性。各种软件在运行时失效的影响各不相同。在需求分析时，应对所开发软件在投入运行后不发生故障的概率，按实际的运行环境提出要求。u安全保密要求：工作在不同环境的软件对其安全、保密的要求显然是不同的，应当把这方面的需求恰当地做出规定。u用户界面需求：软件与用户界面的友好性是用户能够方便有效愉快地使用该软件的关键之一。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5.3 需求类别可靠性需求：指软件的有效性和数据完整性。304.5.3 需求类别需求类别u资源使用需求资源使用需求：指所开发软件运行时所需的数据、软件、内存空间等各项资源，以及软件开发时所需的人力、支撑软件、开发设备等。u软件成本消耗与开发进度需求软件成本消耗与开发进度需求：在软件项目立项后，要根据合同规定，对软件开发的进度和各步骤的费用提出要求，作为开发管理的依据。u预先估计以后系统可能达到的目标：预先估计以后系统可能达到的目标：在开发过程中，可对系统将来可能的扩充与修改做准备。一旦需要时，就比较容易进行补充和修改。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5.3 需求类别资源使用需求：指所开发软件运行时所需的数31非功能性需求列表非功能性需求列表目标系统的限制性能实时性其他的时间限制资源利用，特别是硬件配置选型精确度、质量要求可靠性有效性完整性安全/保密性安全性保密性运行限制使用频度、运行期限控制方式（本地还是远程）对使用者的要求物理限制系统的规模等限制开发和维护的限制开发类型（实用型开发或试验型开发）开发工作量估计；在采用具有试验型的渐进开发方法时，对资源、开发时间及交付的安排开发方法质量控制标准里程碑和评审验收标准优先性和可维修性可维护性 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心非功能性需求列表目标系统的限制性能实时性其他的时间限制资源利324.5.4 需求分析与综合需求分析与综合u需求获取之后就需要对比较复杂的需求进行建模分析，进而逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，分析它们是否满足功能要求，是否合理。u依据功能需求，性能需求，运行环境需求等，剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。u分析和综合工作需要反复地进行，其过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的需求规格说明为止。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5.4 需求分析与综合需求获取之后就需要对比较复杂的需求334.5.4 需求分析与综合需求分析与综合u需求分析的流程：目的定义准确无误的软件产品需求，产生软件需求规格说明书。角色与职责需求分析员定义软件需求。客户与最终用户确认软件需求。启动准则用户需求说明书已经撰写完成。输入用户需求说明书主要步骤第一步：细化并分析用户需求第二步：撰写软件需求规格说明书第三步：软件需求确认输出软件需求规格说明书结束准则软件需求规格说明书已经撰写完成。开发方和客户方已经对产品需求进行了确认。度量需求分析员统计工作量和上述文档的规模，汇报给项目经理。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5.4 需求分析与综合需求分析的流程：目的定义准确无误的344.5.5 需求建模需求建模u软件开发人员还需要构造系统的分析模型，着重于描述系统必须做什么、而不是如何去做系统。u给出系统的逻辑视图，以及系统的物理视图。逻辑模型给出软件要达到的功能和处理数据之间的关系，而不是实现的细节。物理模型给出处理功能和数据结构的实际表示形式，这往往是由设备决定的。u常用的建模分析方法有：面向数据流的结构化分析方法（简称SA）面向数据结构的Jackson方法（简称JSD）面向对象的分析方法（简称OOA）等以及用于建立动态模型的状态迁移图或Petri网等 2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5.5 需求建模软件开发人员还需要构造系统的分析模型，着354.5.6 编制需求分析文档编制需求分析文档u把描述需求的文档称为软件需求规格说明书。u为了确切表达用户对软件的输入输出要求，还需制定数据词典及初步的用户手册，反映软件的用户界面和用户使用的具体要求。从现实中分离功能，即描述要“做什么”而不是“怎样实现”；要求使用面向处理的规格说明语言，从而得到“做什么”的规格说明。如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中；规格说明必须包括系统运行环境，等；2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5.6 编制需求分析文档把描述需求的文档称为软件需求规格36软件需求规格说明书的特点软件需求规格说明书的特点u正确性：不仅要正确书写，最主要的是正确地表达用户的需求。u清晰性：需求地表达是否清晰易懂？文档的结构、段落是否乱七八糟？上下文是否不连贯？文档的语句是否含糊其词、啰里啰唆？看了半天是否还不明白需求究竟是什么？u无二义性：需求的表达内容只有唯一的含义。u一致性：在上下中，需求之间不存在矛盾。u必要性：所需表达的内容一定是必须的，注意避免“画蛇添足”u完备性：需求所对应的功能是完整的，不能缺少某个部分。u可实现：所列举的需求，在技术上一定是可实现的。u可验证：所列需求在进行软件验收时，要被用户所理解和测试。u确定优先级：根据项目计划制定需求实现的先后次序。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心软件需求规格说明书的特点正确性：不仅要正确书写，最主要的是正374.5.7 需求确认需求确认u需求确认是指开发方和客户方共同对需求文档用户需求说明书和软件需求规格说明书进行评审，对需求达成共识后作出承诺。目的目的开发方和客户对需求文档进行评审，并作书面承诺。开发方和客户对需求文档进行评审，并作书面承诺。角色与职责角色与职责开发方和客户共同组织人员对需求文档进行评审。双方负责人对需求文档作书面承开发方和客户共同组织人员对需求文档进行评审。双方负责人对需求文档作书面承诺，使之具有商业合同效果。诺，使之具有商业合同效果。启动准则启动准则需求文档如用户需求说明书和软件需求规格说明书已经完成。需求文档如用户需求说明书和软件需求规格说明书已经完成。输入输入需求文档如用户需求说明书和软件需求规格说明书需求文档如用户需求说明书和软件需求规格说明书主要步骤主要步骤第一步：非正式需求评审第一步：非正式需求评审第二步：正式需求评审第二步：正式需求评审第三步：获取需求承诺第三步：获取需求承诺输出输出需求评审报告和书面的需求承诺需求评审报告和书面的需求承诺结束准则结束准则需求文档通过了正式评审，并且获得开发方和客户的书面承诺。需求文档通过了正式评审，并且获得开发方和客户的书面承诺。度量度量项目经理统计工作量和上述文档的规模。项目经理统计工作量和上述文档的规模。2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5.7 需求确认需求确认是指开发方和客户方共同对需求文档384.5.8 需求分析评审需求分析评审u在需求分析的最后一步，应对功能的正确性、完整性和清晰性，以及其他需求给予评价。主要内容是：系统定义的目标是否与用户的要求一致；文档资料是否齐全，内容是否完整、清晰、准确？与所有其他系统成分的重要接口是否都已经描述；所开发项目的数据流与数据结构是否足够，确定；所有图表是否清楚，在不补充说明时能否理解；系统的约束条件或限制条件是否符合实际；是否考虑过软件需求的其他方案；是否考虑过将来可能会提出的软件需求；是否详细制定了检验标准？软件开发计划中的估算是否受到了影响？2009 BUPT TSEG 北京邮电大学北京邮电大学 通信软件工程中心通信软件工程中心4.5.8 需求分析评审在需求分析的最后一步，应对功能的正确