第二章2系统—需求

1、第二章第二章 系统分析系统分析需求分析需求分析本节主要内容：本节主要内容：n需求分析的目的和任务n需求工程一般过程n内容层次与来源n需求调研n需求建模n需求规格说明书n需求管理为什么要进行需求分析？修复成本修复成本n是获得用户需求的有效途径是获得用户需求的有效途径n是决定项目成功与否的关键因素是决定项目成功与否的关键因素n是系统分析和设计的桥梁和依据是系统分析和设计的桥梁和依据n是控制软件质量的重要阶段是控制软件质量的重要阶段1、需求分析的目标和任务、需求分析的目标和任务n软件需求分析的对象是软件需求分析的对象是用户要求用户要求。n其任务是其任务是要准确地定义新系统的目标要准确地定义新系统的目

2、标。回答系统。回答系统必须必须“做什么做什么”的问题并编制需求规格说明书。的问题并编制需求规格说明书。n作为目标系统的参考，需求分析的任务就是借助作为目标系统的参考，需求分析的任务就是借助于（业务）系统的逻辑模型导出目标系统的于（业务）系统的逻辑模型导出目标系统的逻辑逻辑模型模型，解决目标系统的，解决目标系统的“做什么做什么”的问题。的问题。 需求分析的目标需求分析的目标1、需求分析的目标和任务、需求分析的目标和任务1、需求分析的目标和任务、需求分析的目标和任务（1 1）获得当前系统的物理模型获得当前系统的物理模型：分析、理解当前系分析、理解当前系统（人工处理或原有系统）是如何运行的，了解其统

3、（人工处理或原有系统）是如何运行的，了解其组织机构、输入输出、资源利用情况和日常数据处组织机构、输入输出、资源利用情况和日常数据处理过程理过程 。（2 2）抽象出当前系统的逻辑模型抽象出当前系统的逻辑模型：在理解当前系统在理解当前系统“怎样做怎样做”的基础上，抽取其的基础上，抽取其“做什么做什么”的本质的本质 。 （3 3）建立目标系统的逻辑模型建立目标系统的逻辑模型：分析目标系统与当分析目标系统与当前系统逻辑上的差别，明确目标系统到底要前系统逻辑上的差别，明确目标系统到底要“做什做什么么”，进而从当前系统的逻辑模型导出目标系统的，进而从当前系统的逻辑模型导出目标系统的逻辑模型。逻辑模型。 （

4、4 4）对逻辑模型的补充对逻辑模型的补充 ：包括说明目标系统的用户包括说明目标系统的用户界面界面 、系统细节和性能限制等。、系统细节和性能限制等。2、需求工程、需求工程n软件系统的需求分析是一系列复杂的软件工程活动，为了便于对需求进行更好的管理，人们把所有与需求直接相关的活动通称为需求工程。需求分析需求分析需求工程需求工程nMatthias JarkeMatthias Jarke和和Klaus PohlKlaus Pohl提出了三提出了三阶段周期的说法：阶段周期的说法：获取、表示和验证获取、表示和验证 nHerb KrasnerHerb Krasner定义了需求工程的五阶段定义了需求工程的五阶

5、段生命周期：生命周期：需求定义和分析、需求决策、需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求形成需求规格、需求实现与验证、需求演进管理演进管理n Alan Davis Alan Davis 把需求工程定义为把需求工程定义为“直到直到（但不包括）把软件分解为实际架构构（但不包括）把软件分解为实际架构构件之前的件之前的所有活动所有活动” ” n 需求工程需求工程需求开发需求开发需求管理需求管理u需求工程的主要阶段需求工程的主要阶段需求获取需求获取需求分析需求分析需求规约需求规约需求验证需求验证变更控制变更控制版本控制版本控制需求跟踪需求跟踪需求状态跟踪需求状态跟踪需求规格说明书需求

6、规格说明书需求开发需求开发重复过程需求获取需求分析需求规约需求验证需求开发过程需求获取 搜集与探索需求的过程需求分析 检视需求的过程需求规约 创建软件和系统规范文档的过程需求验证 帮助确定实现了正确的需求n需求获取需求获取 从众从众利益相关者利益相关者处收集开发和文档处收集开发和文档所需要的信息；所需要的信息；n需求分析需求分析 分类分类诸需求，诸需求，建建立需求立需求模模型，将它型，将它们们分配分配到软件的架构设计中，并在各利益相关者到软件的架构设计中，并在各利益相关者间权衡间权衡协商；协商；n需求编制需求编制 创建出以一种合适方式记录的用于创建出以一种合适方式记录的用于软件进一步的设计与维

