03第三章需求工程.pptx

《03第三章需求工程.pptx》由会员分享，可在线阅读，更多相关《03第三章需求工程.pptx（159页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、2023/12/21第三章第三章 需求工程需求工程 主讲：任向民主讲：任向民 2023/12/22第三章第三章 需求工程需求工程3.1概述概述3.2需求获取方法需求获取方法3.3需求分析的任务与原则需求分析的任务与原则3.4需求建模方法需求建模方法3.5需求图形工具需求图形工具3.6需求验证需求验证3.7需求管理需求管理2023/12/233.1概述概述3.1.1 软件需求定义软件需求定义3.1.2软件需求分类软件需求分类3.1.3需求规格说明需求规格说明3.1.4需求工程概念需求工程概念3.1.5需求工程过程需求工程过程2023/12/245.2 软件需求的分类软件需求的定义2023/12/

2、253.1概述概述软件需求工程的目的是定义软件所需要解决软件需求工程的目的是定义软件所需要解决的问题的问题。软件需求是要把一个定义不足和模糊的问题软件需求是要把一个定义不足和模糊的问题转换为一个定义良好而准确的问题，进而找转换为一个定义良好而准确的问题，进而找到解决问题的方案。到解决问题的方案。2023/12/263.1概述概述主要困难主要困难：1.软件开发人员与用户双方固有的矛盾软件开发人员与用户双方固有的矛盾2.需求具有易变性和难以表述性需求具有易变性和难以表述性3.需求错误的高频性和修复的高成本性需求错误的高频性和修复的高成本性2023/12/27软件开发的目标是什么？开发高质量的软件；

3、在预定的时间和预算约束下完成；软件要能够满足顾客的需求。2023/12/28但实际情况是什么样子？调查报告的数字是这样的StandishGroup2004SucceededChallengedFailed用户参与程度高：16%用户高层的支持：14%对需求的清晰陈述：12%缺乏用户参与：13%需求规格说明不完整：12%需求频繁的发生变化：12%结论：结论：对用户需求的管理水平对用户需求的管理水平是决定软件成败的重要原因是决定软件成败的重要原因2023/12/29案例分析1“只有结婚后才可以修改姓名吗？”Phil开发了一套人力资源软件，有一天他接到了人力资源部Maria打来的电话Maria 一个同

4、事想把自己名字改为Sparkle Starlight，但系统不允许，能帮忙吗？Phil她嫁给了一个姓Starlight的人吗？Maria 不，她并没有结婚，她只是想改名字而已；Phil系统只支持在改变婚姻状况时才可以改名字。Maria 可是每个人只要愿意就可以随时改变自己的名字啊。Phil这并不是我的错！在开发系统之前，你从来没有向我提起过有这种需求！Maria 不管如何，请尽快把这个功能修改完毕，否则Sparkle无法支付她的银行帐单。Phil如果你一开始就告诉我你想随时改变某人的名字，那这些就都不会发生！2023/12/210“错误的需求”的扩散效应问题正确的需求错误的需求正确的设计基于“

5、错误的需求”的设计错误的设计基于“错误的设计”的编码正确的编码 错误的编码基于“错误的需求”的编码2023/12/211“错误的需求”的修复代价“构建一个软件系统最困难的部分是确定构建什么在出错之后会严重影响随后实现的系统，并且在以后的修补是如此的困难”2023/12/213根本原因是什么？需求的鸿沟(期望差异)：开发者开发的与用户所想得到的软件存在着巨大期望差异。2023/12/214什么是“软件需求”软件需求(Software Requirements)：用户解决问题以达到特定目标所需的能力；系统或系统构件要满足的合同、标准、规范或其他正式文档所需具备的能力；IEEE,1997指用户对软件

6、的功能与性能需求,就是用户希望软件能够做什么事情,完成哪些功能，达到哪些性能等。软件需求：以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。需求通常用于表达“做什么”，而不描述“如何做”。2023/12/216关于“需求”的例子Course Registration System(学生选课系统)某大学希望采用计算机管理学生的选课学生可以在一个学期开始之前选择该学期开设的某些课程老师可以使用选课系统获得选课学生的名单，并登记学生的课程学习成绩学生不希望自己的学习成绩被他人查阅(你可以补充吗？)以下描述是否属于需求？

