第三章需求工程课件

《第三章需求工程课件》由会员分享，可在线阅读，更多相关《第三章需求工程课件（158页珍藏版）》请在装配图网上搜索。

1、Click to edit Master title style,,Click to edit Master text styles,,Second level,,Third level,,Fourth level,,Fifth level,,*,王克朝 软件工程导论之需求工程,*,2024/11/27,1,第三章,需求工程,,,,,主讲：任向民,,,,,2024/11/27,2,第三章,需求工程,3.1,概述,,3.2,需求获取方法,,3.3,需求分析的任务与原则,,3.4,需求建模方法,,3.5,需求图形工具,,3.6,需求验证,,3.7,需求管理,2024/11/27,3,3.1,概述,

2、,3.1.1,软件需求定义,3.1.2,软件需求分类,3.1.3,需求规格说明,3.1.4,需求工程概念,3.1.5,需求工程过程,2024/11/27,4,5.2,软件需求的分类,软件需求的定义,2024/11/27,5,3.1,概述,软件需求工程的目的是定义软件所需要解决的问题 。,,软件需求是要把一个定义不足和模糊的问题转换为一个定义良好而准确的问题，进而找到解决问题的方案。,2024/11/27,6,3.1,概述,主要困难 ：,,,软件开发人员与用户双方固有的矛盾,,需求具有易变性和难以表述性,,需求错误的高频性和修复的高成本性,2024/11/27,7,软件开发的目标是什么？,开发高

3、质量的软件；,,在预定的时间和预算约束下完成；,,软件要能够满足顾客的需求。,,,2024/11/27,8,但实际情况是什么样子？,调查报告的数字是这样的,…,,,51%,15%,34%,Standish Group 2004,Succeeded,Challenged,Failed,用户参与程度高：,16%,用户高层的支持：,14%,,对需求的清晰陈述：,12%,,缺乏用户参与：,13%,需求规格说明不完整：,12%,,需求频繁的发生变化：,12%,,结论：,,对用户需求的管理水平,,是决定软件成败的重要原因,2024/11/27,9,[,案例分析,1] “,只有结婚后才可以修改姓名吗？”,P

4、hil,开发了一套人力资源软件，有一天他接到了人力资源部,Maria,打来的电话,…,Maria,一个同事想把自己名字改为,Sparkle Starlight,，但系统不允许，能帮忙吗？,Phil,她嫁给了一个姓,Starlight,的人吗？,Maria,不，她并没有结婚，她只是想改名字而已；,Phil,系统只支持在改变婚姻状况时才可以改名字。,Maria,可是每个人只要愿意就可以随时改变自己的名字啊。,Phil,这并不是我的错！在开发系统之前，你从来没有向我提起过有这种需求！,Maria,不管如何，请尽快把这个功能修改完毕，否则,Sparkle,无法支付她的银行帐单。,Phil,如果你一开始

5、就告诉我你想随时改变某人的名字，那这些就都不会发生！,……,,2024/11/27,10,“错误的需求”的扩散效应,问题,,正确的需求,,错误的需求,,,正确的设计,,基于“错误的需求”,,的设计,错误的设计,基于“错误的,,设计”的编码,正确的编码,,,,,错误的编码,基于“错误的需求”,的编码,2024/11/27,11,“错误的需求”的修复代价,“构建一个软件系统最困难的部分是确定构建什么,…,在出错之后会严重影响随后实现的系统，并且在以后的修补是如此的困难,…”,2024/11/27,12,“错误的需求”所带来的后果,早期的需求错误可能造成,,重新进行规格说明、设计、编码和测试,,改变

6、订单：告诉用户和操作员用一个修正后的版本来代替有缺陷的版本,,纠正活动：消除由于不正确的系统错误造成的一切危害，可能涉及到赔偿客户损失以及重新运行系统等,,报废：即使设计、代码和测试完成得很好，由于它们是根据不正确的需求产生的，所以不得不被丢弃,,收回有缺陷的软件产品以及相关的用户手册,,技术人员为客户重新安装新软件所必须支付的服务成本,2024/11/27,13,根本原因是什么？,需求的鸿沟,(,期望差异,),：,,开发者开发的与用户所想得到,,的软件存在着巨大期望差异。,2024/11/27,14,什么是“软件需求”,软件需求,(Software Requirements),：,,用户解决

7、问题以达到特定目标所需的能力；,,系统或系统构件要满足的合同、标准、规范或其他正式文档所需具备的能力；,——IEEE, 1997,,指用户对软件的功能与性能需求,,,就是用户希望软件能够做什么事情,,,完成哪些功能，达到哪些性能等,。,,软件需求：,以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。,,,需求通常用于表达,“做什么”,，而不描述“,如何做,”。,,2024/11/27,15,“软件需求”的作用,“,Requirement is the Basics of Quality”,,充分理解现实中的业务问