7、护的软件和系统规范；软件进一步的设计与维护的软件和系统规范；n需求验证需求验证 使用模型，复核，原型以及最终产使用模型，复核，原型以及最终产品的最终验收测试来检验和确认需求的正确性。品的最终验收测试来检验和确认需求的正确性。需求开发典型利益相关者典型利益相关者角色需求的用途项目领导人确定范围和创建项目计划获得项目所有者的同意追踪进度分析师捕获需求分解需求开发团队按需求设计和编写代码高效设计和重用测试团队验证与需求的一致性传统团队确保与传统的整合维护团队向用户提供产品支持确保改变符合需求项目出资方提供动力和结约需求管理需求管理n对需求的改动是不避免的，尤其是在大型系统中对需求的改动是不避免的，尤

8、其是在大型系统中在项目一开始便定义或收集到所用的需求是困难的在项目一开始便定义或收集到所用的需求是困难的随着问题逐渐清晰，需求也会被添加、删除或修改随着问题逐渐清晰，需求也会被添加、删除或修改n需求管理通过一种称为需求管理通过一种称为变更管理变更管理的过程来提供对这些的过程来提供对这些变动的支持变动的支持变更控制变更控制版本控制版本控制可追踪性可追踪性状态跟踪状态跟踪3、需求分析的内容与来源、需求分析的内容与来源非功能需求非功能需求包括必须遵从的标准、规范、约束，操作界面的具体细节包括必须遵从的标准、规范、约束，操作界面的具体细节和构造上的限制等。和构造上的限制等。组织机构或用户对组织机构或用

9、户对系统的高层次目标要求系统的高层次目标要求用户使用系统必须用户使用系统必须要完成的任务要完成的任务必须要实现的软件必须要实现的软件功能功能n内容层次内容层次常见非功能需求常见非功能需求可用性计划开机时长，平均故障时间间隔，MTBFMTBF等高效性系统如何高效利用处理器、磁盘空间、通讯带宽灵活性向产品中加入其它功能需要多大努力完整性阻止未经授权的访问、修改互操作性与其他系统交换数据或服务可靠性无错误的软件执行稳健性系统遭遇无效数据或其他干扰时继续正常运作的程度易用性用户友好易于使用，符合人机工程维护性是否易于修正一个缺陷或改动软件移植性把软件从一个操作系统移植到另一个所需的努力, ,支持平台数

10、重用性为某个应用所设计的模块能被其他应用重复所用的程度可测性测试软件模块或者所整合产品的难易度量化需求量化需求需求类型测量范例观感接受率易用性错误率性能与速度响应时间可靠性停工时间移植性平台数稳健性致命/ /非致命错误比例维护性修改所需的时间和工作量大小源代码行数（Source lines of Source lines of codecode，SLOCSLOC）认证所符合的诸标准n需求的来源需求的来源n用户或潜在用户用户或潜在用户n竞争对手同类产品竞争对手同类产品n分析人员的经验分析人员的经验n市场支持活动市场支持活动n政策制度和法律法规政策制度和法律法规4、需求调研、需求调研p识别调研范围

11、识别调研范围p组建调研团队组建调研团队p确定调研方案确定调研方案p调研准备调研准备p前期沟通前期沟通（1）识别调研范围）识别调研范围n决定了需求调研决定了需求调研对象对象、调研、调研参与人员参与人员和调研和调研周期周期的长短；的长短； n划分了调研划分了调研内容边界内容边界，决定了本次调研的主要内，决定了本次调研的主要内容；容；可以依据产品范围和预期目标，分析目标组织特征和可以依据产品范围和预期目标，分析目标组织特征和业务特征业务特征, ,确定需求调研范围，划分清楚调研业务边界。确定需求调研范围，划分清楚调研业务边界。n当调研范围过大当调研范围过大 时，把调研范围划分成若干个时，把调研范围划分

