实用软件工程(第2版)第4章[赵池龙].ppt

实用软件工程,-IT企业软件的开发与管理 赵池龙,第4章 软件需求,本章导读 软件工程的两大难点： 一是软件需求 二是项目管理。 软件需求，又称软件需求分析或软件需求获取，它既是软件开发中的老问题（几十年都没有很好地彻底解决），又包含着许多新思路和新内容。需求获取是否彻底与成功，直接关系到软件开发的成败。,本章导读,本章论述： 1. 需求分析的重要性 2. 需求分析的理论基础 3. 需求分析的任务、目的、方法和分类 4. 需求的各种描述工具 5. 需求的管理过程 6. IT企业用户需求报告和需求规格说明书的编写参考指南。,本章对读者的要求,了解： (1）需求分析的输入输出 (2）需求获取的难点 (3）需求报告和需求规格说明书的差异 (4）评审与审计的概念，同行评审的概念 (5）不符合项的概念 (6）用户、顾客、客户的概念 (7）基线、里程碑、评审点、软件产品、软件工作产品的概念,本章对读者的要求,理解： (1）需求分析的目的 (2) 需求分析的重要性 (3) 需求分析的理论基础 (4) 需求的各种描述工具 (5）需求管理方法与管理文档,本章对读者的要求,掌握： (1）需求分析的任务：组织结构图，业务操作流程图，数据流程图，列出功能性能接口列表、确定运行环境和界面约定，确定工期、费用、进度、风险 (2）需求分析方法：面向流程分析，找出元数据，找出中间数据，找出元数据与中间数据的关系，学会需求分析艺术 (3）用户需求报告的内容与编写方法 (4）需求规格说明书的内容与编写方法,4.1 需求分析的重要性,输入：合同/立项建议书/现场调研。 输出：用户需求报告/需求规格说明书。 1. 需求分析为什么重要？ （1）许多大型应用系统的失败，最后均归结到需求分析：要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。,需求分析为什么重要？,（2）需求分析的输出文档是用户需求报告，它是客户、软件开发人员和项目管理人员三者必须遵守的一根基线，三者共同工作的基础，是测试的准则。 （3）需求分析要占用整个软件开发时间或工作量的30%左右。 （4）需求获取中的错误，属于软件开发中的早期错误，它会在后续的设计和实现中进行发散式的传播。 根据以上四项原因，IT企业的高层经理，对需求分析特别重视，常常派经验最丰富的人员去作项目需求。正因为如此，“系统分析员”才是软件行业中的最高技术职称。,2. 需求获取为什么难？,需求获取看似容易，做起来难，主要原因有四： （1）用户需求具有动态性，即需求的不稳定性。在整个软件生存周期内，应用软件的需求会随着时间的进展而有所变化。个别用户，甚至是朝三暮四地变化。 （2）用户需求具有模糊性，即需求不准确性。由于用户的素质不是很高，业务流程不很规范，所以需求表达不很清楚也不够明确。,2. 需求获取为什么难？,（3）开发者和用户要对需求达成完全一致的认识，用户要在需求报告上签字，要承担责任。 （4）中国的国有企业正处在变动期（体制改革与企业重组），中国的民营企业正处在成长期（发展壮大与不完全成熟）。这就给信息系统的需求分析，无疑增加了难度系数。 想想看，这四条原因，哪一条都非同小可？,4.2 需求分析的理论基础,1. 什么是软件需求 软件需求就是为了解决现实世界中的特定问题必须展现的属性。这里的问题可能是用户的任务自动化，或由软件来完成一个组织的业务处理，或控制一个设备等等。需求属性主要有： (1) 可验证性 可验证性是软件需要的基本属性。软件需求必须是可验证的，否则软件的评审和测试就没有相应的依据。但在某些情况下，很难对某些软件需求进行验证或需要的代价很高。软件需求人员和测试人员应以合理的代价实现需求的验证。,什么是软件需求,(2) 优先级 软件需求应具有优先级，可以在有限的资源情况下进行取舍。 (3) 唯一性 软件需求应唯一地标识出来，以便在软件配置管理和整个软件生命周期中进行管理。,2. 软件需求需要量化,软件需求应尽可能地表述清楚，没有二义性，尽可能量化，使得需求是可测试、可验证的。应避免含糊地、无法测试、无法验证的需求出现。软件质量的可靠性和用户界面的友好性，这些非功能性需求的量化尤为重要。 例如，系统应支持1000并发用户，系统影响时间应低于10毫秒，这就是需求的量化。软件需求的可靠性将直接影响系统的架构。,3. 需求是一个过程,需求过程不仅表现在一个软件生命周期的早期活动之中，而且应体现在整个生命周期过程中。 需求过程要适应客户和项目的环境，并作为配置项纳入配置管理。 需求过程描述了在不同项目和限制条件下，如何提取、分析、文档化以及验证软件需要。P68 图4-2描述了软件的需求过程。,4. 需求过程中的角色,5. 需求来源,(1) 系统目的 指软件的整体目的，或高层的目标。这是进行软件开发的动机，但它们通常表达比较模糊。软件分析师需要仔细地评估这些目标的价值以及成本。应对系统的整体目标进行可行性研究。 (2) 行业知识 软件分析师需要获取业务领域内的相关知识。当需要发生矛盾时，软件分析师可以利用行业知识对各种需求进行权衡。,需求来源,(3) 软件涉众 应充分考虑不同软件涉众的需求，如果只强调某一角色的需求，忽略其它角色的需求，往往将导致软件系统的失败。软件分析师应从不同涉众的角度去识别、表述他们需求。 (4) 运行环境 软件的运行环境包括地域限制，实时性要求和网络性能等。可行性和软件架构都依赖这些环境需求。 (5) 组织环境 软件作为一个组织的业务流程支持工具，受到组织结构、企业文化和内部政策的影响。,4.3 需求分析的任务,在实现生活中，确实存在多种软件，确实有多种软件需求。但是，由于信息系统这种软件应用面最广，市场最大，客户最多，需求分析最难，所以人们一谈需求分析，就自然而然地认为指“信息系统需求分析”。 需求分析是分行业的，成功的需求分析专家，都是某行业领域内的行业产品专家。 一般而言，对于信息系统的需求分析，最主要的是完成9项任务(以图书馆为例) 。,需求分析的任务 第1：画出目标系统的组织结构图与列出各部门的岗位角色表(组织机构模型),图书馆的岗位角色,第2：画出目标系统的业务操作流程图 (业务操作模型),画出目标系统的业务操作流程图，它包括物流、资金流、信息流，即业务操作模型，重点是业务操作的流水步骤。业务模型是经过业务流程重组、再造和优化之后，并且得到企业领导确认的业务流程图。 业务流程图的画法多种多样，各软件组织可根据自身的习惯和特点，制定一套图形规则，在本组织内统一遵守。业务流程图的制作工具，可以是微软的Word , Visio。 请读者定义一套图形规则，并画出“图书馆信息系统”的业务流程图。,第3：画出目标系统的数据流程图(数据模型),画出目标系统的数据流图，即单据和报表的流图，掌握业务规则，获得初步数据模型（真正的数据模型是E -R图加上相应的数据字典）。 数据流图中要突出单据流，分清不同单据之间的先后流动次序，以及同一单据中的不同数据项的先后流动次序。,第3：画出目标系统的数据流程图(数据模型),数据流图的画法多种多样，各软件组织可根据自身的习惯和特点，制定一套图形规则，在本组织内统一遵守。数据流图的制作工具，可以是微软的桌面办公工具Office，也可以是Power Designer中的数据流图绘制工具Process Analyst。 例如，可以规定用矩形表示数据的起始点或终止点（数据源或数据潭），用圆圈表示对数据的加工处理，用箭头表示数据的流向，用两条横线表示单据或报表等文件 。,单据或报表分为头和体两部分，下面是头,单据或报表分为头和体两部分，下面是体,第4：列出目标系统的功能点列表(功能模型),列出目标系统的功能点列表，即功能模型。（注：有时将性能模型、界面模型和接口模型的内容都合并到功能模型之中。）功能模型也可以用Use Case图表示，也可以用功能点列表描述。 “图书馆信息系统”的功能点列表，如P72表4-7所示。其中“系统响应”这一项，表示将来的目标系统所要做的工作。需要指出，功能列表不是唯一，也没有标准答案。,第5：列出系统的性能点列表(P74 性能模型),第6：列出目标系统的接口列表(P74 接口模型),第7：确定目标系统的运行环境(环境模型),运行环境包括：核心计算机及网络资源(系统软件、硬件和初始化数据)的配置计划、采购计划、安装调试进度、人员培训计划等内容。,第8：目标系统的界面约定(界面模型),界面设计的原则是：方便、简洁、美观、一致等。整个目标系统的界面风格定义要统一，某些功能模块的特殊界面要说明。例如： 输入设备：键盘、鼠标、条码扫描器、扫描仪等； 输出设备：显示器、打印机、光盘刻录机、磁带机、音箱等； 显示风格：图形界面、字符界面、IE界面等； 显示方式：1024*768、640*480等； 输出格式：显示布局、打印格式等。,第9：对目标系统的开发工期、费用、开发进度、系统风险等问题进行分析与评估,注1：上述九项任务不是教条，不能完全生搬硬套，而要具体问题具体分析，活学活用，举一反三。 注2：通过需求分析之后，对将来要实现的目标系统，如果仍然感到心中无数、心里发慌、腰杆不硬，那么绝对不要签字确认，而要从头开始，重新进行需求获取。,4.4 需求分析的目的,在技术上，需求分析的目的，就是用于说明软件产品或软件项目需要满足的条件和限制。 为此，在软件工程项目中，首先要获取用户的需求，通过对软件需要的提取、分析、文档化以及验证，为进一步的设计和实现提供依据。 需求分析就是对提取的需求进行分析整理：,对提取的需求进行分析整理：,(1) 需求分类，将相关需求组织成一个子集。 (2) 检查需求是否准确，是否存在二义性。 (3) 检查和解决不同需求间的冲突。 (4) 分析软件的边界与范围。 (5) 从系统需求中推导软件需求。 需求过程不仅仅是一个项目的开始，它将贯穿软件的整个 命周期，将需求纳入配置管理。,需求分析的目的,需求分析的重点：通过弄清业务流程和数据流程的手段，达到与客户共同确定业务模型、功能模型、性能模型、接口模型的目标。 需求分析的难点：在系统的流程、功能、性能和接口四个方面，开发者与客户达成完全一致，并且要求客户签字确认。需求分析在商务上的目的。 需求分析的变更：万一需求有点变化，双方必须履行“需求变更管理程序”，而变更管理程序在签订合同时已经作了规定。要知道，合同是具有法律效果的。,4.5 需求分析方法,前人需求分析的经验是： a. 系统分析师应对用户进行需求分析培训 b. 用户应参加业务需求分析的全过程 c. 向用户发放需求调查表格 d. 召开需求调研会 e. 深入到重点岗位了解需求 f. 必要时参加实际的业务工作 g. 边分析边整理文档，边征求修改意见 h. 定期向操作层、管理层、决策层分别汇报，演示目标系统的流程、功能、性能、接口及界面的需求,需求分析的具体方法,1. 面向流程分析 需求分析是面向流程的。流程是动态的、实时的。系统的功能、性能、接口、界面都是在流程中动态实时地反映出来。 2. 找出元数据 元数据是组织数据的数据，元数据就是信息系统中实体名及其属性名的集合。,【例4-1】在人力资源系统中，“员工的基本情况”是一个实体名，而员工的“编号、姓名、性别、年龄、学历、住址、电话、电子信箱、业务特长”等则是属性名，这些名词统称为人事系统的元数据。 而某一员工的具体信息，“8008，张开，男，30岁，大学本科，北京王麻子胡同东一条8号，66268866，，软件开发”，则是被上述元数据所组织好的一条记录（该实体的一个实例），称为人事系统中的基础数据。需求分析的技巧之一，是分析与识别元数据，而不是基础数据。,【例4-2】 商品出库单，它是一个实体，单据中的数据项“品名，型号，规格，单价，数量，产地，出厂日期，出库日期，制单人，审核人，批准人”，就是该实体的属性名，它们都是元数据。 而“海尔电视机，HE2000，29英寸，2500，100，青岛，2002/09/26，2002/10/12，张三，李四，王老五”，就不是元数据，只是由元数据所组织好的一条记录（该实体的一个实例）。,3. 找出中间数据 中间数据蕴藏在信息系统的输出报表中，报表名称及其内部的数据项名称，一般就是中间数据。 【例4-3】 人力资源系统中有一张统计报表，表中的第一行中数据就是中间数据，第二行开始，就不是中间数据，而是统计记录数据。,4. 找出元数据与中间数据之间的关系 a. 元数据对应原始单据 b. 中间数据对应查询、统计、报表 c. 元数据将原始单据中录入的数据组织起来，变成基表中的记录，这些记录称为基础数据 d. 中间数据将统计报表中输出的数据组织起来，变成中间表中的记录，这些记录称为统计数据 e.“中间数据是由元数据派生出来的”，这种派生就是算法分析，也叫数据处理。,5. 找出单据中的流程 (1) 该单据的上游是什么？ (2) 同一个单据内部的数据项之间，也存在一个先后次序问题。 (3) 该单据的下游是什么？,【例4-4】 在人力资源系统中，“个人简历”和“员工基本情况”都是一个单据（实体），“个人简历”的上游就是“员工基本情况”，只有先录入“员工基本情况”，“个人简历”才能录入。在信息系统中，一般都要先录入父表（主表）中的记录，然后再录入子表（又称明细表）中的记录。即先有父母，后有儿女。,【例4-5】 家电出库单中的数据项“制单人，审核人，批准人”之间的录入次序，也有一个先后问题。制单人必须第一个录入，审核人必须是第二个确认，批准人只能是第三个确认。而且企业的业务规则规定：只有批准人确认之后，该单据才能生效，电视机才能出库，信息系统才能向后台数据库服务器提交这条记录。否则，仓库中的家电早就丢光了。 这就是同一单据中不同数据项之间的先后次序问题。,6. 三种需求分析方法 历史上存在三种需求分析方法： 面向功能分析 面向对象分析 面向数据分析 各适用不同的目标系统。,7. 分析与设计要同时考虑 因为许多问题在分析“目标系统是什么”的时发现不了，到了设计时才暴露出来。 分析与设计同时考虑，也符合迭代模型的思想，即：复杂的需求是个需求迭代过程。 这就是有经验的分析员与无经验的分析员之间的差异。,8. 需求分析艺术 (1) 需求分析是双打项目。 (2) 宏观上和微观上都要以流程为主。 (3) 不能偏听偏信。 (4) 需求金字塔。决策层提出宏观上的统计、查询、决策需求，管理层提出业务管理和作业控制需求，操作层提出录入、修改、提交、处理、打印、界面、传输、通信、时间与速度等方面的操作需求。 (5) 汇报两三次，直到客户确认为止。 (6) 要与用户交朋友。,9. 提取需求技术 (1) 会谈 这是最常见的方式。为保证会议的效率和效果，应事先做好准备并做好会议记录。 (2) 场景 软件分析师为每个用户任务设计一个场景，以提问的方式提取需求。场景通常以用例图来表示。,(3) 原型 用户在原型系统中更容易表达自己的需求。原型技术有很多，从界面示意图到快速搭建的原型系统。 (4) 实地观察 软件分析师到实际的用户现场去，体验和观察用户的实际工作，了解用户如何利用软件和其它人协作完成某项任务。,10. 提取对象、属性和方法的技术 在面向对象的需求分析中，如何提取对象(准确说是对象集或类)呢？或者说， 对象在哪里？ 属性在哪里？ 方法在哪里？,10. 提取对象、属性和方法的技术,回答是：因为“对象”是“名词”，所以要到需求分析的重要名词集合中去发现有用的“对象”； 因为“属性”是“形容词或名词”，所以要到需求分析的主要形容词集合或次要名词集合中去发现对象的“属性”； 因为“方法”是“动词”，所以要到需求分析的主要动词中去发现“方法”。,11.实时系统需求分析法,数据流图DFD是结构化分析方法的主要表达工具。数据流图运用加工、文件、数据流线等图形来反映系统的逻辑功能及其内部的数据联系。 数据字典DD是对数据流图DFD的补充。用数据字典说明每个数据流的组成、每个数据文件的内容以及每个数据项的定义等。 实时系统的跟踪与控制，至今仍然采用面向过程的方法来实现，它包括面向过程的分析、设计、编程、测试、维护。,附：对多种数据字典的解释,信息系统中有如下四种数据字典： (1).数据流图中的数据字典：如上所说。 (2).数据库中的数据字典：就是数据库中的元数据，例如表名、字段名、索引名、主键名。 (3).数据库管理系统中的系统数据字典：它分为系统数据字典和用户数据字典两部分，用这些字典来管理数据库。 (4).信息系统用户初始化中的用户数据字典：就是一些科目代码、单位代码等等。,4.6 需求的分类,对软件需求进行分类，目的是决定如何对各种需求进行取舍。软件需求可以从不同的角度进行分类，例如： (1) 功能性需求与非功能性需求 a. 功能需求描述软件应完成的功能。例如记录借书情况，控制信号灯的显示等。 b. 非功能需求是对解决方案的限制和约束。如性能需求，可维护性需求，安全需求等。,需求的分类,(2) 产品需求与过程需求 产品需求指与软件产品相关的功能性能需求。 过程需求指对软件开发过程方面的需求，例如过程管理、文档形式、用户培训等。 (3) 根据需求的优先级进行分类 需求的优先级越高，重要性越。可以用：必须、最好具备、可选等词汇进行优先级分类。应根据开发成本和预算，来确定软件需求的优先级。,需求的分类,(4) 独立需求与全局需求 全局需求可能会影响到整个系统的架构或者很多部件的设计。而独立需求通常只影响一个或几个部件。 (5) 稳定的需求与可变的需求 稳定的需求，反映了问题域中的本质特征。 某些需求在软件的整个生命周期或开发过程中，是可变的(例如报表)，称为可变的需求。对可变需求可能的变化，进行充分的估计和预测，将有助于软件的开发和维护。,4.7 需求的描述工具,需求分析的一个重要工作，就是建立问题域的概念模型。 建立概念模型是为了帮助我们更好地理解问题域，而不是提供一个初始的解决方案。,4.7.1 描述工具概述,需求分析中的概念模型，是站在用户的立场上，开发者用一些软件工具，来表述用户对系统的功能、性能、接口和界面的需求。 这些工具包括用况图、数据流图、状态模型图、用户交互图、对象模型图、数据模型图和功能需求列表、性能需求列表、接口需求列表、界面需求列表等。 选择哪种软件工具，主要取决于问题域的本质特征。例如，对于实时系统，它对数据流图和状态模型图要求高。而对信息管理系统，它对数据模型图要求高。,4.7.2 实体联系模型,实体联系模型是用户对数据和加工的需求用实体联系模型（即E-R图）表达出来，明确描述应用系统的概念数据模型，为建立数据库设计打好基础。 对于较复杂的系统，通常要先画出单个用户的E-R分图或最主要的几个实体E-R图，最后得出总E-R图，并对总E-R图进行优化，如去掉冗余的属性和联系等，以得到整个应用系统的概念数据模型。,实体联系模型,需要指出的是：不同的软件分析师，对于同一个图书馆信息系统，所设计出来的E-R图，可能大同小异(并不存在唯一的标准答案)，也可能各不相同。 E-R模型既是表达用户需求的工具，又是数据库概念设计的工具。在需求分析中，它叫做实体联系模型，在数据库设计中，它叫做概念数据模型CDM。,4.7.3 数据流图,数据流图DFD的描述符号主要只有四种，即： a. 数据源或数据潭 b. 数据流动的连线 c. 数据加工或处理泡 d. 输入或输出文件 如P82表4-12所示 。,数据流图DFD,面向过程的分析方法也称结构化分析，采用“自顶向下，由外到内，逐层分解”的分析思想，即将一个复杂的系统逐层分解成许多简单的基本加工，当信息“流”过系统时，被系统加工变换。 先画出的顶层数据流图，再逐层画出的底层数据流图，具体地描述上层系统的细节。 不需再进一步分解的加工(处在叶子部位的加工)，都必须有一个加工说明。加工说明常常用结构化语言、判定树和判定表来描述。 由于数据流图及其数据字典DD，是需求分析中的早期工具，时至今天，除了在实时控制系统中还采用之外，其他领域就很少采用了。,4.7.4 用例图,在统一建模语言UML中，用例图又叫做用况图，有时又称为Use Case图。 它用于定义系统的行为、展示角色（系统的外部实体，即参入者）与用例（系统执行的服务）之间的相互作用。,*4.7.5 活动图,在统一建模语言UML中，活动图用于描述系统行为，在需求阶段，可以配合用例图说明复杂的交互过程。 活动图由开始点、活动、转换和结束点组成。一个活动图只能包含一个开始点，可以有多个结束点。开始点、活动、结束点之间通过转换连接。表4-14详细地说明了活动图的各种图例。,4.8 需求管理过程,1. 需求管理的任务与内容 需求管理的中心任务，是保证客户在软件功能、性能、接口三个方面的需求满足。 需求管理的目标，是维护软件计划、软件工作产品、软件活动与软件需求的一致性，并保证软件需求在软件项目中得到实现。,需求管理过程,按照“五个面向理论”，软件管理是面向过程的。需求管理是面向需求过程的，需求管理过程主要包括： 需求确认过程 需求评审过程 需求跟踪过程 需求变更过程 先确认、后评审、再跟踪、最后是处理变更。,需求管理过程,（1）非技术需求确认，一般在协议和合同条款中确认，包括提交的产品、提交的日期和里程碑等内容。 （2）技术需求确认，描述系统的软件功能、性能、接口、设计约束、编程语言和界面需求等多方面内容确认。 （3）需求评审。一般情况下，客户会参与项目需求评审。评审的对象是需求确认的结果，包括技术需求文档、非技术需求文档。 (4) 需求跟踪矩阵，使项目经理能够跟踪每一项需求的确认、评审、变更、设计、实现、测试、验收状态。,问题： 怎样构造需求跟踪矩阵？,回答： (1) 该矩阵的第一行(横座标)应该是：确认、评审、变更、设计、实现、测试、验收的状态； (2) 该矩阵的第一列(纵座标)应该是：需求功能1、需求功能2、需求功能3、需求功能n。,需求评审的目的,（1）确定软件功能、性能、接口需求，用软件来实现是可行的。 （2）软件功能、性能、接口需求是清晰的。 （3）软件功能、性能、接口需求是一致的(相互不矛盾)。 （4）软件功能、性能、接口需求是可测试的。 评审的结束，标志需求的结束。 通过高级管理者批准的需求文档，应置于软件基线库中，进行配置管理和控制，同时已批准的需求，作为软件项目策划的主要输入。,需求跟踪,需求跟踪的意义在于，获得需求目前的实现状态，确保用户所有的需求都得到满足。 需求跟踪的好处：为需求变更、系统维护、关键成员离开、类似系统设计等很多方面，提供参考和指导，并可以减少风险和提高项目成功。 需求跟踪用于追溯需求来源，需求应能向后追溯到它的发起人，向前追溯到实现它的部件和实体。 需求跟踪的一项重要内容，是跟踪不符合项的改正情况。,需求管理过程,2对需求文档进行评审 最常见的需求验证方式就是需求评审。邀请相关的评审人员阅读需求文档，找出其中的错误，不正确的假设，表达不清的地方，以及与标准不符的地方。评审成员应包括客户代表。 最好的评审方法是同行评审。最重要的是找出不符合项。,同行评审的内容,需求评审的内容包括： (1) 需求是否描述清楚，不存在歧义。 (2) 需求是否是可量化的，可验证的。 (3) 需求间是否存在冲突，以及它们之间的依赖关系。 (4) 非功能性需求是否明确、合理。 (4) 需求是否注明来源。 (5) 每个需求是否分配了唯一的标识。,需求管理过程,3对需求进行测试 在评审之前应对需求进行测试，并将测试结果通作为需求评审的输入文档之一。 对软件需求的一个基本要求，就是需求的可验证性，而需求测试，就是需求验证的最好方法。 要考虑如何对每个需求进行验证。接受测试可以完成这个工作。,4.9 需求分析文档,如果系统中包含软件和非软件的部分，如数控系统，移动电话，那么应建立独立的系统需求规格说明书。 软件需求规格说明书应以系统需求规格说明书以基础进行编写，描述软件部分的需求。 通常由系统工程师编写系统需求规格说明书，由软件工程师编写软件需求规格说明书。,4.9.1 需求报告和需求规格说明书的差异,(1)用户需求报告是对外的， 需求规格说明书是对内的 ； (2)用户需求报告是合同的产物， 需求规格说明书是立项建议书的产物； (3) 由用户需求报告可产生需求规格说明书；,需求报告和需求规格说明书的差异,(4) 需要注意的问题 国内有的软件公司，不仅将用户需求报告