8、题，并作为软件设计的基础；,,为软件项目的成本、时间、风险估计提供准确的依据；,,减少开发工作量，避免将时间与资源浪费在设计与实现错误的需求上；,,通过提供需求文档和需求基线，来有效的管理系统演化与变更；,,作为顾客与开发团队之间正式合同的一部分；,,为最终的验收测试提供标准和依据；,2024/11/27,16,关于“需求”的例子,Course Registration System(,学生选课系统,),,某大学希望采用计算机管理学生的选课,,学生可以在一个学期开始之前选择该学期开设的某些课程,,老师可以使用选课系统获得选课学生的名单，并登记学生的课程学习成绩,,学生不希望自己的学习成绩被他人

9、查阅,,……(,你可以补充吗？,),,,以下描述是否属于需求？为什么？,,系统通过,JDBC,与,Oracle,数据库,CourseDB,建立连接，并使用,T-SQL,语句从,CourseOffering,数据表中获得课程的开设信息。,,2024/11/27,17,5.2,软件需求的分类,软件需求的分类,2024/11/27,18,不同层次的软件需求,2024/11/27,19,1.,业务需求,业务需求,(Business Requirements),：,客户对于系统的,高层次目标要求,(high-level objectives),,，定义了项目的,远景和范畴,(vision and sco

10、pe),,业务：属于哪类业务范畴？应完成什么功能？为何目的？,,客户：软件为谁服务？目标客户是谁？,,特性：区别于其他竞争产品的特性是什么？,,价值：价值体现在那些方面？,,优先级：功能特性的优先级次序是什么？,,,[,例,]“,图书资料管理系统”的业务需求,,该系统使用计算机实现图书资料日常管理，提高工作效率和服务质量；,,该系统可让用户在网络上查询与浏览电子资料，改变原有的借阅模式；,,由于版权的限制，某些电子资料只能浏览,/,打印，但不能下载。,2024/11/27,20,2.,用户需求,(,目标需求,),用户需求,(User Requirements),：,从用户角度描述的,系统功能需

11、求与非功能需求,，通常只涉及系统的,外部行为,而不涉及内部特性。,,,[,例,],用户可以通过,Internet,随时查询图书信息和个人借阅情况，并可以快速查找和浏览需要的电子资料；,,[,功能需求,],用户通过,Internet,查询图书信息；,,[,功能需求,],用户通过,Internet,浏览个人借阅情况；,,[,功能需求,],用户通过,Internet,查找和浏览电子资料；,,[,非功能需求,],随时、快速,2024/11/27,21,业务需求与用户需求的对比,针对,Course Registration System,,,业务需求,,由于实行学分制管理，学校领导希望用计算机管理学生选

12、课。,,课程信息维护、选课管理、课程成绩登记和查询等业务全部由手工方式改为计算机应用。,,用户需求,,教务管理员希望能够增加、修改和删除学校的课程目录，并且设置各学期课程的开设信息。,,学生希望能够在学期开始之前查询所有开设课程的详细信息，并能够通过校园网进行选课。,,学生希望在选课期间系统能够,24,小时使用，系统使用方便快捷。,2024/11/27,22,3.,功能需求,功能需求,(Functional Requirements, FR),：,系统应该提供的,功能或服务,，通常涉及用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节；,,,[,例,],,用户可从图书资料库中查询或者选

13、择其中一个子集；,,系统可提供适当的浏览器供用户阅读馆藏文献；,,用户每次借阅图书应对应一个唯一的标识号，它被记录到用户的账户上；,2024/11/27,23,4.,非功能需求,非功能需求,(Non-Functional Requirements, NFR),：,从各个角度对系统的约束和限制，反映了客户对软件系统,质量和性能,(quality and performance),的额外要求，如响应时间、数据精度、可靠性等。,,,[,例,],,系统在,20,秒内响应所有的请求；,,系统应该每周,7,天、每天,24,小时都可使用；,,对一个没有经验的用户而言，经过,2,小时培训即可使用系统所有功能。

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

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

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

17、政策、硬件,/,资源限制、开发语言、等等。,,2024/11/27,28,6.,业务规则,业务规则,(Business Rule),：,对某些功能的可执行性或,内部执行逻辑,的一些限定条件。,,通常表达为“如果,…,，那么,…”,的形式,,通常是一些容易发生变化的功能；,,,例如：,,如果借书卡类型为“教师”，那么一次借阅的最大数量为,8,本；,,如果订单金额大于,10000,元，那么该订单的折扣为,10%,；,,如果采购单金额在,10,万到,50,万之间，那么需要总经理审批；,,2024/11/27,29,7.,外部接口需求,外部接口需求,(External Interface Requir

18、ement),：,描述系统与其所处的,外部环境之间如何进行交互,，包括：,,用户接口需求,(UI),,硬件接口需求,,软件接口需求,,通信接口需求,,例如：,,“从,<,某些设备,>,读取信号”,,“给,<,一些其它系统,>,发送消息”,,“以,<,某种格式,>,读取文件”,,“能控制,<,一些硬件,>”,,“,采用,<,某种类型的,>,用户界面”,,2024/11/27,30,关于需求的一些例子,系统必须有能力支持,100,个以上的并发用户，每个用户可以处理操作任务的任选组合，平均响应时间应该小于,1,秒，最大响应时间应小于,5,秒。,,必须在对话窗口的中间显示错误警告，使用红色的、,14,