12、成若干个业业务域务域，识别其中关键的业务域，确定调研重点，识别其中关键的业务域，确定调研重点，便于调研过程的控制便于调研过程的控制 。 （2）组建调研团队）组建调研团队n可视项目大小和复杂程度确定人员要求和数量。可视项目大小和复杂程度确定人员要求和数量。 n参与方主要包括：参与方主要包括：业务用户：业务用户：由熟悉调研范围相关业务实际工作的用户由熟悉调研范围相关业务实际工作的用户组成，负责提出需求，评审需求结果组成，负责提出需求，评审需求结果, ,协助调研实施人协助调研实施人员完成需求调研工作。至少包含三类人：对项目有决员完成需求调研工作。至少包含三类人：对项目有决定权的领导、熟悉业务流程的专

13、家、系统最终用户。定权的领导、熟悉业务流程的专家、系统最终用户。 调研实施人员：调研实施人员：由熟悉调研业务领域人员组成，负责由熟悉调研业务领域人员组成，负责组织、协调和开展需求调研工作，记录调研内容，编组织、协调和开展需求调研工作，记录调研内容，编写需求说明书。至少包含三类人：技术人员、业务人写需求说明书。至少包含三类人：技术人员、业务人员和管理者。员和管理者。 需求调研管理人员：需求调研管理人员：负责需求调研工作的整体工作部负责需求调研工作的整体工作部署，重大业务、进度等事项的协调，调研进度和质量署，重大业务、进度等事项的协调，调研进度和质量的控制。的控制。 （3）确定调研方案）确定调研方

14、案n调研方式调研方式主导型主导型n用户经验不足，认识不清晰，需要调研人员整理需用户经验不足，认识不清晰，需要调研人员整理需求概要内容，提交给用户进行分析和初步确认，最求概要内容，提交给用户进行分析和初步确认，最终由用户和调研实施人员对需求内容进行细化、确终由用户和调研实施人员对需求内容进行细化、确认的过程。认的过程。 n对调研人员要求较高；对调研人员要求较高；n与用户真实意图可能存在偏差。与用户真实意图可能存在偏差。（3）确定调研方案）确定调研方案n调研方式调研方式引导型引导型n用户有较为完整、系统的知识、经验积累，调研人用户有较为完整、系统的知识、经验积累，调研人员引导用户将需求阐述完整、清

15、晰，最终由用户对员引导用户将需求阐述完整、清晰，最终由用户对需求进行确认的过程称之为引导型调研。需求进行确认的过程称之为引导型调研。 n用户和调研实施人员相互配合程度高用户和调研实施人员相互配合程度高 ；n此种调研方式的进度和质量风险最小此种调研方式的进度和质量风险最小 。（3）确定调研方案）确定调研方案n调研方式调研方式被动型被动型n业务用户强势，且在调研领域内知识、经验丰富，业务用户强势，且在调研领域内知识、经验丰富，对未来建设系统有较为清晰的认识，在调研过程中对未来建设系统有较为清晰的认识，在调研过程中采取由业务用户主动说明、阐述需求，调研人员记采取由业务用户主动说明、阐述需求，调研人员

16、记录、分析需求的方式，或由业务用户按照调研实施录、分析需求的方式，或由业务用户按照调研实施人员要求出具需求的方式，称之为被动型调研人员要求出具需求的方式，称之为被动型调研 。 n对调研人员要求最低，但调研人员不能掌握调研进对调研人员要求最低，但调研人员不能掌握调研进度，无法对收集到的需求质量进行判断，因而进度度，无法对收集到的需求质量进行判断，因而进度风险较大。风险较大。 n需要提前做好调研提纲，以便把握进度和质量。需要提前做好调研提纲，以便把握进度和质量。（3）确定调研方案）确定调研方案n调研方法调研方法实地观察法实地观察法面谈法面谈法 问卷调查法问卷调查法 查阅资料法查阅资料法 n访问调查

17、宜采用访问调查宜采用直接面谈直接面谈，并且使用非标准化的，并且使用非标准化的方式，这样便于发挥和沟通，通过调研过程的互方式，这样便于发挥和沟通，通过调研过程的互动，可以激发调研对象积极性，收获调研实施前动，可以激发调研对象积极性，收获调研实施前遗漏的需求；遗漏的需求；n问卷调查法问卷调查法是标准化调查，可作为一种辅助手段，是标准化调查，可作为一种辅助手段，对于较为复杂的系统调研，不建议问卷调查作为对于较为复杂的系统调研，不建议问卷调查作为唯一调研方法；唯一调研方法；n而而实地观察法实地观察法和和查阅资料查阅资料法，作为由调研人员主法，作为由调研人员主动实施的调研方法，依赖于调研人员的主观判断，