7、为什么？系统通过JDBC与Oracle数据库CourseDB建立连接，并使用T-SQL语句从CourseOffering数据表中获得课程的开设信息。2023/12/2175.2 软件需求的分类软件需求的分类2023/12/218不同层次的软件需求2023/12/2191.业务需求业务需求(Business Requirements)：客户对于系统的高层次目标要求(high-level objectives)，定义了项目的远景和范畴(vision and scope)业务：属于哪类业务范畴？应完成什么功能？为何目的？客户：软件为谁服务？目标客户是谁？特性：区别于其他竞争产品的特性是什么？价值：价

8、值体现在那些方面？优先级：功能特性的优先级次序是什么？例“图书资料管理系统”的业务需求该系统使用计算机实现图书资料日常管理，提高工作效率和服务质量；该系统可让用户在网络上查询与浏览电子资料，改变原有的借阅模式；由于版权的限制，某些电子资料只能浏览/打印，但不能下载。2023/12/2202.用户需求(目标需求)用户需求(User Requirements)：从用户角度描述的系统功能需求与非功能需求，通常只涉及系统的外部行为而不涉及内部特性。例用户可以通过Internet随时查询图书信息和个人借阅情况，并可以快速查找和浏览需要的电子资料；功能需求用户通过Internet查询图书信息；功能需求用户

9、通过Internet浏览个人借阅情况；功能需求用户通过Internet查找和浏览电子资料；非功能需求随时、快速2023/12/221业务需求与用户需求的对比针对Course Registration System业务需求由于实行学分制管理，学校领导希望用计算机管理学生选课。课程信息维护、选课管理、课程成绩登记和查询等业务全部由手工方式改为计算机应用。用户需求教务管理员希望能够增加、修改和删除学校的课程目录，并且设置各学期课程的开设信息。学生希望能够在学期开始之前查询所有开设课程的详细信息，并能够通过校园网进行选课。学生希望在选课期间系统能够24小时使用，系统使用方便快捷。2023/12/222

10、3.功能需求功能需求(Functional Requirements,FR)：系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节；例用户可从图书资料库中查询或者选择其中一个子集；系统可提供适当的浏览器供用户阅读馆藏文献；用户每次借阅图书应对应一个唯一的标识号，它被记录到用户的账户上；2023/12/2234.非功能需求非功能需求(Non-Functional Requirements,NFR)：从各个角度对系统的约束和限制，反映了客户对软件系统质量和性能(quality and performance)的额外要求，如响应时间、数据精度、可靠性等。例系统

11、在20秒内响应所有的请求；系统应该每周7天、每天24小时都可使用；对一个没有经验的用户而言，经过2小时培训即可使用系统所有功能。注意：非功能需求隐含了对可选设计方案的一些关键影响体系结构设计(e.g.,体系结构风格选择)算法设计(e.g.,排序策略的选择)2023/12/224非功能需求的度量NFR：检验起来非常困难，一般采用一些可度量的特性进行描述。例如：即使对一个没有经验的用户，系统也应该很容易使用，且是用户错误降到最少；修改为：对一个没有经验的用户来说，经过2个小时的培训就应该使用系统的全部功能。在这样的培训之后，一个有经验的用户每天的出错平均数不应超过2次。2023/12/225NFR

12、：检验起来非常困难，一般采用一些可度量的特性进行描述。非功能需求的度量非功能特性度量指标速度 每秒处理的事务 用户的响应时间 屏幕的刷新速度存储空间 字节数 RAM芯片数可用性 培训时间 帮助页面数可靠性 平均失败时间 系统无效的概率 失败发生率容错性 失败后的重启次数 事件引起失败的比例 失败时数据崩溃的可能性2023/12/226一个例子：拼写检查器业务需求：“用户能有效地纠正文档中的拼写错误”；用户需求：“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”；功能性需求：找到拼写错误的单词并以高亮度提示显示提供替换词的对话框实现整个文档范围的替换非功能性需求：正确的找到至

13、少95%以上的错词并100%的加以正确替换拼写检查的速度应至少达到5000词/秒。2023/12/2275.约束条件约束条件(Constraints)：系统设计和实现时必须满足的限制条件，对其进行权衡或调整是相当困难的，甚至是不可能的；例如：系统必须用C+或其他面向对象语言编写；系统用户接口需要采用图形化界面；任取10秒，一个特定应用所消耗的可用计算能力平均不超过50%；系统开发过程和交付文档需遵循GB/T 8567-2006标准；通讯接口必须符合ISO七层架构。来源：法规政策、硬件/资源限制、开发语言、等等。2023/12/2286.业务规则业务规则(Business Rule)：对某些功能