19、点加粗,Arial,字体。,,系统必须有能力存储平均操作连续,100,天所产生的事务。,,系统应该在,5,分钟内计算出给定季度的总销售税。,,系统应该在,1,分钟内从,1000000,条记录中检索出一个销售订单。,,系统必须支持,100,个,Windows,工作站的并行访问。,,系统可从各型号的,modem,上读取信号作为系统输入。,2024/11/27,31,需求规格说明,2024/11/27,32,3.1,概述,3.1.3,需求规格说明,需求规格说明是指软件所应满足的全部要求，并用文档方式完整和精确描述。全部要求是指软件系统必须提供的功能和性能、约束条件和限制。,2024/11/27,33

20、,5.2,软件需求的分类,好的需求,vs,坏的需求,2024/11/27,34,好的需求应具备的特征,完整性：,每一项需求都必须将所要实现的功能描述清楚,,正确性：,每一项需求都必须准确地陈述其要开发的功能；,,可行性：,每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的,,必要性：,每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来,,划分优先级：,给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量,,无二义性：,对所有需求说明的读者都只能有一个明确统一的解释,,可验证性：,检查一下每项需求是否能通过设计测试用例或其它验证方法，如用演示、检测

21、等来确定产品是否确实按需求实现,2024/11/27,35,产生不合格需求的原因,无足够用户参与,,——“,我不明白为什么要花那么多功夫收集需求”,,——“,与其与用户讨论浪费时间，不如写代码有意思”,,——“,我已经明白用户需求了”,,用户需求的不断增加,,——,若不断增加新需求，项目就越来越庞大以致超过其计划及预算范围,,——,开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护,,2024/11/27,36,产生不合格需求的原因,模棱两可的需求,,——,诸多读者对需求说明产生了不同的理解,,——,单个读者能用不止一个方式来解释某个需求说明,,——,后果：返工，

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

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

24、不是刚告诉你我的需求了吗？,Cynthia,你只说明了整个项目的概念与目标，这些高层次的业务需求并不能为我们提供足够的详细信息以确定究竟要开发什么样的软件，以及需要多长时间。我需要一些分析人员与一些知道系统使用要求的化学专家进行讨论，然后才能真正明白达到业务目标所需的各种功能和用户的要求。,Gerhard,那些化学专家都非常忙，没有时间与你们详细讨论各种细节，你不能让你的手下的人说明要做的系统吗？,Cynthia,如果我们只是凭空猜想用户要求，结果不会令人满意。,Gerhard,行了，行了，我们没有那么多时间，我来告诉你需求，请马上开始开发系统，并随时将你们的进展情况告诉我。,……,,2024

25、/11/27,39,好需求与坏需求,1.,在现实情况中，用户存钱时并不需要信用检查，因此这个需求描述是错误的,,2. “,适当的行动”对不同的人来说有不同的解释，显然是歧义的。,,改正：如果用户试图透支，系统将显示错误信息并拒绝取款操作。,,3. “,尽快”是不可验证的，应该给出具体数量值。,,改正：系统将在,20,秒内响应所有有效的请求。,,4.,与,5,是矛盾的。,考虑以下需求是否满足“好需求”的标准，如不是，该如何修正？,,在用户每次存钱时系统将进行信用检查；,,如果用户试图透支，系统将采取适当的行动；,,系统将尽可能快的响应所有有效的请求；,,系统允许立即使用所存资金；,,只有在手工验

26、证所存资金后，系统才能允许使用它；,,,2024/11/27,40,需求规格说明,软件需求规格说明的一般格式 ：,,1,．引言,2,．任务概述,,3,．数据描述,4,．功能要求,,5,．性能需求,6,．运行需求,,7,．其他要求（如可使用性、安全保密、可维护性、可移植性等）,,8,．附录,2024/11/27,41,需求规格说明,需求规格说明的特性如下：,,1,．完整性,,2.,正确性,,3.,可行性,,4.,必要性,,5.,无歧义性,,6.,可验证性,,7.,划分优先级,2024/11/27,42,需求工程,2024/11/27,43,3.1,概述,3.1.4,需求工程概念,需求工程就是应用

27、工程化的方法、技术和规格来开发和管理软件的需求。,,需求工程的目标是获取高质量的软件需求。,,需求工程突出了工程化原则，强调以系统化、条理化和重复化的方法进行软件需求的相关活动，从而增强了管理性和降低了需求开发的成本,2024/11/27,44,3.1,概述,3.1.4,需求工程概念,需求工程的任务：,,,1,．确定待开发的软件系统的用户，并获取用户的需求信息。,,2,．分析用户的需求信息，并按需求类型分类，过滤掉非需求的信息。,,3,．根据需求信息建立软件系统的逻辑模型和需求模型，确定非功能需求和约束条件及限制。,2024/11/27,45,3.1,概述,3.1.4,需求工程概念,需求工程的

28、任务：,,,4,．根据收集的需求信息和逻辑模型编写需求规格说明及文档。,,5,．评审需求规格说明。,,6,．当需求变更时，对需求规格说明及需求变更实施进行管理。,2024/11/27,46,3.1,概述,3.1.5,需求工程过程,需求工程过程分为需求开发和需求管理两阶段。,,2024/11/27,47,3.1,概述,3.1.5,需求工程过程,1,.,需求获取,,,确定和,收集,与待开发的软件系统相关的用户需求信息。,,2,.,需求分析,,,对获得的用户需求信息进行分析和综合，找出错误和冲突及遗漏的地方，获得用户的准确的需求，进而建立软件系统的逻辑模型或需求模型。,,3,.,需求定义,,,利用描