18、动实施的调研方法，依赖于调研人员的主观判断，有一定局限性，可作为一种辅助手段对收集需求有一定局限性，可作为一种辅助手段对收集需求进行判断。进行判断。 （4）调研前准备）调研前准备n1 1、编制需求调研计划、编制需求调研计划 n2 2、编制调研活动使用的文档模版、编制调研活动使用的文档模版 ，例例n3 3、准备调研过程使用的工具、准备调研过程使用的工具 n4 4、制作调研提纲、制作调研提纲 n1 1） 调研对象的基本情况调研对象的基本情况 n2 2） 调研对象的预期目标调研对象的预期目标 n3 3） 调研业务的功能需求调研业务的功能需求 n4 4） 调研业务的非功能需求调研业务的非功能需求 n5

19、 5、调研背景培训、调研背景培训 调研实施调研实施inging5、需求建模、需求建模n结构化分析方法结构化分析方法SASAn面向数据结构的分析方法面向数据结构的分析方法n面向对象的分析方法面向对象的分析方法OOAOOA例：业务流程刻画例：业务流程刻画图例说明图例说明6、需求定义与评审、需求定义与评审n又称又称需求规格说明需求规格说明或需求规约。或需求规约。n需求定义的主要目的是需求定义的主要目的是分析需求草稿和模型分析需求草稿和模型，解，解决其中存在的二义性和不一致性，系统、准确地决其中存在的二义性和不一致性，系统、准确地表达系统需求，形成需求规格说明书。包括：表达系统需求，形成需求规格说明书

20、。包括： 系统应提供的功能和服务；系统应提供的功能和服务； 非功能需求；非功能需求； 系统开发或运行的限制条件；系统开发或运行的限制条件； 与系统互连的其他系统的信息与系统互连的其他系统的信息。n软件需求规格说明的基本原则：软件需求规格说明的基本原则：功能与实现分离功能与实现分离，描述要，描述要“做什么做什么”而不而不是是“怎样实现怎样实现”。要求使用面向处理的规格说明要求使用面向处理的规格说明语言语言，从而，从而得到得到“做什么做什么”的规格说明。的规格说明。如果目标软件只是一个如果目标软件只是一个大系统大系统中的一个元中的一个元素，那么整个大系统也包括在规格说明的素，那么整个大系统也包括在

21、规格说明的描述之中。描述之中。规格说明必须包括系统规格说明必须包括系统运行的环境运行的环境。（1）需求规格说明的原则）需求规格说明的原则系统规格说明必须是一个认识的模型，而不系统规格说明必须是一个认识的模型，而不是设计或实现的模型。是设计或实现的模型。规格说明必须是可操作的。规格说明必须是可操作的。规格说明必须容许不完备性并允许扩充。规格说明必须容许不完备性并允许扩充。规格说明必须局部化和松散的耦合。当信息规格说明必须局部化和松散的耦合。当信息被修改时，只要修改某个单个的段落，能够被修改时，只要修改某个单个的段落，能够很容易地加入和删去一些段落。很容易地加入和删去一些段落。（2）需求规格说明的

22、内容）需求规格说明的内容基于基于IEEE 830改写的规格说明模板内容：改写的规格说明模板内容：n引言引言a.1 目的目的a.2 文档约定文档约定 a.3 预期的读者和阅读建议预期的读者和阅读建议a.4 产品的范围产品的范围a.5 参考文献参考文献n综合描述综合描述 b.1 产品的前景产品的前景 b.2 产品的功能产品的功能b.3 用户类和特征用户类和特征b.4 运行环境运行环境b.5 设计和实现的限制设计和实现的限制b.6 假设和依赖假设和依赖c. 外部接口外部接口 c.1 用户界面用户界面 c.2 硬件接口硬件接口 c.3 软件接口软件接口 c.4 通信接口通信接口d. 系统特性系统特性