14、的可执行性或内部执行逻辑的一些限定条件。通常表达为“如果，那么”的形式通常是一些容易发生变化的功能；例如：如果借书卡类型为“教师”，那么一次借阅的最大数量为8本；如果订单金额大于10000元，那么该订单的折扣为10%；如果采购单金额在10万到50万之间，那么需要总经理审批；2023/12/2297.外部接口需求外部接口需求(External Interface Requirement)：描述系统与其所处的外部环境之间如何进行交互，包括：用户接口需求(UI)硬件接口需求软件接口需求通信接口需求例如：“从读取信号”“给发送消息”“以读取文件”“能控制”“采用用户界面”2023/12/230关于需求

15、的一些例子系统必须有能力支持100个以上的并发用户，每个用户可以处理操作任务的任选组合，平均响应时间应该小于1秒，最大响应时间应小于5秒。必须在对话窗口的中间显示错误警告，使用红色的、14点加粗Arial字体。系统必须有能力存储平均操作连续100天所产生的事务。系统应该在5分钟内计算出给定季度的总销售税。系统应该在1分钟内从1000000条记录中检索出一个销售订单。系统必须支持100个Windows工作站的并行访问。系统可从各型号的modem上读取信号作为系统输入。2023/12/231需求规格说明2023/12/2323.1概述概述3.1.3需求规格说明需求规格说明需求规格说明是指软件所应满

16、足的需求规格说明是指软件所应满足的全部要求，并用文档方式完整和精全部要求，并用文档方式完整和精确描述。全部要求是指软件系统必确描述。全部要求是指软件系统必须提供的功能和性能、约束条件和须提供的功能和性能、约束条件和限制。限制。2023/12/2335.2 软件需求的分类好的需求 vs 坏的需求2023/12/234好的需求应具备的特征完整性：每一项需求都必须将所要实现的功能描述清楚正确性：每一项需求都必须准确地陈述其要开发的功能；可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来划分优先级：给每项需求、

17、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量无二义性：对所有需求说明的读者都只能有一个明确统一的解释可验证性：检查一下每项需求是否能通过设计测试用例或其它验证方法，如用演示、检测等来确定产品是否确实按需求实现2023/12/235产生不合格需求的原因无足够用户参与“我不明白为什么要花那么多功夫收集需求”“与其与用户讨论浪费时间，不如写代码有意思”“我已经明白用户需求了”用户需求的不断增加若不断增加新需求，项目就越来越庞大以致超过其计划及预算范围开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护2023/12/236产生不合格需求的原因模棱两可的需

18、求诸多读者对需求说明产生了不同的理解单个读者能用不止一个方式来解释某个需求说明后果：返工，重做一些你认为已做好的事情不必要的特性“画蛇添足”，开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能客户可能要求一些看上去很“酷”，但缺乏实用价值的功能，而实现这些功能只能徒耗时间和成本2023/12/237产生不合格需求的原因过于精简的规格说明给开发人员带来挫折，使他们在不正确的假设前提和极其有限的指导下工作给客户带来烦恼，他们无法得到他们所设想的产品忽略了用户分类软件由不同的人使用其不同的特性使用频繁程度有所差异使用者受教育程度和经验水平也不尽相同不准确的计划对需求分析缺乏理解会导致过

19、分乐观的估计原因：频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析2023/12/238案例分析2“他们忙，没有时间与你讨论需求”Contoso公司的CEO Gerhard约见软件开发小组Cynthia，商讨为公司开发新系统的事情Gerhard我们需要建立一套化学制品跟踪信息系统，可以记录并查询库房或某个实验室中已有的化学药品你们小组能在五个月内开发出该系统吗？Cynthia我已经明白这个项目的重要性了，但在我制定计划前，我们必须收集一些系统的需求。Gerhard你什么意思？我不是刚告诉你我的需求了吗？Cynthia你只说明了整个项目的概念与目标，这些高层次

