04-1软件需求分析培训讲学

《04-1软件需求分析培训讲学》由会员分享，可在线阅读，更多相关《04-1软件需求分析培训讲学（64页珍藏版）》请在金锄头文库上搜索。

1、1,需求分析概述 需求获取 需求分析与建模 需求归档 需求过程管理,软件需求分析,2,学习目标,了解需求工程的几个阶段； 掌握需求分析的任务； 了解需求过程管理的相关知识； 理解需求的概念、需求的种类、需求的层次； 理解需求确认与验证的区别； 掌握两种需求文档的关系与区别； 掌握获取需求的方法； 理解需求分析的原则； 掌握需求分析的方法及对应的建模描述工具。,3,需求的概念 需求的种类 需求的层次 需求分析的任务 两类需求文档 需求工程阶段,一、需求分析概述,5,1997年,IEEE软件工程标准词汇表中定义需求为： (1)用户解决问题或达到目标所需的条件或能力(Capability)。 (2)

2、系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 (3)一种反映上面(1)或(2)所描述的条件或能力的文档说明。,1.需求的概念,6,需求的简化定义： 产品必须提供的服务 产品必须具备的质量特征 需求关注于顾客的需要，指定系统要“做什么”，而不关心问题的解决方案或实现,1.需求的概念,7,负责者：系统分析人员 参与者： 合同监督人员，提出限制系统开发的里程碑和进度表 顾客和用户，必须理解需求，确信满足了他们的需要。 业务经理，必须理解建立和使用系统的可能的后果 设计员，使用需求作为开发可接受解决方案的依据 测试员，开发测试数据和测试事务以确保软件系统满足每一条需求,

3、8,功能性需求:描述系统做什么。 非功能性需求：定义系统工作时的特性。包括： 产品必须遵从的标准、规范和合约； 外部界面的具体细节； 性能要求； 设计或实现的约束条件及质量属性。,2.需求的种类,9,高层领导的战略决策需求 中层管理的查询统计需求 基层人员的实时操作需求 这个上中下三层需求，构成一个需求金字塔。,3.需求的三个层次,10,4.需求分析的任务,深入描述软件的功能和性能 确定软件设计的约束和软件同其它系统元素的接口细节 定义软件的其它有效性需求,11,需求分析研究的对象：项目的用户要求 准确地表达被接受的用户要求 确定被开发软件系统的系统元素 将功能和信息结构分配到这些系统元素中,

4、12,图书馆信息系统的例子,第1项任务：画出目标系统的组织结构图，列出各部门的岗位角色表，即组织机构模型，如图4-2至表4-4所示。 第2项任务：画出目标系统的业务操作流程图，即业务模型。它包括物流、资金流、信息流，重点是业务操作的流水步骤。 业务流程图的画法多种多样，各软件组织可根据自身的习惯和特点，制定一套图形规则，在本组织内统一遵守。 业务流程图的制作工具，可以是微软的Word , Visio。 所谓“直式业务流程图”，就是用图的横向坐标表示企业的部门岗位，用图的纵向坐标表示企业的作业流程，用图4-3的图标画出企业的业务流程。,13,第3项任务：画出目标系统的数据流图DFD，即单据和报表

5、的流图，掌握业务规则，获得初步数据模型（真正的数据模型是E -R图加上相应的数据字典）。 数据流图中要突出单据流，分清不同单据之间的先后流动次序，以及同一单据中的不同数据项的先后流动次序。 数据流图的画法多种多样，各软件组织可根据自身的习惯和特点，制定一套图形规则，在本组织内统一遵守。 数据流图的制作工具，可以是微软的桌面办公工具Office（Word , Visio），也可以是Power Designer中的数据流图绘制工具Process Analyst。,14,完整的数据流图还包括定义数据字典。数据字典是指对数据流图中出现的数据源、数据潭、数据加工、数据流向、单据、报表等数据名字进行定义与