29、述语言、标准格式书写软件系统的需求规格说明和文档。,,2024/11/27,48,3.1,概述,3.1.5,需求工程过程,4,.,需求验证,,,审查和验证软件系统需求规格说明，进而确定需求规格说明是否正确描述了用户对软件系统的需求。,,5,.,需求管理,,,需求管理的任务是管理软件系统的需求规格说明和文档，评估需求变更带来的影响及成本费用，跟踪软件需求的状态，管理需求规格说明的版本等。,,2024/11/27,49,需求状态跟踪,需求工程的总体流程,需求获取,需求分析,需求规格说明,,(SRS),需求验证,客户,(client),,终端用户,(user),,市场人员,,维护人员,基线,,(ba

30、seline),需求管理,需求变更过程,,,需求变更,,项目变更,,需求开发,需求管理,2024/11/27,50,需求开发所包含的活动,确定,产品所期望的,用户类,,获取每个用户类的需求,,了解实际用户,任务和目标,以及这些任务所支持的,业务需求,,分析源于用户的信息以区别,用户需求、功能需求、非功能需求、约束条件,、建议解决方法和附加信息,,将系统级的需求分为几个子系统，并将需求中的一部份分配给软件构件,,了解相关非功能属性的重要性,,商讨实施,优先级,的划分,,将所收集的用户需求,编写成规格说明和模型,,评审需求规格说明,，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前

31、将问题都弄清楚,2024/11/27,51,(1),需求获取,需求获取,(Requirement Elicitation),：,通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求,,对用户进行分类,,聆听每一类用户的需求,,分析和整理所获取的需求,,形成文档化的描述,,签字确认,2024/11/27,52,(2),需求分析,需求分析,(Requirement Analysis),：对收集到的需求进行提炼、分析和审查，为最终用户所看到的系统建立概念化的分析模型,,定义系统的边界,,建立软件原型,,分析需求可行性,,确定需求优先级,,建立需求分析模型,,创建数据字典

32、,2024/11/27,53,(3),形成需求规格说明,需求规格说明,(Software Requirement Specification, SRS),：,,需求开发的结果,,精确的、形式化的阐述一个软件系统必须提供的功能、非功能、所要考虑的限制条件等,,作为用户和开发者之间的一个契约,,是用户、分析人员和设计人员之间进行理解和交流的手段,,2024/11/27,54,(4),需求验证,需求验证,(Requirement Verification),：以需求规格说明为输入，通过评审、模拟或快速原型等途径，分析需求规格的正确性和可行性，发现存在的错误或缺陷并及时更改和补充。,2024/11/2

33、7,55,(5),需求管理,需求管理,(Requirement Management),,定义需求基线,(,迅速制定需求文档的主体,),,评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它,,以一种可控制的方式将需求变更融入到项目中,,使当前的项目计划与需求一致,,估计变更需求所产生影响并在此基础上协商新的承诺,(,约定,),,让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪,,在整个项目过程中跟踪需求状态及其变更情况,,2024/11/27,56,需求管理,需求管理,变更控制,版本控制,需求跟踪,需求状态跟踪,建议变更,,分析影响,,做出决策,,交流,,合并,,测量

34、需求稳定性,确定需求文档,,版本,定义对其他需求,,的连接链,,定义对其他系统,,元素的连接链,定义需求状态,,跟踪需求状态,2024/11/27,57,需求管理与需求开发的关系,2024/11/27,58,3.2,需求获取方法,2024/11/27,59,需求获取的基本步骤,了解,,领域背景知识,客户分类,,(,按角色,),CxO,部门经理,业务员,管理员,,,,交流,需求纪要,问题？,分类整理,功能需求,,非功能需求,,约束条件,,业务规则,,外部接口需求,,建议解决方案,优先级排序,,冲突消解,签字确认,业务需求,用户需求,2024/11/27,60,需求获取的基本步骤,第,1,步：,了

35、解相关背景和领域,/,行业的知识，,确定产品所期望的,用户类；,,第,2,步：与客户企业或组织的高层人员进行,交流,，了解实际用户,任务和目标,以及这些任务所支持的,业务需求,；,,第,3,步：与客户企业或组织的底层人员进行,交流,，获取,每个用户类的,详细的用户需求；,,第,4,步：,整理需求纪要,，,发现新问题,，并重复,1-3,步；,,第,5,步：,需求分类和组织，,以区别,功能需求、非功能需求、约束条件、业务规则、外部接口需求,、建议解决方法和附加信息；,,第,6,步：,优先排序和冲突解决；,,第,7,步：得到最终需求清单，并与客户做,最终签字确认。,,2024/11/27,61,“看