20、的业务需求并不能为我们提供足够的详细信息以确定究竟要开发什么样的软件，以及需要多长时间。我需要一些分析人员与一些知道系统使用要求的化学专家进行讨论，然后才能真正明白达到业务目标所需的各种功能和用户的要求。Gerhard那些化学专家都非常忙，没有时间与你们详细讨论各种细节，你不能让你的手下的人说明要做的系统吗？Cynthia如果我们只是凭空猜想用户要求，结果不会令人满意。Gerhard行了，行了，我们没有那么多时间，我来告诉你需求，请马上开始开发系统，并随时将你们的进展情况告诉我。2023/12/239好需求与坏需求1.在现实情况中，用户存钱时并不需要信用检查，因此这个需求描述是错误的 2.“适

21、当的行动”对不同的人来说有不同的解释，显然是歧义的。改正：如果用户试图透支，系统将显示错误信息并拒绝取款操作。3.“尽快”是不可验证的，应该给出具体数量值。改正：系统将在20秒内响应所有有效的请求。4.与5是矛盾的。考虑以下需求是否满足“好需求”的标准，如不是，该如何修正？1.在用户每次存钱时系统将进行信用检查；2.如果用户试图透支，系统将采取适当的行动；3.系统将尽可能快的响应所有有效的请求；4.系统允许立即使用所存资金；5.只有在手工验证所存资金后，系统才能允许使用它；2023/12/240需求规格说明需求规格说明软件需求规格说明的一般格式软件需求规格说明的一般格式：1引言引言 2任务概述

22、任务概述 3数据描述数据描述 4功能要求功能要求 5性能需求性能需求 6运行需求运行需求 7其他要求（如可使用性、安全保密、可维护性、其他要求（如可使用性、安全保密、可维护性、可移植性等）可移植性等）8附录附录2023/12/241需求规格说明需求规格说明需求规格说明的特性如下：需求规格说明的特性如下：1完整性完整性2.正确性正确性3.可行性可行性4.必要性必要性5.无歧义性无歧义性6.可验证性可验证性7.划分优先级划分优先级2023/12/242需求工程2023/12/2433.1概述概述3.1.4 需求工程概念需求工程概念需求工程就是应用工程化的方法、技术和规格来开需求工程就是应用工程化的

23、方法、技术和规格来开发和管理软件的需求。发和管理软件的需求。需求工程的目标是获取高质量的软件需求。需求工程的目标是获取高质量的软件需求。需求工程突出了工程化原则，强调以系统化、条理需求工程突出了工程化原则，强调以系统化、条理化和重复化的方法进行软件需求的相关活动，从化和重复化的方法进行软件需求的相关活动，从而增强了管理性和降低了需求开发的成本而增强了管理性和降低了需求开发的成本 2023/12/2443.1概述概述3.1.4 需求工程概念需求工程概念需求工程的任务：需求工程的任务：1确定待开发的软件系统的用户，并获取确定待开发的软件系统的用户，并获取用户的需求信息。用户的需求信息。2分析用户的

24、需求信息，并按需求类型分分析用户的需求信息，并按需求类型分类，过滤掉非需求的信息。类，过滤掉非需求的信息。3根据需求信息建立软件系统的逻辑模型根据需求信息建立软件系统的逻辑模型和需求模型，确定非功能需求和约束条和需求模型，确定非功能需求和约束条件及限制。件及限制。2023/12/2453.1概述概述3.1.4 需求工程概念需求工程概念需求工程的任务：需求工程的任务：4根据收集的需求信息和逻辑模型编写需根据收集的需求信息和逻辑模型编写需求规格说明及文档。求规格说明及文档。5评审需求规格说明。评审需求规格说明。6当需求变更时，对需求规格说明及需求当需求变更时，对需求规格说明及需求变更实施进行管理。

25、变更实施进行管理。2023/12/2463.1概述概述3.1.5需求工程过程需求工程过程需求工程过程分为需求开发和需求管理两阶段。需求工程过程分为需求开发和需求管理两阶段。2023/12/2473.1概述概述3.1.5需求工程过程需求工程过程1.需求获取需求获取确定和确定和收集收集与待开发的软件系统相关的与待开发的软件系统相关的用户需求信息。用户需求信息。2.需求分析需求分析对获得的用户需求信息进行分析和综合，对获得的用户需求信息进行分析和综合，找出错误和冲突及遗漏的地方，获得用找出错误和冲突及遗漏的地方，获得用户的准确的需求，进而建立软件系统的户的准确的需求，进而建立软件系统的逻辑模型或需求