6、解释。 对于所有的单据或报表，均要收集并整理。 将单据或报表的名称、用途、使用单位、制作单位、频率、高峰时流量，及每个数据项的名称、类型、长度、精度、算法等，都要全部列出，形成原始单据和输出报表的表格。 对每一张单据或报表，都必须用两张表格来描述，其中第一张表格描述单据或报表的公共信息，即单据或报表的“头尾”信息。第二张表格描述单据或报表的数据项信息，即单据或报表的“体”。,15,16,第4项任务：列出目标系统的功能点列表，即功能模型。（注：有时将性能模型、界面模型和接口模型的内容都合并到功能模型之中。） 功能模型也可以用Use Case图表示，也可以用功能点列表描述。 “图书馆信息系统”的功

7、能点列表，如表4-7所示。其中“系统响应”这一项，表示将来的目标系统所要做的工作。需要指出，功能列表不是唯一，也没有标准答案。,17,18,19,20,21,22,第5项任务：列出系统的性能点列表，即性能模型。 “图书馆信息系统”的性能点列表，如表4-8所示。 其中“系统响应”这一项，表示将来的目标系统所要做的工作。 需要指出，性能列表不是唯一，也没有标准答案。,23,24,第6项任务：列出目标系统的接口列表，即接口模型。 “图书馆信息系统”的接口点列表，如表4-9所示。 需要指出，接口列表不是唯一，也没有标准答案。,25,26,第7项任务：确定目标系统的运行环境，即环境模型。 运行环境包括：

8、核心计算机及网络资源（系统软件、硬件和初始化数据）的配置计划、采购计划、安装调试进度、人员培训计划等内容。,27,第8项任务：目标系统的界面约定，即界面模型。 界面设计的原则是：方便、简洁、美观、一致。整个目标系统的界面风格定义要统一，某些功能模块的特殊界面要说明。例如， 输入设备：键盘、鼠标、条码扫描器、扫描仪等； 输出设备：显示器、打印机、光盘刻录机、磁带机、音箱等； 显示风格：图形界面、字符界面、IE界面等； 显示方式：1024768，640480等； 输出格式：显示布局、打印格式等。,28,第9项任务：对目标系统的开发工期、费用、开发进度、系统风险等问题进行分析与评估。 对于一般企事业

9、单位的信息系统需求分析，完成好上述任务，并与用户达成全面共识，通过评审，得到用户签字确认，就算成功了。 但是，上述任务不是教条，不能完全生搬硬套，而要根据具体问题具体分析，活学活用，举一反三。例如，对于特殊的系统，除了上述任务之外，可能还要增加其他任务，项目经理和系统分析师要严把关口，分析彻底、实事求是、灵活掌握。,29,【例4-1】介绍网络游戏软件需求分析的任务。 一款网络游戏软件项目的确立，是建立在各种各样的需求上面的，这种需求往往来自于大量玩家的实际需求，或者是出于公司自身发展和实力，其中大量玩家的实际需求最为重要。 面对拥有不同知识和理解层面的游戏玩家，项目负责人对玩家需求的理解程度，

10、在很大程度上决定了此类游戏项目的开发成败。 如何更好地了解、分析、明确玩家需求，并且能够准确、清晰地以文档的形式表达给项目开发成员，保证开发过程按照满足玩家需求为目的，是游戏项目管理者需要面对的问题。,30,网络游戏需求分析规格说明书，必须包含以下内容： 1. 游戏背景、类型、基本功能； 2. 游戏玩家的主界面； 3. 游戏运行的软硬件环境； 4. 游戏系统机制的定义； 5. 游戏系统的创新特性； 6. 确定游戏运营维护的要求； 7. 确定游戏服务器架设和带宽要求； 8. 游戏总体风格及美术效果标准； 9. 游戏等级及技能、物品、任务、场景等的大概数量；,31,10. 开发管理及任务分配； 1