36、似简单，实际却很难,…”,—— “,需求获取？不就是问问题吗？这有什么难的？”,2024/11/27,62,需求获取过程,,2024/11/27,63,3.2,需求获取方法,1,．确定需求开发计划,,本项工作的基本任务是确定需求开发的步骤，提出收集需求活动的具体安排和进度。,,2,．确定项目范围和目标,,项目目标主要指项目开发的目的和意义，以及软件系统的目标。,,3,．确定调查对象,,确定调查对象的基本任务是明确地确定来自不同层次的需求来源和用户，并将其分类。,,2024/11/27,64,3.2,需求获取方法,4,．实地收集用户需求信息,,实地收集需求信息阶段的任务是到现场实地调查和与用户交

37、流，收集和理解用户需求信息。,,5,．确定非功能性需求,,非功能需求是表明软件能否良好运行的定性指标。,,常用的非功能性需求如下：,,①可靠性②可用性③安全性④互操作性⑤易用性,,⑥可维护性⑦可移植性⑧可用性⑨健壮性,,2024/11/27,65,需求获取技术,需求获取的关键：,,沟通和交流,,所要避免的问题：,,交流障碍、沟通不全、意见冲突,,所要必备的条件：,,较高的技术水平、丰富的实践经验、较强的人际交往能力,,可能采取的手段：,,用户访谈、现场考察、专家咨询、会议讨论、,…,2024/11/27,66,需求获取技术,面对面访谈,(face-to-face interviewing),,

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

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

40、种需求目前的解决方案是什么？,,解决方案相关的问题,(solution-context questions),：通过这类问题，探寻特定的解决方案并得到用户认可,,你希望如何解决这个问题？,,你觉得该问题这样解决如何？,,2024/11/27,71,面谈之前,确立面谈目的,,确定要包括的相关用户,,确定参加会议的项目小组成员,,建立要讨论的问题和要点列表,,复查有关文档和资料,,确立时间和地点,,通知所有参加者有关会议的目的、时间和地点,,2024/11/27,72,面谈之中,Step 1,：事先准备一系列上下文无关的问题，并将其记录下来以便面谈时参考；,,Step 2,：面谈前，了解一下要面谈

41、的客户公司的背景资料，不要选择自己能回答的问题而浪费时间；,,Step 3,：面谈过程中，参考事先准备的面谈模板，以保证提出的问题是正确的。将答案记录到纸面上，并指出和记录下未回答条目和未解决问题；,,Step 4,：面谈之后，分析总结面谈记录。,2024/11/27,73,面谈之后,复查笔记的准确性、完整性和可理解性,,把所收集的信息转化为适当的模型和文档,,确定需要进一步澄清的问题域,,向参加会议的每一个人发出此次面谈的,minutes(,会议纪要,),。,,2024/11/27,74,面谈记录的示例,(1),第一部分：建立客户或用户情况表,,第二部分：评估问题,,询问用户对哪些类型的问题

42、缺乏好的解决方案,,它们是什么？,(,不断的问“还有吗？”,),,第三部分：理解用户环境,,谁是用户？他们的经历和经验如何？用户的预期如何？,,第四部分：扼要说明理解情况,,你刚才告诉我：,(,用自己的话复述客户描述的问题,),,这是否足以表达你现在的解决方案中存在的问题？,,如果有，你还有什么问题？,,2024/11/27,75,面谈记录的示例,(2),第五部分：分析人员对客户问题的输入,,对每个问题进行以下提问：,,这是一个实际的问题吗？,,问题产生的原因是什么？,,现在如何解决的？,,希望如何解决？,,该问题的重要度如何？,,第六部分：评估自己的解决方案,,总结自己建议的解决方案；,,对

43、自己方案的优先级排序；,,第七部分：评估机会,,第八部分：评估可靠性、性能及其他需要,2024/11/27,76,面谈记录的示例,(3),第九部分：其他需求,,法律法规、环境、行业标准等；,,第十部分：总结性提问,,还有其他问题要问面谈人吗？,,尚未解决的问题有哪些？,,下次访谈的方式、地点、时间、参加人等；,,第十一部分：分析人员的总结,,总结出客户,/,用户确认的三条优先级最高的需求或问题。,,,2024/11/27,77,面对面访谈的优缺点分析,优点：,,人们很愿意谈论自己的工作，并且总是很喜欢接受访谈；,,缺点：,,大多数人都采用专业术语和“行话”，而太多的专业术语让需求工程师难以理解

44、，往往造成很多误解；,,有些需求对用户来说太普通了，以至于他们不自觉地认为这些需求太基本，不值得去提。但它们对需求工程师来说却不是显而易见的。这往往会造成某些需求被忽略；,,2024/11/27,78,需求研讨会,(Workshop),2024/11/27,79,需求研讨会,(Workshop),2024/11/27,80,需求研讨会,(Workshop),通过让所有相关人员一起参加某个单一会议来定义需求或设计系统，也称联合应用设计会议,(Joint Application Design, JAD),。,,系统相关者在短暂而紧凑的时间段内集中在一起，一般为,1,至,2,天，与会者可以在应用需求