26、模型。逻辑模型或需求模型。3.需求定义需求定义利用描述语言、标准格式书写软件系统利用描述语言、标准格式书写软件系统的需求规格说明和文档。的需求规格说明和文档。2023/12/2483.1概述概述3.1.5需求工程过程需求工程过程4.需求验证需求验证审查和验证软件系统需求规格说明，进审查和验证软件系统需求规格说明，进而确定需求规格说明是否正确描述了用而确定需求规格说明是否正确描述了用户对软件系统的需求。户对软件系统的需求。5.需求管理需求管理需求管理的任务是管理软件系统的需求需求管理的任务是管理软件系统的需求规格说明和文档，评估需求变更带来的规格说明和文档，评估需求变更带来的影响及成本费用，跟踪

27、软件需求的状态，影响及成本费用，跟踪软件需求的状态，管理需求规格说明的版本等。管理需求规格说明的版本等。2023/12/249需求状态跟踪需求工程的总体流程需求获取需求分析需求规格说明(SRS)需求验证客户(client)终端用户(user)市场人员维护人员基线(baseline)需求管理需求变更过程需求变更项目变更需求开发需求开发需求管理需求管理2023/12/250需求开发所包含的活动确定产品所期望的用户类获取每个用户类的需求了解实际用户任务和目标以及这些任务所支持的业务需求分析源于用户的信息以区别用户需求、功能需求、非功能需求、约束条件、建议解决方法和附加信息将系统级的需求分为几个子系统

28、，并将需求中的一部份分配给软件构件了解相关非功能属性的重要性商讨实施优先级的划分将所收集的用户需求编写成规格说明和模型评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚2023/12/251(1)需求获取需求获取(Requirement Elicitation)：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求对用户进行分类聆听每一类用户的需求分析和整理所获取的需求形成文档化的描述签字确认2023/12/252(2)需求分析需求分析(Requirement Analysis)：对收集到的需求进行提炼、分析和审查，为

29、最终用户所看到的系统建立概念化的分析模型定义系统的边界建立软件原型分析需求可行性确定需求优先级建立需求分析模型创建数据字典 2023/12/253(3)形成需求规格说明需求规格说明(Software Requirement Specification,SRS)：需求开发的结果精确的、形式化的阐述一个软件系统必须提供的功能、非功能、所要考虑的限制条件等作为用户和开发者之间的一个契约是用户、分析人员和设计人员之间进行理解和交流的手段2023/12/254(4)需求验证需求验证(Requirement Verification)：以需求规格说明为输入，通过评审、模拟或快速原型等途径，分析需求规格的正

30、确性和可行性，发现存在的错误或缺陷并及时更改和补充。2023/12/255(5)需求管理需求管理(Requirement Management)定义需求基线(迅速制定需求文档的主体)评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它以一种可控制的方式将需求变更融入到项目中使当前的项目计划与需求一致估计变更需求所产生影响并在此基础上协商新的承诺(约定)让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪在整个项目过程中跟踪需求状态及其变更情况2023/12/256需求管理需求管理变更控制版本控制需求跟踪需求状态跟踪建议变更分析影响做出决策交流合并测量需求稳定性确定需求文档版

31、本定义对其他需求的连接链定义对其他系统元素的连接链定义需求状态跟踪需求状态2023/12/257需求管理与需求开发的关系2023/12/2583.2 需求获取方法需求获取方法2023/12/259需求获取的基本步骤了解领域背景知识客户分类(按角色)CxO部门经理业务员管理员交流需求纪要问题？分类整理功能需求非功能需求约束条件业务规则外部接口需求建议解决方案优先级排序冲突消解签字确认业务需求用户需求2023/12/260需求获取的基本步骤第1步：了解相关背景和领域/行业的知识，确定产品所期望的用户类；第2步：与客户企业或组织的高层人员进行交流，了解实际用户任务和目标以及这些任务所支持的业务需求；

32、第3步：与客户企业或组织的底层人员进行交流，获取每个用户类的详细的用户需求；第4步：整理需求纪要，发现新问题，并重复1-3步；第5步：需求分类和组织，以区别功能需求、非功能需求、约束条件、业务规则、外部接口需求、建议解决方法和附加信息；第6步：优先排序和冲突解决；第7步：得到最终需求清单，并与客户做最终签字确认。2023/12/261“看似简单，实际却很难”“需求获取？不就是问问题吗？这有什么难的？”2023/12/265需求获取技术需求获取的关键：沟通和交流所要避免的问题：交流障碍、沟通不全、意见冲突所要必备的条件：较高的技术水平、丰富的实践经验、较强的人际交往能力可能采取的手段：用户访谈、