11、1. 各种游戏特殊效果及其数量； 12. 项目完成的时间及进度。 在网络游戏项目的需求分析中，主要是由项目负责人来确定对玩家需求的理解程度，而玩家调查和市场调研等需求分析活动的目的，就是帮助项目负责人加深对玩家需求的理解，以便于日后在项目开发过程中，作为开发成员的依据和借鉴。 随着网络游戏投入的加大，精细的需求分析也就越来越重要，一次成功的需求分析，不仅需要项目负责人甚至是玩家等所有项目相关人员的共同努力，还和公司的能力范围有一定关系。,32,用户需求报告 站在用户的角度、使用他们可以看懂的语言写的，内容是有关系统的运行环境、业务流程、业务功能、业务性能和业务接口等。 它是需求分析阶段产生的第

12、一份重要的文档，表达了用户全面的、系统的、准确的、并且用户确认的需求，它是用户、项目开发者、项目测试者和项目管理者四方共同工作的基础，是用户测试和验收目标的依据，是作为软件开发机构和用户之间一份事实上的技术合同书，是软件生命周期中的第一根基线。,5.两类需求文档-用户需求报告与需求分析规格说明书,33,需求分析规格说明书（SRS） 以用户需求报告为基线。 站在开发者的角度、使用开发者的语言写的，目的是作为概要设计和详细设计的依据，内容是系统的业务模型、功能模型、数据模型和接口模型的进一步定量描述。它是需求分析阶段产生的第二份重要的文档。 与用户需求报告不同的是，需求分析规格说明书不但以一种一致

13、的、无二义的方式准确的表达用户的需求，而且增加了一些对设计者非常有用的信息(如模型、实体、属性、方法、关系、主键、外键、算法等等)，它是项目开发者、项目测试者和项目管理者三方共同工作的技术基础，是项目开发者下一步进行设计和编码的依据。,34,Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动” Herb Krasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理 Matthias Jarke和Klaus Pohl提出了三阶段周期的说法：获取、表示和验证 ,6.需求工程阶段,35,我们将软件需求工

14、程细分为： 需求获取 需求分析与系统建模 需求归档(需求规约) 需求确认与验证（评审）,需求工程阶段,36,所谓需求获取，就是开发者与用户共同提取并共同确认需求。 在需求获取过程中，人们将“划分、抽象和投影”三要素，作为需求获取的三原则。 (1).划分，就是捕获问题空间的“整体/部分”关系； (2).抽象，就是捕获问题空间的“一般/特殊”或“一般/特例”关系； (3).投影，就是捕获问题空间的多维“视图”。 所谓需求规约，就是对获取并确认的需求进行定义与分析，并且解决需求中存在的二义性和不一致性，最后以一种系统化的文档形式，准确地表达用户的需求，形成所谓的需求分析规格说明书（SRS）。,37,

15、需求确认（Validation）与验证（Verification） 验证 & 确认（Verification & Validation）的定义 验证：我们在正确地构建产品吗？（Are we building the product right?） 确认：我们在构建正确的产品吗？（Are we building the right product?）,38,需求确认（Validation）与验证（Verification） 验证&确认之间的差异： 验证：意即开发的每个阶段都遵循过程和标准。质量是它的目标。 确认：意即整个产品和过程都迎合用户的需要。用户满意是它的目标。就是对软件需求分析规格说明书加以验证。 确认对于软件来说是很困难的 最好确认需求的方法是在需求检查过程中让客户参与。 需求验证要从以下方面进行：正确性，无二义性，完整性，可验证性，一致性，可量化性，可理解性，可修改性，唯一性，可跟踪性，设计无关性。,39,需求评审 需求确认和验证的手段。 应指定专门人员负责。 按规程严格进行。,40,需求评审的内容： 系统定义的目标是否与用户的要求一致； 系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求； 被开发项目的数据流与数据结构是否确定且充足； 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 设计的约束条件或限制条