45、上达成共识、对操作过程尽快取得统一意见。,,协助建立一支高效团队，围绕一个目的：项目的成功；,,所有人员都畅所欲言；,,促进用户与开发团队之间达成共识；,,能够揭露和解决那些妨碍项目成功的行政问题；,,最终很快产生初步的系统定义。,,2024/11/27,81,需求研讨会,(Workshop),专题讨论会准备,,参加会议人员：主持人、用户、技术人员、项目组人员,,安排日程,,通常在具有相应支持设备的专用房间进行,,举行会议,,可能出现人员之间的责备或冲突，主持人应掌握讨论气氛并控制会场,,最重要的部分是自由讨论阶段，这种技术非常符合专题讨论会的气氛，并且营造一种创造性的和积极的氛围，同时可以获

46、得所有相关者的意见,,分配会议时间，记录所有言论,,2024/11/27,82,现场观察,用户可能无法有效全面的表达自己的需求，通过面谈和会议也难以获得完整信息；,,,在这种情况下，现场观察用户的工作流程有助于更深入全面了解需求。,,,两种方式：,,被动观察：用户实地工作，需求分析人员在旁边看,,主动观察：需求分析人员直接参与用户的实际工作,,2024/11/27,83,头脑风暴,(Brainstorming),2024/11/27,84,头脑风暴,(Brainstorming),一般以,8-12,人最佳：,,人数太少不利于交流信息和激发思维；人数太多则不容易掌握，并且每个人发言的机会相对减少

47、,,明确分工：,1,名主持人、,2,名记录员,,成功要点：,,自由畅谈,,延迟批判、禁止批评,,禁止批评、自我批评、自谦,,追求数量,,会后：修剪、分组、排序,,,适用场合：产品型系统，需要具有创新性特征，尚未投放市场，无明确的客户。,2024/11/27,85,3.3,需求分析的任务与原则,,3.3.1,需求分析的任务,3.3.2,需求分析的原则,2024/11/27,86,需求工程过程,需求工程过程分为需求开发和需求管理两阶段。,,2024/11/27,87,3.3,需求分析的任务与原则,3.3.1,需求分析的任务,需求分析的基本任务是分析与综合已收集到的需求信息，通过分析找出需求信息内在

48、联系和可能的矛盾，通过综合找出解决问题的方法并建立系统的逻辑模型。,,具体地说，需求分析是提炼、分析和审查已收集到的需求信息，找出真正的和具体的需求，并确保所有相关人员都理解其含义。,2024/11/27,88,3.3,需求分析的任务与原则,3.3.1,需求分析的任务,绘制系统关联图,,关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。,,,2.,创建用户接口原型,,当开发人员或用户不能确定软件需求时，开发一个用户接口原型,(,可能的局部实现,),，这样使得许多概念和可能发生的事更为直观明了。,2024/11/27,89,3.3,需求分析的任务与原则,3.3.1,需求分析的任务,3.

49、,分析需求可行性,,在允许的成本、性能要求下，分析每项需求实施的可行性。,,4.,确定需求的优先级,,应用分析方法来确定使用实例、产品特性或单项需求实现的优先级。,,5.,为需求建立模型,,需求的图形分析模型是软件需求规格说明的补充说明。,2024/11/27,90,3.3,需求分析的任务与原则,3.3.1,需求分析的任务,6.,创建数据字典,,数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。,,7.,质量功能调配,,质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。,2024/1

50、1/27,91,3.3,需求分析的任务与原则,3.3.2,需求分析的原则,1,．必须能够表达和理解问题的数据域和功能域,,,对于计算机程序处理的数据，其数据域应包括数据流、数据内容和数据结构。就是将一种形式的数据转换成另一种形式的数据。,2024/11/27,92,3.3,需求分析的任务与原则,3.3.2,需求分析的原则,2.,按自顶向下、逐层分解问题,,,,分解问题是把问题以某种方式分解为几个较易理解的部分，并确定各部分间的接口，从而实现整体功能。,,在需求分析阶段，软件的功能域和信息域都能做进一步的分解。这种分解可以是同一层次上的，称为横向分解；也可以是多层次的纵向分解。,2024/11/

51、27,93,3.3,需求分析的任务与原则,3.3.2,需求分析的原则,3.,要给出系统的逻辑视图和物理视图,,,这对系统满足处理需求所提出的逻辑限制条件和系统中其他成分提出的物理限制条件是必不可少的。,,,软件需求的逻辑视图给出软件要达到的功能和要处理数据之间的关系。,,软件需求的物理视图给出处理功能和数据结构的实际表示形式。,,2024/11/27,94,3.4,需求建模方法,,3.4.1,结构化需求建模方法,3.4.2,数据流图,3.4.3,数据字典,,2024/11/27,95,3.4,需求建模方法,需求建模方法的共同特性 ：,,1,．提供描述手段,,2,．提供基本步骤,,建模方法主要包

52、括结构化的需求建模方法和面向对象的需求建模方法,2024/11/27,96,3.4,需求建模方法,3.4.1,结构化需求建模方法,基本特点是表达问题时尽可能使用图形符号的形式，设计数据流图时只考虑系统必须完成的基本功能，不必考滤如何具体实现这些功能。,,基本思想是按照由抽象到具体、逐层分解的方法，确定软件系统内部的数据流、变换关系，并用数据流图表示。,,描述手段 ①一套分层的数据流图 ②一本词典 ③其他补充材料,2024/11/27,97,数据流图,(DFD),数据流图,(Data Flow Diagram, DFD),：,结构化系统分析的基本工具,,描绘数据在系统中各逻辑功能模块之间的流动和