33、现场考察、专家咨询、会议讨论、2023/12/266需求获取技术面对面访谈(face-to-face interviewing)专题讨论会(workshop)现场观察(observing on the scene)头脑风暴(brain storming)多种方法要复合在一起使用，效果更好2023/12/267面对面访谈2023/12/268面对面访谈需求获取中最直接的方法：用户面谈(interviewing)“看起来很美”，但“做起来并不容易”需求分析者个人的偏见、事先的理解、以往的经验积累是导致面谈失败的最重要原因在面谈时，忘掉一切以往所作的事情，通过问题启发，倾听对方的陈述不要把自己放在“

34、专家”的位置上2023/12/269如何提问？“每个人都能提问题，但并不等于人人都会提问题”封闭式问题：对错判断或多项选择题，回答只需要一两个词 开放式问题：这种问题需要解释和说明，同时向对方表示你对他们说的话很感兴趣，还想了解更多的内容。通过提问题增强你对谈话进展和方向的控制问题不能过于宽泛最开始的问题不能太难不能在提问之前就已经表示不赞同谈话之前有意识的准备一些备用问题2023/12/270访谈问题的分类上下文无关的问题(context-free questions)：充分理解用户的问题，不涉及具体的解决方案客户是谁？最终用户是谁？不同用户的需求是否不同？这种需求目前的解决方案是什么？解决

35、方案相关的问题(solution-context questions)：通过这类问题，探寻特定的解决方案并得到用户认可你希望如何解决这个问题？你觉得该问题这样解决如何？2023/12/271面谈之前确立面谈目的确定要包括的相关用户确定参加会议的项目小组成员建立要讨论的问题和要点列表复查有关文档和资料确立时间和地点通知所有参加者有关会议的目的、时间和地点2023/12/272面谈之中Step 1：事先准备一系列上下文无关的问题，并将其记录下来以便面谈时参考；Step 2：面谈前，了解一下要面谈的客户公司的背景资料，不要选择自己能回答的问题而浪费时间；Step 3：面谈过程中，参考事先准备的面谈模

36、板，以保证提出的问题是正确的。将答案记录到纸面上，并指出和记录下未回答条目和未解决问题；Step 4：面谈之后，分析总结面谈记录。2023/12/273面谈之后复查笔记的准确性、完整性和可理解性把所收集的信息转化为适当的模型和文档确定需要进一步澄清的问题域向参加会议的每一个人发出此次面谈的minutes(会议纪要)。2023/12/274面谈记录的示例(1)第一部分：建立客户或用户情况表第二部分：评估问题询问用户对哪些类型的问题缺乏好的解决方案它们是什么？(不断的问“还有吗？”)第三部分：理解用户环境谁是用户？他们的经历和经验如何？用户的预期如何？第四部分：扼要说明理解情况你刚才告诉我：(用自

37、己的话复述客户描述的问题)这是否足以表达你现在的解决方案中存在的问题？如果有，你还有什么问题？2023/12/275面谈记录的示例(2)第五部分：分析人员对客户问题的输入对每个问题进行以下提问：这是一个实际的问题吗？问题产生的原因是什么？现在如何解决的？希望如何解决？该问题的重要度如何？第六部分：评估自己的解决方案总结自己建议的解决方案；对自己方案的优先级排序；第七部分：评估机会第八部分：评估可靠性、性能及其他需要2023/12/276面谈记录的示例(3)第九部分：其他需求法律法规、环境、行业标准等；第十部分：总结性提问还有其他问题要问面谈人吗？尚未解决的问题有哪些？下次访谈的方式、地点、时间

38、、参加人等；第十一部分：分析人员的总结总结出客户/用户确认的三条优先级最高的需求或问题。2023/12/277面对面访谈的优缺点分析优点：人们很愿意谈论自己的工作，并且总是很喜欢接受访谈；缺点：大多数人都采用专业术语和“行话”，而太多的专业术语让需求工程师难以理解，往往造成很多误解；有些需求对用户来说太普通了，以至于他们不自觉地认为这些需求太基本，不值得去提。但它们对需求工程师来说却不是显而易见的。这往往会造成某些需求被忽略；2023/12/278需求研讨会(Workshop)2023/12/279需求研讨会(Workshop)2023/12/280需求研讨会(Workshop)通过让所有相关