23、d.1 说明和优先级说明和优先级d.2 激励响应序列激励响应序列d.3 功能需求功能需求e. 其他非功能需求其他非功能需求 e.1 性能需求性能需求 e.2 基本设施需求基本设施需求 e.3 安全性需求安全性需求 e.4 软件质量属性软件质量属性 e.5 业务规则业务规则 e.6 用户文档用户文档f. 其他需求其他需求附录附录A：词汇表：词汇表附录附录B: 软件需求分析模型软件需求分析模型附录附录C: 待确定的问题待确定的问题常用模板常用模板案例案例n又称又称需求评审需求评审。需求评审的目的是确保需求编写。需求评审的目的是确保需求编写正确。审查的内容包括：正确。审查的内容包括：系统定义的系统定

24、义的目标目标是否与用户的要求是否与用户的要求一致一致；需求分析阶段提供的需求分析阶段提供的文档文档资料是否资料是否齐全齐全；文档中的所有文档中的所有描述描述是否是否完整、清晰、准确完整、清晰、准确反反映用户要求；映用户要求；1)与所有其它系统成分的重要与所有其它系统成分的重要接口接口是否都已经描述；是否都已经描述；（3） 需求验证需求验证主要主要功能功能是否已包括在规定的软件范围之是否已包括在规定的软件范围之内，是否都已充分说明；内，是否都已充分说明；软件的软件的行为行为和它必须处理的信息、必须完和它必须处理的信息、必须完成的功能是否一致；成的功能是否一致；设计的设计的限制条件限制条件是否符合

25、实际；是否符合实际；是否考虑了开发的技术风险；是否考虑了开发的技术风险；是否详细制定了是否详细制定了检验标准检验标准，它们能，它们能否对系统定义是否成功进行确认；否对系统定义是否成功进行确认；（3） 需求验证需求验证6. 需求管理需求管理n需求管理就是需求管理就是管理需求变化的过程管理需求变化的过程。n需求管理涉及需求变更如何被处理的策略、需求管理涉及需求变更如何被处理的策略、规程和过程。它规定了规程和过程。它规定了应如何提交一个需求变更请求？应如何提交一个需求变更请求？如何分析需求变更对范围、进度和成本的如何分析需求变更对范围、进度和成本的影响？影响？如何批准或驳回需求变更？如何批准或驳回需

26、求变更？如果批准了变更，变更如何实现？如果批准了变更，变更如何实现？需求管理需求管理l建议变更建议变更l分析影响分析影响l做出决策做出决策l交流交流l合并合并l测量需求测量需求 的稳定性的稳定性变更控制变更控制l确定需求确定需求 文档版本文档版本l确定单个确定单个需求文档版本需求文档版本版本控制版本控制l定义对其他定义对其他 需求的连接链需求的连接链l定义对其他定义对其他 系统元素的系统元素的 连接链连接链需求跟踪需求跟踪l定义需求状态定义需求状态l跟踪需求的跟踪需求的 每一个状态每一个状态需求状态跟踪需求状态跟踪6. 需求管理需求管理n变更管理的方法和手段变更管理的方法和手段（1 1）确定需

27、求变更控制过程）确定需求变更控制过程（2 2）建立变更控制委员会）建立变更控制委员会（3 3）进行需求变更影响分析）进行需求变更影响分析（4 4）跟踪所有受需求变更影响的工作产品）跟踪所有受需求变更影响的工作产品（5 5）建立需求基线和需求控制版本文档）建立需求基线和需求控制版本文档（6 6）维护需求变更的历史记录）维护需求变更的历史记录（7 7）跟踪每项需求的状态）跟踪每项需求的状态（8 8）衡量需求稳定性）衡量需求稳定性（9 9）使用需求管理工具）使用需求管理工具6. 需求管理需求管理停车场收费的业务流程停车场收费的业务流程一、入场：一、入场：1.1.有车辆进入；有车辆进入；2.2.判断是临时车辆还是固定车辆；判断是临时车辆还是固定车辆；3.3.若是临时车辆，发进车单，写明若是临时车辆，发进车单，写明车号、入场时间等，然后放行；车号、入场时间等，然后放行；4.4.若是固定车辆，检查车证看是否若是固定车辆，检查车证看是否过期，若正常，放行；若过期，提过期，若正常，放行；若过期，提醒续费，本次按临时车辆处理。醒续费，本次按临时车辆处理。二、出场：二、出