软件工程---软件需求

1,软件工程,软件需求,2,主要讲解内容,1、需求分析的重要性2、需求分析的任务3、需求分析的目的4、需求分析的方法5、需求分析的艺术6、需求管理过程7、需求分析文档8、用户需求报告9、需求规格说明书,3,软件需求,导读: 软件需求，又称软件需求分析或软件需求获取，它既是软件开发中的老课题（讲了几十年了）和老问题（几十年都没有很好地彻底解决），又包含着许多新思路和新内容。需求获取是否彻底与成功，直接关系到软件开发的成败问题。本章先论述需求分析的9项任务和目的，然后介绍需求分析和需求管理的方法，以及IT企业的用户需求报告和需求规格说明书编写的参考指南。下面列出了读者在本章学习中要了解、理解和掌握的主要内容。,4,软件需求,5,面向对象分析,面向对象分析(通常缩写为OOA)的关键，是识别出问题域内的对象，并分析它们相互间的关系，最终建立起问题域的简洁、精确、可理解的正确模型。,6,分析过程,1、 概述 面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。,7,2、 三个子模型与五个层次 即静态结构(对象模型)，交互次序(动态模型)和数据变换(功能模型)。解决的问题不同，这三个子模型的重要程度也不同： 当问题涉及交互作用和时序时(例如，用户界面及过程控制等)动态模型是重要的； 解决运算量很大的问题(例如，高级语言编译、科学与工程计算等)，则涉及重要的功能模型。 动态模型和功能模型中都包含了对象模型中的操作(即服务或方法)。,60,8,五个层次,9,一般说来，面向对象分析大体上按照下列顺序进行： 寻找类&对象，识别结构，识别主题，定义属性，建立动态模型，建立功能模型，定义服务。 但是，分析不可能严格地按照预定顺序进行，大型、复杂系统的模型需要反复构造多遍才能建成。通常，先构造出模型的子集，然后再逐渐扩充，直到完全、充分地理解了整个问题，才能最终把模型建立起来。,60,10,分析也不是一个机械的过程。大多数需求陈述都缺乏必要的信息，所缺少的信息主要从用户和领域专家那里获取，同时也需要从分析员对问题域的背景知识中提取。在分析过程中，系统分析员必须与领域专家及用户反复交流，以便澄清二义性，改正错误的概念，补足缺少的信息。面向对象建立的系统模型，尽管在最终完成之前还是不准确、不完整的，但对做到准确、无歧义的交流仍然是大有益处的。,11,需求陈述,书写要点 内容包括：问题范围，功能需求，性能需求，应用环境及假设条件等。总之，需求陈述应该阐明“做什么”，而不是“怎样做”。它应该描述用户的需求，而不是提出解决问题的方法。应该指出哪些是系统必要的性质，哪些是任选的性质。应该避免对设计策略施加过多的约束，也不要描述系统的内部结构，因为这样做将限制实现的灵活性。对系统性能及系统与外界环境交互协议的描述，是合适的需求。此外，对采用的软件工程标准、模块构造准则、将来可能做的扩充以及可维护性要求等方面的描述，也都是适当的需求。,60,12,需求分析的重要性,需求分析的输入是软件合同或软件立项建议书，以及对用户现场的调研、分析和确认，输出是用户需求报告/需求规格说明书，根据“五个面向理论”，需求分析的方法主要是“面向流程分析”。,60,13,1.需求分析为什么重要（1）许多大型应用系统的失败，最后均归结到需求分析：要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。,14,（2）需求分析的输出文档是用户需求报告，它既是软件生存周期中的第一个里程碑，又是客户、软件开发人员和项目管理人员三者必须遵守的一根基线，是三者共同工作的基础。（3）需求分析要占用整个软件开发时间或工作量的30%。（4）需求获取中的错误，属于软件开发中的早期错误，它会在后续的设计和实现中进行发散式的传播。 根据以上4项原因，IT企业的高层经理，对需求分析特别重视，常常派经验最丰富的人员去做项目需求。正因为如此，“系统分析员”才是软件行业中的最高技术职称。,60,15,2.需求获取为什么难 需求获取看似容易，做起来很难，主要原因有三条。（1）用户需求具有动态性，即需求的不稳定性：在整个软件生存周期内，应用软件的需求会随着时间的进展而有所变化。个别用户，甚至是朝三暮四地变化。（2）用户需求具有模糊性，即需求的不准确性：由于用户的素质不是很高，业务流程不是很规范，所以需求表达不很清楚和也不够明确。（3）开发者和用户要对需求达成完全一致的认识，用户要在需求报告上签字，要承担责任。,16,名词解释,17,名词解释,18,需求分析的任务,需求分析就是对顾客的需求进行定义或确定，这一过程中有许多工作要做。但是，最主要的是完成如下9项任务。第1项任务： 画出目标系统的组织结构图，列出各部门的岗位角色表，即组织机构模型。,19,组织机构模型,20,岗位角色,21,需求分析的目的,第2项任务： 画出目标系统的业务操作流程图，它包括物流、资金流、信息流、即业务操作模型，重点是业务操作的流水步骤。业务模型表示了与系统有关的人、设备、其他子系统之间的业务关系和费用关系，它是经过业务流程重组、再造和优化之后，并且得到企业领导确认的业务流程图。 业务流程图的画法多种多样，各自可根据自身的习惯和特点，制定一套图形规则，在本组织内统一遵守。业务流程图的制作工具，所谓直式业务流程图，就是用图的横向坐标表示企业的部门岗位，用图的纵向坐标表示企业的作业流程。,60,22,第3项任务： 画出目标系统的数据流程图，即单据和报表的流程图，掌握业务规则，获得初步数据模型(真正的数据模型是ER图加上相应的数据字典)。 数据流程图中要突出单据流，分清不同单据之间的先后流动次序，以及同一单据中的不同数据项的先后流动次序。数据流程图的画法多种多样，各软件组织可根据自身的习惯和特点，制定一套图形规则，在本组织内统一遵守。,60,23,对于所有的单据或报表，均要收集并整理。同时，将单据或报表的名称、用途、使用单位、制作单位、频率、高峰时数据流量，及每个数据项的名称、类型、长度、精度、算法等，都要全部列出，形成原始单据和输出报表的表格。单据或报表整理后的参考格式,24,各数据项的详细说明,25,第4项任务： 列出目标系统的功能点列表，即功能模型。(注：有时将性能模型、界面模型和接口模型的内容都合并到功能模型之中。) 系统的功能点列表,26,第5项任务： 列出系统的性能点列表，即性能模型。 系统的性能点列表,27,第6项任务：列出目标系统的接口列表，即接口模型。接口列表的参考格式，如表5-8所示。,28,第7项任务： 确定目标系统的运行环境，即环境模型。 运行环境包括：核心计算机及网络资源（系统软件、硬件和初始化数据）的配置计划、采购计划、安装调试进度、人员培训计划等内容。第8项任务： 目标系统的界面约定，即界面模型。 界面设计的原则是：方便、简洁、美观、一致等。整个目标系统的界面风格定义要统一，某些功能模块的特殊界面要说明。,29,第9项任务： 对目标系统的开发工期、费用、开发进度、系统风险等问题进行分析与评估。 对于一般企业事业单位的信息系统需求分析，完成好上述9项任务，并与用户达成全面共识，通过评审，得到用签字确认，就算成功了。 但是，上述9项任务不是教条，不能完全生搬硬套，而要根据具体问题具体分析。 对于特殊的系统，除了上述9项任务之外，可能还要增加其他任务，项目经理和系统分析师要严把关口。 如果通过需求分析之后，对将来要实现的目标系统，仍然感到心中无数、心里发慌，那么绝对不要签字确认，而要从头开始，重新进行需求获取。,60,30,需求分析的目的,需求分析的重点是： 通过弄清业务流程和数据流程的手段，达到与客户共同确定业务模型、功能模型、性能模型、接口模型的目标。通过评审，与客户达成完全一致的理解，让客户确认，在需求报告上签字，这是需求分析的根本目的。只有实现了这个目的，才能冻结需求，实现一个重要的里程碑，形成稳定可靠的需求文档基线，为后致的设计、编码、测试、验收打下坚实的基础。 如果在需求分析中隐含一个错误或一个不确定的问题，就会导致在后续开发工作中出现十个甚至百个错误或问题，这就是错误或问题传播的发散性。,60,31,需求分析的难点是： 在系统的流程、功能、性能和接口4个方面，开发者与客户达成完全一致的需求，让客户最终签字确认，并保证在项目验收前，需求相对稳定不变。 如需求有变化，双方必须履行“需求变更管理程序”。 “开发者与客户达成完全一致的需求”，这既是需求分析的目的，又是需求分析的难点。那么，要克服这个难点，形成稳定可靠的需求文档基线就要靠需求分析的方法、技巧和经验了。,60,32,总结前人需求分析的经验，系统分析师应该对用户进行需求分析培训，用户应参加业务需求分析的全过程，向用户发放需求调查表格，召开需求调研会，深入到重点岗位了解需求，必要时参加实际的业务工作，边分析边整理文档，边征求修改意见，定期向用户中的操作层、管理层、决策层分别汇报，演示目标系统的流程、功能、性能、接口及界面的需求。,需求分析的方法,60,33,1、面向流程分析 需求分析是面向流程的，而流程是动态的、实时的。系统的功能、性能、接口、界面都是在流程中动态实时地反映出来。在所有的流程(物流、人流、资金流、信息流、单据流、报表流、数据流)中，数据流最重要，也最有代表性。因为在计算机网络系统内，一切流程都表现为数据流。所以，面向流程分析，实质上是面向数据流程分析，或面向数据分析。计算机网络只认识数据，其他所有的信息必须转化为数据之后才能流动，所以说面向流程分析本质上是面向数据流程分析。,60,34,需求分析的思路，是从用户的功能需求(系统需要做什么)出发，由系统的业务流程和数据流程导出系统的业务模型和功能模型，识别出系统的元数据和中间数据，为今后设计数据模型做好充分准备。同时，对系统的软、硬件环境配置；开发工期、费用、开发进度、培训、系统风险进行评估。,60,35,2.找出元数据元数据的分析与识别，是需求分析的主要议题之。元数据是组织数据的数据，描述数据的数据，关于数据的数据。通俗地讲，元数就是信息系统中实体名及其属性名的集合，或者说就是基表的表名与字段名的集合。此可见，所谓实体，就是一组相关元数据的集合。 元数据分析的出发点是业务模型和功能模型，落脚点是系统中的实体及其属性，企事业单位的数据模型中的所有元素。元数据蕴藏在信息系统的单据中，单据名称及其内部的数据项名称，一般就是元数据。,60,36,它是一个实体，单据中的“数据项”就是该实体的姓名，它们都是元数据。而“，”，就不是元数据，只是由元数据所组织的一条记录。,商品出库单,37,3找出中间数据 中间数据蕴藏在信息系统的输出报表中，报表名称及其内部的数据项名称，一般是中间数据。其中“部门名称，员工人数，男性人数，本科以上人数，30岁以下人数，”，这名词称为中间数据，而“市场部，25，16，21，23”，这些数据称为统计数据。 中间数据是组织统计数据的数据，描述统计数据的数据，关于统计数据的数据。,38,4找出元数据与中间数据之间的关系 元数据对应原始单据，中间数据对应查询、统计、报表。元数据将原始单据中与入的数据组织起来变成基表中的记录，这些记录称为基础数据。中间数据将统计报表叫输出的数据组织起来变成中间表中的记录，这些记录称为统计数据。,60,39,4找出元数据与中间数据之间的关系 那么读者会问：“它们两者之间是否有关系?有什么关系?”回答是：“有关系是一种因果关系”。 中间表中的记录是由基表中的记录派生(推导、加工、处理)出来的，为了简单起见，我们说“中间数据是由元数据派生出来的”，这种派生就是算法分析，也叫数拆处理。在需求分析中，弄清由元数据到中间数据之间的演变关系，对需求分析的成败至关重要，系统分析师和项目经理不能粗心大意!,60,40,需求分析的方法,5找出单据中的流程 单据中有如下三个流程。 (1)该单据的上游是什么?例如，若要录入“单据2”，必须先录入“单据1，否则“单据2”就录入不进去。那么“单据1就是“单据2”的上游。,41,(2)同一个单据内部的数据项之间，也存在一个先后次序问题。 例：出库单中的数据项“制单人，审核人，批准人”之间的录入次序，也有一个先后问题。制单人必须第一个录入，审核人必须是第二个确认，批准人只能是第三个确认。而且只有批准人确认之后，该单据才能生效，才能出库，信息系统才能向后台数据库服务器提交这条记录。 (3)该单据的下游是什么?是录入“单据3”呢?还是打印报表A”呢?还是当日单据汇总处理呢?这个问题，也要明确。否则，操作员就可能误操作。,60,42,6面向对象分析 也是从系统的基本功能入手，或从与系统有关的人和事入手，将所有的功能需求找出来，然后将每项功能对应一个对象，分析每个对象的属性、方法及包装方式，最后归并相同对象，删除冗余属性，将对象上升为类，再用对象总线或对象框架将类组装起来，用以表示用户所有需求。CASE工具RationalRose用Usecase称为“用况”或“用例”，表示与系统有关的人、设备或外界子系统的一组交互动作序列)来进行需求分析，就是系统的需求。 面向数据分析，就是面向元数据和中间数据分析，只要将这两类数据及其之间的关系分析透了，对开发者来说，主要目的就达到了。,43,需求分析的方法,7分析与设计要同时考虑 在分析师心灵深处既要弄清目标系统是什么，又要为目标系统怎么设计做充分准备。那种在分析师心灵深处只考虑目标系统是什么、而不考虑目标系统怎么做的需求分析观点，是片面的、表面的、过时的、不可取的。有经验的分析师，常常是一边搞需求分析，一边在心灵深处思考今后怎么去设计实现。一旦发现设计实现中将会出现问题，立即进一步需求分析。这是因为：许多问题在分析“目标系统是什么”时发现不了，只有考虑“目标系统怎么做”时才能暴露和发现更多的问题。一些系统由于多次需求分析不到位，甚至在设计或编程时被卡住，不得不回头再做需求分析，就是缺乏分析与设计的同步考虑。,60,44,需求分析艺术,作为系统分析员，要在实践中不断提高自己，增长才干，修炼自身，形成独特的分析艺术。下面介绍常用的几点艺术。(1)需求分析相似如乒乓球赛的双打，它是由分析师和用户配对进行双打，而且用户不懂得需求分析方法。怎么办?在需求分析之初，要对用户进行通俗易懂、深入浅出的需求分析方法培训和引导。培训的内容是：需求分析的重要性、双方配合的重要性、需要调查的项目、用户哪些人员参加、调查表的填法和调查会的开法。,45,(2)宏观上的流程，由企事业单位懂业务的中高层领导介绍。微观上的流程，由企事业单位懂业务的基层人员说明。(3)同一个业务流程，要有两个以上懂业务的人员介绍，而且要经得起推敲，要经过优化过滤处理，要被业务主管确认。4)企事业单位是个金字塔结构，上面小，下面大，需求也是个金字塔结构。决策层提出宏观上的统计、查询、决策需求，管理层提出业务管理和作业控制需求，操作层提出录入、修改、提交、处理、打印、界面、传输、通信、时间与速度等方面的操作需求。,60,46,(5)在需求分析中，一般要向用户进行两三次汇报，公开征求决策层、管理层和操作层的意见。每次汇报一个人主讲，其他人补充。在汇报之前，先在项目组内部演示一次，即彩排一次，以提高汇报的质量(6)要与用户交朋友，要记住用户的姓名、职务、职称、特长、爱好、脾气、特点。要交心谈心，要讲信誉，要尊重人，要诚恳待人。,47,需求管理过程,1.需求管理的任务与内容 需求管理的中心任务，是保证软件产品满足客户在软件功能、性能、接口三个方面的需求。 在开发过程中，经常会碰到客户不明确的需求及频繁的需求变更，正确地对待并处理这种情况，可以保证软件产品在预计的进度和成本范围内提交。需求管理过程的目标，是管理和控制需求，维护软件计划、产品和活动与需求的一致性，并保证需求在软件项目中得到实现。 需求管理是面向需求过程的，需求管理过程主要包括需求确认、需求评审、需求跟踪和需求变更活动。 需求管理过程要求指定明确的负责人，负责与客户协商并确认需求，包括非技术需求、技术需求及编制需求跟踪矩阵。,48,(1)非技术需求：一般在协议、条件和合同条款中描述，包括提交的产品、提交的日期和里程碑等内容。(2)技术需求：描述系统的软件功能、性能、接口、设计约束、编程语言和界面需求等多方面内容。(3)需求跟踪矩阵，是在充分了解技术需求的基础上编制的。需求跟踪矩阵的建立，使项目经理能够跟踪每一项需求的实现状态。,60,49,在需求被纳入到软件项目之前，要求软件工程组评审需求。一般情况下，客户会参与项目需求的评审。评审的形象是需求确认的结果，包括非技术需求文档、技术需求文档和需求跟踪矩阵。评审的主要目的在于： (1)确定分配的软件功能、性能、接口需求，用软件来实现是可行的、适当的。 (2)软件功能、性能、接口需求被清晰、正确地描述。 (3)软件功能、性能、接口需求是一致的、相互不矛盾。 (4)软件功能、性能、接口需求是可测试的。,60,50,评审的结束，标志着与客户协商确认需求的结束。通过高级管理者批准的需求文档，应置于软件基线库中，进行配置管理和控制，同时已批准的需求，作为软件项目策划的主要输入，要纳入到软件项目之中。 需求跟踪的主要内容是跟踪不符合项的改正情况。需求跟踪的主要意义在于，获得需求目前的实现状态，确保用户所有的需求都得到满足。可靠的跟踪信息可为需求变更、系统维护、关键成员离开、系统再设计和类似系统设计等很多方面，提供参考和指导，并可以减少风险和提高项目成功。 一般来讲，需求变更，会引起计划及其他软件工作产品的变更。实施CMM的项目，都是遵照软件组织规定的变更流程进行需求变更。需求变更的过程需要跟踪，同样，对变更的需求也要进行跟踪。,60,51,2对需求文档进行同行评审 在CMML3中，提倡同行评审，而不是专家鉴定。需求文档产生后，一定要进行同行评审。若未获得通过，则要列出“不符合项”，并进行跟踪监督。 同行评审，是指进行软件工作产品验证的活动，其目的是为了及早和高效地从软件产品中识别并消除缺陷。与技术鉴定不同，同行评审的对象一般是部分软件产品，其重点在于发现软件产品中的缺陷。所谓同行，是指和生产者在被评审的软件产品上有相同的开发经验和知识的人员。一般来讲，不建议管理者作为同行参与同行评审，也不应使用同行评审的结果去评价产品生产者。,60,52,与一般评审流程相似，同行评审过程包括策划、准备和实施三个阶段。正式的同行评审一般采取会议的形式。同行评审的重点，在于确定产品的缺陷，而不是如何解决问题。在会议结束之后，软件产品的生产者依据同行评审记录，修正软件产品缺陷，然后由同行评审负责人确认缺陷的修正。 引入同行评审流程后，加大了对软件开发前期产品质量的保证力度，如需求分析、概要设计和详细设计阶段的产品都是同行评审的重点。对前期产品的质量保证，明显地降低了软件产品的成本，提高了软件产品的整体质量。另外，由于进行同行评审，使大量人员对软件系统中原本不熟悉的部分更加了解。因此，同行评审还提高了项目的连续性，培训了后备人员。,53,需求分析文档,需求报告和需求规格说明书的差异1、用户需求报告是对外的，需求规格说明书是对内的 用户需求报告是站在用户的角度、用他们可以看懂的语言写的，需要用户签字确认，目的是为用户验收测试提供依据(基线)，内容既要描述当前系统的情况，又要描述目标系统的运行环境、流程、功能、性能、接口和界面等。 需求规格说明书则不同，它是对内的，不需要用户签字确认。它是站在开发者的角度、用开发者的语言写的(用户可能看不懂，比如主键、外键、算法分析、伪码等名词)，目的是作为概要设计和详细设计的基线，内容不必描述当前系统的情况，只需描述目标系统的业务模型、功能模型(包括接口和界面)、数据模型。,60,54,2用户需求报告是合同的产物，需求规格说明书是立项建议书的产物 用户需求报告是对合同而言的。因为签订了合同，要按合同要求为用户定制软件，所以要对用户的需求进行分析，最后与用户在需求上达成一致，形成用户需求报告，因此用户需求报告是合同的产物。 需求规格说明书是对立项建议书而言的。由于事先没有签合同，没有确定的某个用户，只是针对某行业的共同特点研发一个软件产品，为潜在的客户群服务，所以要进行市场调研，市场销售人员要写出立项建议书，正式立项后，再由系统分析员进一步调研，写出需求规格说明书，以它作为概要设计和详细设计的基线。因此需求规格说明书是立项建议书的产物。,60,55,3由用户需求报告可产生需求规格说明书 签完合同后，一般是先书写出用户需求报告，后书写出需求规格说明书。当需求报告用户签字确认后，需求规格说明书很快就出来了。利用软件复用技术，在制作需求规格说明书之前，先将需求报告拷贝一份，作为需求规格说明书的雏型，然后再在上面增、删、改，将用户看不懂的内容，而设计师又必须知道的内容(比如主键、外键、算法分析等)加上去，就产生了最终的需求规格说明书，以它作为概要设计和详细设计的基线。,60,56,4需要注意的问题 有的软件公司不仅将用户需求报告和需求规格说明书不加区分地合二而一，而且还将概要设计说明书和详细设计说明书也不加区分地合二而一。这种做法不规范，对小而熟悉的项目可以，对大而生疏的项目不合适，应该逐步改正，养成一种认真、仔细、规范的作风。 在软件开发的总工作量中，需求的工作量一般占30；设计的工作量一般占30，编码和单元测试的工作量一般占30，Alpha测试的工作量一般占5，返工返修的工作量一般占5。那种认为需求不重要、设计可不做、一上来就写程序的观点和做法是完全错误的。 用户需求报告和需求规格说明书两者的内容较多；篇幅较长，少则几十页，多则上千页，一般为几百页。,60,57,2 用户需求报告 软件需求分为两种，一种是“用户需求报告”，它是开发人员直接与用户打交道，直接向用户提交需求的报告。另一种是分配的“软件需求报告”，它是开发人员不直接与用户打交道，只与系统集成项目组打交道，由系统集成项目组将一个大项目分解为硬件和软件两部分，并将软件开发的任务分配给软件项目组，它相当于指令性软件开发计划，是由软件项目组的分析人员与系统集成项目组共同完成。 以业务流程为主线，以需求分析为中心，以功能、性能、接口三个列表为基本点，按照规定的格式，就可以制作出合乎规范的用户需求报告。,60,58,小 结,本章从需求分析的任务、目标、方法、经验、文档、管理等6个不同的方面，论述了需求获取的手段。 本章具体说明了需求分析的重要性，重点介绍了需求获取的任务和目的。为了完成软件需求的任务，实现软件需求的目标，必须掌握需求分析的方法。 需求分析方法本身没有高深的理论，大部分都是工作经验的积累，如在分析中坚持以流程为主线；集中精力找出元数据和中间数据，理清从元数据到中间数据之间的转换算法(算法分析)：在实现的思考中去发现分析中存在的不足和问题，防止在后续工作中出现需求分析的返工。 管现方法主要是对需求活动的评审，对不符合项的跟踪，以及对需求变更的控制。,59,小 结,软件需求阶段的成果表现在需求文档上。文档中重点要写清楚需求的功能点列表、性能点列表、接口列表。初学者书写文档有个适应期，可以先简后繁、循序渐进，本章只是提供书写文档的参考格式，在实际工作中要灵活运用。 软件分为系统软件和应用软件，应用软件又可以分为信息系统软件和非信息系统软件，信息系统软件是以数据库管理系统DBMS为支撑平台的应用软件，非信息系统软件是与数据库管理系统平台无关的应用软件。有人在想：“需求分析是否也可以分为系统软件需求分析和应用软件需求分析，信息系统软件需求分析和非信息系统软件需求分析呢?”回答是：“应该大胆地想，而且想得很好!”,60,思 考 题,1、为什么需求分析特别重要?2、需求分析的目的是什么?需求分析的难点在哪里?3、总结前人需求分析的经验有哪几条?4、需求分析的基本思路是什么？5、元数据与中间数据之间，有什么关系?请举例说明。 6、需求管理过程的目标和内容是什么? 7、为什么对需求文档要进行同行评审? 8、用户需求报告与需求规格说明书有何差异?,61,用户需求报告,1.概述 本文档是进行需求规格定义、项目策划、概要设计的基础，也是用户进行验收的依据。1.1用户简介 在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统范围，进行关于功能、进度、成本、性能等方面的平衡决策。 对于产品开发类项目，需要在此将该产品定义的用户群的特点描述清楚。,20,62,用户需求报告,1.2项目的目的与目标 项目的目的是对开发本系统意图的总概括。项目的目标是将目的细化后的具体描述。项目目标应是明确的、可度量的、可以达到的，项目的范围应能确保项目的目标可以达到。 对于项目的目标可以逐步细化，以便与系统的需求建立对应关系，检查系统的功能是否覆盖了系统目标。1.3术语定义（Terms Glossary） 将该用户需求报告中的术语、缩写进行定义，包括用户应用领域与计算机领域的术语与缩写等。,63,用户需求报告,1.4参考资料(References)说明该用户需求报告使用的参考资料，如：1商务合同2招标书3用户领域的资料4用户需求调查表5参照的标准每一个文件、文献要有标题、或文件号，发布或发表日期以及出版单位。1.5相关文档(RelatedDocuments)说明用户需求报告的变更，以及可能受变更影响的其他相关文档,如:1项目开发计划2需求规格说明书,64,用户需求报告,版本更新记录格式,65,用户需求报告,2.现有系统描述2.1组织结构与职责 将用户的组织结构逐层详细描述，建议采用树状的组织结构图进行表达，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围很有帮助。取得用户的组织结构，是需求获取步骤中的工作任务之一。2.2岗位定义 用户环境中的企业岗位和组织结构一样，也是分析人员理解企业业务的基础，是需求获取的工作任务，同时也是分析人员提取形象的基础。每个岗位的职责可以进行详细的描述,66,用户需求报告,岗位定义,67,用户需求报告,2.3作业流程企业的作业流程，首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图、程序流程图加上方字说明。 图形可以将流程描述得很清楚，但是还要附加一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述的内容，需要用文字进行详细描述。,20,68,用户需求报告,2.4单据、报表 现行系统中用户正在使用的正式的或非正式的单据、账本、报表等可以收集起来，并进行穷举、分类、归纳。单据、账本、报表是用户系统中信息的载体，是进行系统需求分析的基础，无论采用哪种分析方法，这都是必不可少的信息源。,20,69,用户需求报告,单据的描述格式,70,用户需求报告,各数据项的详细说明如下:,71,用户需求报告,2.4.3报表 因为报表上的数据是统计数据，所以一个报表一般对应一张中间表，报表的格式可用表格描述。,20,72,用户需求报告,报表的描述格式,73,用户需求报告,2.5存在的问题 在现行的系统中，决策层、管理层、操作层各存在哪些方面的问题需要计算机来解决，尤其是决策层、管理层这些问题中包含了用户的需求与期望，有些问题是新系统可以解决的，有些问题则不是。2.6可能的变化 对于现行的系统，将来可能会有哪些变化，需要在此描述。企业中的变化是永恒的，系统分析员需要描述哪些变化可能引起系统范围变更。,20,74,用户需求报告,3.目标系统功能需求(FunctiOnofTargetSystem)3.1功能需求分析(FunctionAnalys)决策层、管理层、操作层各有哪些具体功能要求。3.2功能需求点列表(FunctionLlst)在功能需求分析完成后，要详细列出用户需求功能点列表，提供给后续设计、编程、测试中使用，更是为了用户测试验收中使用。功能需求点列表的格式,75,用户需求报告,功能需求点列表,76,用户需求报告,4.目标系统性能需求4.1时间要求 如： (1)响应时间，如查询的最长等待时间。 (2)更新处理时间，如记账的最长时间。 (3)数据的转换和传送时间，如远程数据传输的时间要求。 (4)解题时间。,77,用户需求报告,4.2空间要求 如： (1)支持的终端数。 (2)支持的并行操作的使用者数。 (3)处理的文件和记录数。 (4)表和文件的大小规模(要按可预见的增长，对数据及其分量的存储要求做出估算)。 (5)处理任务的数量。 (6)在正常情况下和峰值工作条件下，在一定时间周期中要处理的数据总数。 (7)对输入和输出数据的精度要求。 (8)对处理和传输过程中的精度要求,78,用户需求报告,4.3性能需求点列表详细列出用户性能点列表，提供给后续分析、设计、编程、测试中使用，更是为了用户测试验收中使用。性能需求点列表,79,用户需求报告,5.目标系统界面与接口需求(InterfaceofTargetSystem)5.1界面需求(hlterphaseRequirement)界面的原则要求，如方便、简洁、美观、一致等。整个系统的界面风格定义，某些功能模块的特殊的界面要求。(1)输入设备：键盘、鼠标、条码扫描器、扫描仪等；(2)输出设备：显示器、打印机、光盘刻录机、磁带机、音箱等；(3)显示风格：图形界面、字符界面、IE界面等；(4)显示方式：1024*768、640*480等；(5)输出格式：显示布局、打印格式等。,80,用户需求报告,5.2接口需求(InterfaceRequirement)与其他系统的接口，如监控系统、控制系统、银行结算系统、税控系统、财务系统、政府网络系统及其他系统等。(1)与系统特殊外设的接口，如CT机、磁共振、柜员机(ATM)、IC卡、盘点机等。(2)与中间件的接口，要列出接口规范、入口参数、出口参数、传输频率等。应在此列举出所有的外部接口名称、接口标准、规范。外部接口列表。,20,81,用户需求报告,82,用户需求报告,6.目标系统其他需求(OtherRequirementsOfTargetSystem)6.1安全性(Security)6.2可靠性(Dependability)6.3灵活性(Agility) 6.4特殊需求(Specialrequirements)如：(1)进度需求：系统的阶段进度要求。(2)资金需求：投资额度。(3)运行环境需求：平台、体系结构、设备要求。(4)培训需求：用户对培训的需求，是否提供多媒体教学光盘。(5)推广需求：推广的要求，如在上百个远程部门推广该系统，是否要有推广的支持软件。,20,83,用户需求报告,7目标系统假设与约束条件(SupposeandRestrictionOfTargetSystem)假设与约定条件是对预计的系统风险的描述，如：(1)法律、法规和政策方面的限制。(2)硬件、软件、运行环境和开发环境方面的条件和限制。(3)可利用的信息和资源。(4)系统投入使用的最晚日期。(5)需求中的风险分析：技术风险、技能风险、时间风险、资源风险。,20,84,软件工程,需求规格说明书,85,需求规格说明书,1.概述 本文档是进行项目策划、概要设计和详细设计的基础，也是软件企业测试部门进行内部验收测试的依据。1.1用户简介 本节中要将用户的基本情况描述清楚，以便于分析人员划定系统范围，进行功能、进度、成本、性能等方面的平衡决策 对于产品开发类项目，需要在此将该产品定义的用户群的特点描述清楚。,86,需求规格说明书,1.2项目的目的与目标 项目的目的是对开发本系统的意图的总概括。项目的目标是将目的细化后的具体描述。项目目标应是明确的、可度量的、可以达到的，项目的范围应能确保项目的目标可以达到。 对于项目的目标可以逐步细化，以便与系统的需求建立对应关系，检查系统的功能是否覆盖了系统的目标。1.3术语定义 将该需求的术语、缩写进行定义，包括用户应用领域与计算机领域的术语与缩写等。,87,需求规格说明书,1.4参考资料 说明该用户需求报告使用的参考资料，如： 1商务合同 2招标书 3用户领域的资料 4用户需求调查表 5用户需求报告 6参照的标准 每一个文件、文献要有标题、文件发号、发布或发表日期以及出版单位。,88,需求规格说明书,1.5相关文档 1项目开发计划 2概要设计说明书 3详细设计说明书,89,需求规格说明书,1.6版本更新信息版本更新记录,90,需求规格说明书,2.目标系统描述2.1组织结构与职责 将目标系统的组织结构逐层详细描述，建议采用树状的组织结构图进行表达，每个部门的职责也应进行简单的描述。组织结构是用户业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围很有帮助。取得用户的组织结构，是需求获取步骤中的工作任务之一。2.2角色定义 用户环境中的企业角色，和组织机构一样，也是分析人员理解企业业务的基础，是需求获取工作任务，同时也是分析人员提取对象的基础。每个角色的授权可以进行详细的描述，建议采用表格的形式。,91,需求规格说明书,角色定义,92,需求规格说明书,对用户角色的识别也包括使用了计算机系统后的系统管理人员。2.3作业流程(业务模型) 目标系统的作业流程是对现有系统作业流程的重组、优化与改进。企业的作业流程首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图、Use case图、其他示意图的形式。 图形可以将流程描述得很清楚，但是还要附加一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述的内容，需要用文字进行详细描述。,93,需求规格说明书,2.4单据、报表 目标系统中用户将使用的正式单据、账本、报表等，并进行穷举、分类、归纳。单据、账本、报表是用户系统中信息的载体，是进行系统需求分析的基础，无论采用哪种分析方法，这都是必不可少的信息源。2.4.1单据因为单据上的数据是原始数据，所以一种单据一般对应一个实体，一个实体一般对应一张基本表。,94,需求规格说明书,单据的描述格式,95,需求规格说明书,2.4.2报表 因为报表上的数据是统计数据，所以一个报表一般对应一张中间表，报表的格式可用表格描述。,96,需求规格说明书,2.5可能的变化 对于目标系统，将来可能会有哪些变化，需要在此描述。企业中的变化是永恒的，系统分析员需要描述哪些变化可能引起系统范围变更。3.目标系统功能需求3.1功能需求分析 决策层、管理层、操作层各有哪些具体功能要求3.2功能需求点列表(功能模型) 在功能需求分析完成后，要详细列出用户需求功能点列表，提供给续设计、编程、测试中使用，更是为了用户测试验收中使用。,97,需求规格说明书,功能需求点列表,98,需求规格说明书,4.目标系统性能需求4.1时间要求 如： (1)响应时间，如查询的最长等待时间。 (2)更新处理时间，如记账的最长时间。 (3)数据的转换和