39、人员一起参加某个单一会议来定义需求或设计系统，也称联合应用设计会议(Joint Application Design,JAD)。系统相关者在短暂而紧凑的时间段内集中在一起，一般为1至2天，与会者可以在应用需求上达成共识、对操作过程尽快取得统一意见。协助建立一支高效团队，围绕一个目的：项目的成功；所有人员都畅所欲言；促进用户与开发团队之间达成共识；能够揭露和解决那些妨碍项目成功的行政问题；最终很快产生初步的系统定义。2023/12/281需求研讨会(Workshop)专题讨论会准备参加会议人员：主持人、用户、技术人员、项目组人员安排日程通常在具有相应支持设备的专用房间进行举行会议可能出现人员之间

40、的责备或冲突，主持人应掌握讨论气氛并控制会场最重要的部分是自由讨论阶段，这种技术非常符合专题讨论会的气氛，并且营造一种创造性的和积极的氛围，同时可以获得所有相关者的意见分配会议时间，记录所有言论2023/12/282现场观察用户可能无法有效全面的表达自己的需求，通过面谈和会议也难以获得完整信息；在这种情况下，现场观察用户的工作流程有助于更深入全面了解需求。两种方式：被动观察：用户实地工作，需求分析人员在旁边看主动观察：需求分析人员直接参与用户的实际工作2023/12/283头脑风暴(Brainstorming)2023/12/284头脑风暴(Brainstorming)一般以8-12人最佳：人

41、数太少不利于交流信息和激发思维；人数太多则不容易掌握，并且每个人发言的机会相对减少 明确分工：1名主持人、2名记录员成功要点：自由畅谈延迟批判、禁止批评禁止批评、自我批评、自谦追求数量会后：修剪、分组、排序适用场合：产品型系统，需要具有创新性特征，尚未投放市场，无明确的客户。2023/12/2853.3 需求分析的任务与原则需求分析的任务与原则3.3.1需求分析的任务需求分析的任务3.3.2需求分析的原则需求分析的原则2023/12/286需求工程过程需求工程过程需求工程过程分为需求开发和需求管理两阶段。需求工程过程分为需求开发和需求管理两阶段。2023/12/2873.3 需求分析的任务与原

42、则需求分析的任务与原则3.3.1需求分析的任务需求分析的任务需求分析的基本任务是分析与综合已收集到的需需求分析的基本任务是分析与综合已收集到的需求信息，通过分析找出需求信息内在联系和可能求信息，通过分析找出需求信息内在联系和可能的矛盾，通过综合找出解决问题的方法并建立系的矛盾，通过综合找出解决问题的方法并建立系统的逻辑模型。统的逻辑模型。具体地说，需求分析是提炼、分析和审查已收集具体地说，需求分析是提炼、分析和审查已收集到的需求信息，找出真正的和具体的需求，并确到的需求信息，找出真正的和具体的需求，并确保所有相关人员都理解其含义。保所有相关人员都理解其含义。2023/12/2883.3 需求分

43、析的任务与原则需求分析的任务与原则3.3.1需求分析的任务需求分析的任务1.绘制系统关联图绘制系统关联图关联图是用于定义系统与系统外部实体间的界限关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。和接口的简单模型。2.创建用户接口原型创建用户接口原型当开发人员或用户不能确定软件需求时，开发一当开发人员或用户不能确定软件需求时，开发一个用户接口原型个用户接口原型(可能的局部实现可能的局部实现)，这样使得许，这样使得许多概念和可能发生的事更为直观明了。多概念和可能发生的事更为直观明了。2023/12/2893.3 需求分析的任务与原则需求分析的任务与原则3.3.1需求分析的任务需求分析的

44、任务3.分析需求可行性分析需求可行性在允许的成本、性能要求下，分析每项需求实施在允许的成本、性能要求下，分析每项需求实施的可行性。的可行性。4.确定需求的优先级确定需求的优先级应用分析方法来确定使用实例、产品特性或单项应用分析方法来确定使用实例、产品特性或单项需求实现的优先级。需求实现的优先级。5.为需求建立模型为需求建立模型需求的图形分析模型是软件需求规格说明的补充需求的图形分析模型是软件需求规格说明的补充说明。说明。2023/12/2903.3 需求分析的任务与原则需求分析的任务与原则3.3.1需求分析的任务需求分析的任务6.创建数据字典创建数据字典数据字典是对系统用到的所有数据项和结构的