53、处理过程，是一种功能模型,,主要刻画“功能的输入和输出数据”、“数据的源头和目的地”,,2024/11/27,98,DFD,的主要元素,销售订单,1,,录入订单,销售订单,客户,数据流,加工,数据存储,外部实体,2024/11/27,99,DFD,的主要元素,(1),：加工,加工,(,又称数据处理，,data processing),：对数据流进行某些操作或变换。,,收集、排序、选择、聚集、分析等,,加工要有名字，通常是动词短语，简明地描述完成什么事情,,在分层的数据流图中，加工还应编号,,三种类型：计算机自动加工、手工加工、人机协作的加工,,1,,录入订单,2,,审核订单,2024/11/2

54、7,100,DFD,的主要元素,(2),：数据存储,数据存储,(data storage,，也称文件,),：需要在外存储器上保存的数据，它可以是数据库文件或任何形式的数据组织。,,以名词命名,销售订单,销售订单,销售订单,2024/11/27,101,DFD,的主要元素,(3),：外部实体,外部实体,(external entity),：本系统外部环境中的实体,(,包括人员、组织或其他软件系统,),,也称为“数据源点,/,数据终点”，表示产生数据的源头或消费数据的终点,,以名词短语命名,,不能直接访问数据存储,,,客户,学生,库存系统,旅行社,2024/11/27,102,DFD,的主要元素,

55、(4),：数据流,销售订单,数据流,(data flow),：数据在系统内传播的路径,,由一组成分固定的数据组成。,,由于数据流是流动中的数据，所以必须有流向,,应用名词或名词短语命名,,可能是纸张上的数据、电子数据、通过网络传输的数据等,,,,,可能存在于：,,外部实体与加工之间；,,加工与加工之间；,,加工与数据存储之间,,2024/11/27,103,DFD,的简单练习,背景：用户输入,a,、,b,、,c,、,d,四个值，系统计算,(a+b)*(c+a*d),，并将结果输出到一个文件中存储。,,问题：绘制该系统的,DFD,,,,2024/11/27,104,DFD,的层次性,DFD,的层

56、次性：,自顶向下的分解,(top-down),,DFD,的两种类型：,,环境关联,DFD,图,(Context-level DFD,，或,Context Diagram),：也称顶层,DFD,图,，描述了系统与外部环境之间的数据输入,/,输出关系；,,系统内部,DFD,图,(Inner-level DFD),：,描述系统内部各功能模块之间的数据流动关系,,0-,层,DFD,图,,1-,层,DFD,图,,…,,N,层,DFD,图,,2024/11/27,105,顶层,DFD,顶层,DFD,图,(,关联图,),,通过系统和外部世界之间的联系来描述系统的范围,,确定了通过某一接口与系统相连的外部实体

57、，同时也确定了外部实体和系统之间的数据流,,只包含一个加工，用以表示被开发的系统，然后考虑该系统有哪些输入数据、输出数据流,,编号：,0,,,2024/11/27,106,示例：顶层,DFD,2024/11/27,107,0,层,DFD,将顶层,DFD,图中的系统分解为若干个子系统，决定每个子系统间的数据接口和活动关系，得到,0,层,DFD,图；,,编号：,1,、,2,、,…,、,n,2024/11/27,108,底层,DFD,针对,0,层,DFD,中的每一个子系统，对其继续分解得到细化的加工，进而逐渐向下构造得到,1,层,DFD,、,2,层,DFD,、,…,、,n,层,DFD,，,一直到不能

58、或不需再分解为止。,,最底层,DFD,中的加工称为,“基本加工”,。,,,编号：,,1,层,DFD,：,1.1,、,1.2,、,…,、,1.n,,2,层,DFD,：,1.1.1,、,1.1.2,、,…,、,1.1.n,,…,2024/11/27,109,底层,DFD,0,层,DFD,1,层,DFD,2024/11/27,110,数据流的分解,2024/11/27,111,如何识别数据流,通过识别“事件”来识别数据流，进而识别得到加工、数据存储,,事件的分类：,,外部事件,(External events),：外部实体与系统进行交互,(,顾客下订单、供应商的货物到达,),,决策事件,(Decis

59、ion events),：需要外部实体为系统某些业务做出决策,(,是否接受订单,),,时间性事件,(Temporal events),：由时间所触发的周期性时间,(,每月,25,号编制下月计划、每天,17,点盘点库存,),,状态事件,(State events),：由某些数据的变化所自动触发的事件,(,当库存量下降到,100,以下时，启动采购流程,),2024/11/27,112,绘制,DFD,的一些基本原则,,把数据存储放在,0,层数据流图或更低层子图上，不要放在顶层的关联图上,,,,,,使用数据流图时，不要试图让数据流图反映处理的顺序，忽略系统的运行时的时间特性,,加工通过数据存储进行通讯