45、定数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。义，以确保开发人员使用统一的数据定义。7.质量功能调配质量功能调配质量功能调配是一种高级系统技术，它将产品特质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的供了一种分析方法以明确那些是客户最为关注的特性。特性。2023/12/2913.3 需求分析的任务与原则需求分析的任务与原则3.3.2 需求分析的原则需求分析的原则1必必须须能能够够表表达达和和理理解解问问题题的的数数据据域域和功能域和功能域

46、对对于于计计算算机机程程序序处处理理的的数数据据，其其数数据据域域应应包包括括数数据据流流、数数据据内内容容和和数数据据结结构构。就就是是将将一一种种形形式式的的数数据据转转换换成成另另一一种种形形式式的的数数据。据。2023/12/2923.3 需求分析的任务与原则需求分析的任务与原则3.3.2 需求分析的原则需求分析的原则2.按自顶向下、逐层分解问题按自顶向下、逐层分解问题 分分解解问问题题是是把把问问题题以以某某种种方方式式分分解解为为几几个个较较易易理理解解的的部部分分，并并确确定定各各部部分分间间的的接接口口，从而实现整体功能。从而实现整体功能。在在需需求求分分析析阶阶段段，软软件件

47、的的功功能能域域和和信信息息域域都都能能做做进进一一步步的的分分解解。这这种种分分解解可可以以是是同同一一层层次次上上的的，称称为为横横向向分分解解；也也可可以以是是多多层次的纵向分解。层次的纵向分解。2023/12/2933.3 需求分析的任务与原则需求分析的任务与原则3.3.2 需求分析的原则需求分析的原则3.要给出系统的逻辑视图和物理视图要给出系统的逻辑视图和物理视图这这对对系系统统满满足足处处理理需需求求所所提提出出的的逻逻辑辑限限制制条条件件和和系系统统中中其其他他成成分分提提出出的的物物理理限限制制条条件是必不可少的。件是必不可少的。软软件件需需求求的的逻逻辑辑视视图图给给出出软软

48、件件要要达达到到的的功能和要处理数据之间的关系。功能和要处理数据之间的关系。软软件件需需求求的的物物理理视视图图给给出出处处理理功功能能和和数数据据结构的实际表示形式。结构的实际表示形式。2023/12/2943.4需求建模方法需求建模方法3.4.1结构化需求建模方法结构化需求建模方法 3.4.2数据流图数据流图 3.4.3数据字典数据字典 2023/12/2953.4需求建模方法需求建模方法需求建模方法的共同特性需求建模方法的共同特性：1提供描述手段提供描述手段2提供基本步骤提供基本步骤建建模模方方法法主主要要包包括括结结构构化化的的需需求求建建模模方方法法和面向对象的需求建模方法和面向对象

49、的需求建模方法 2023/12/2963.4需求建模方法需求建模方法3.4.1结构化需求建模方法结构化需求建模方法基基本本特特点点是是表表达达问问题题时时尽尽可可能能使使用用图图形形符符号号的的形形式式，设设计计数数据据流流图图时时只只考考虑虑系系统统必必须须完完成成的的基基本本功功能能，不不必必考考滤滤如如何何具具体体实实现这些功能。现这些功能。基基本本思思想想是是按按照照由由抽抽象象到到具具体体、逐逐层层分分解解的的方方法法，确确定定软软件件系系统统内内部部的的数数据据流流、变变换关系，并用数据流图表示。换关系，并用数据流图表示。描描述述手手段段 一一套套分分层层的的数数据据流流图图 一一

50、本本词典词典 其他补充材料其他补充材料 2023/12/297数据流图(DFD)数据流图(Data Flow Diagram,DFD)：结构化系统分析的基本工具描绘数据在系统中各逻辑功能模块之间的流动和处理过程，是一种功能模型主要刻画“功能的输入和输出数据”、“数据的源头和目的地”2023/12/298DFD的主要元素销售订单1录入订单销售订单客户数据流加工数据存储外部实体2023/12/299DFD的主要元素(1)：加工加工(又称数据处理，data processing)：对数据流进行某些操作或变换。收集、排序、选择、聚集、分析等加工要有名字，通常是动词短语，简明地描述完成什么事情在分层的数