60、，而尽量避免从一个过程直接流到另一过程,,2024/11/27,113,绘制,DFD,的一些基本原则,外部实体,1,外部实体,2,数据流,数据存储,1,外部实体,1,数据流,数据存储,1,外部实体,1,数据流,数据存储,1,数据流,数据存储,2,,,,,数据不能直接由一个数据存储直接流到另一个数据存储,,,,数据不能直接从一个外部实体直接流到一个数据存储,,,,数据不能直接从一个数据存储直接流到一个外部实体,,,,数据不能直接在外部实体之间流动,,2024/11/27,114,绘制,DFD,的一些基本原则,数据流是单向的,,,,,,任何加工必须有输入和输出数据流,,,,对现有加工进行持续的分解

61、和组合，直到所有加工之间达到较高的聚合度；,,尽量将每一张,DFD,上的所有元素数目控制在,7-12,个。,,,2024/11/27,115,父图与子图的平衡,下层,DFD,中的输入输出数据流同上层,DFD,中相应加工的输入输出数据流必须一致，此即父图与子图的平衡。,1.1,,加工,1.2,,加工,1.3,,加工,a,b,c,d,e,1.1.1,,加工,1.1.2,,加工,1.1.3,,加工,a,a,1,a,2,b,c,2024/11/27,116,父图与子图的平衡,数据流本身可以分解，但其包含的数据内容应保持平衡,1.1,,加工,1.2,,加工,1.3,,加工,a,b,c,d,e,1.3.1

62、,,加工,1.3.2,,加工,1.3.3,,加工,c,c,1,c,2,d,1,d,2,d,1,+d,2,=d,2024/11/27,117,DFD,实例：销售系统,某企业销售管理系统：,,接受顾客的订单，检验订单，若库存有货，进行供货处理，即修改库存，给仓库开备货单，并且将订单留底；若库存量不足，将缺货订单登入缺货记录。,,根据缺货记录进行缺货统计，将缺货通知单发给采购部门，以便采购。,,根据采购部门发来的进货通知单处理进货，即修改库存，并从缺货记录中取出缺货订单进行供货处理。,,根据留底的订单进行销售统计，打印统计表给经理。,,,绘制上述系统的顶层、,0,层、,1,层,DFD,图,2024/

63、11/27,118,销售系统顶层,DFD,2024/11/27,119,销售系统,0,层,DFD,2024/11/27,120,销售系统,1,层,DFD,2024/11/27,121,销售系统,1,层,DFD,2024/11/27,122,销售系统,1,层,DFD,2024/11/27,123,DFD,树,顶层,DFD,0,层,DFD,1,层,DFD,2,层,DFD,2024/11/27,124,数据流图,1,．数据流图的含义,,数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的传输变换过程。,,,2,．数据流图的特性,,（,1,）抽象性 （,2,）概括性（,3,）层次性,

64、,3.,数据流图基本符号,,（,1,）源点（,2,）加工（,3,）数据流,,（,4,）数据存储文件,,4,．数据流图的用途,--,作为交流信息的工具。,2024/11/27,125,数据流图,5,．数据流图的优缺点,,,(1),总体概念强，每一层都明确强调干什么，需要什么，给出什么。,,,(2),可以反映出数据的流向和处理过程。,,,(3),由于自顶向下分析，容易及早发现并修正系统各部分的逻辑错误。,,,(4),容易与计算机处理相对照。,,,(5),不直观,,,(6,）人工绘制太麻烦，工作量较大。,2024/11/27,126,数据流图,6,．数据流图的画法,,(1),画数据流图的一般原则,,

65、画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。,,(2),数据流图的分层方法,,,2024/11/27,127,数据流图,7,．数据流图的绘制与其他流程图的差别,,,(1),数据流图与系统流程图的区别,,将物流与资金流排除在外,,(2),数据流与程序流程图的区别,,只反映数据的流向、处理逻辑和必要的数据存储，它不反映处理逻辑的先后的时间顺序,2024/11/27,128,数据流图,7,．数据流图的绘制与其他流程图的差别,,,(3),数据流与程序结构图的区别,,不反映控制关系、调用关系、控制流，只画数据流,,(4),数据流与控制流的区别,,有数据（指表示事物的信息，而

66、不是控制信号）流过,2024/11/27,129,数据字典,1,．数据字典的定义,,数据字典是定义目标系统中使用的所有数据元素和结构的含义、类型、数量值、格式和度量单位、精度及允许取值范围内的共享数据仓库。,,2,．数据字典的内容 （,l,）数据流 （,2,）数据项 （,3,）数据结构 （,4,）数据存储 （,5,）处理逻辑 （,6,）外部实体,,3,．定义数据的方法,--,对数据自顶向下的分解,2024/11/27,130,数据字典,4,．数据字典的用途,,数据字典最重要的用途是作为分析阶段的工具。,,,5,．数据字典的实现,,目前实现数据字典有三种常见的途径：全人工过程，全自动化过程（利用数据字典处理程序）和混合过程（用正文编辑程序、报告生成程序等已有的实用程序帮助人工过程）。,2024/11/27,131,数据字典,(DD),DFD,只是绘制了系统各功能之间的数据流动和处理关系，还需进一步考虑各数据的具体内容。,,,采用数据字典,(Data Dictionary),作为描述工具,,,,对于,DFD,中出现的所有被命名的图形元素,(,数据流、数据项、数据存储、加工,),在,DD,中