《软件项目管理原理与实践》 课件 第2章 软件项目需求工程.pdf

第2章软件项目需求工程 21概述O 2.1.1 需求定义O 2.1.2 需求类型 2.2需求开发和管理过程O 2.2.1 需求获取o 2.2.2 需求分析o 2.2.3 需求规格说明o 2.2.4 需求验证o 2.2.5 需求变更管理o 2.2.6 可测试性需求2 2.3需求获取方法O 2.3.1 访谈和调研o 2.3.2 专题讨论会o 2.3.3 头脑风暴o 2.3.4 场景串联 2.4需求分析建模方法O 2.4.1 用例分析方法o 2.4.2 原型分析方法o 2.4.3 结构化分析方法 2.5需求管理工具O 2.5.1 需求管理工的功能o 2.5.2 常用需求管理工具3Why Are Requirements Important in Software Engineering?为什么需要，将用在何处?在构造任何工程制品之前，人们都要弄清楚为什 么需要，将用在何处？O这些问题与一个工程制品的需求相关，其答案就代表了构造这个工 程制品的意图。O软件也是一种工程制品，在开发软件之前，也必须先了解清楚需求,充分理解设计、使用软件的意图。软件需求，是指用户对目标软件系统在功能、行 为、性能、设计约束等方面的期望。O通过对应问题及其环境的理解、分析，为问题涉及的信息、功能、系统行为建立模型，将用户需求精确化、完全化，最终形成需求规 格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段O软件需求工程是要把一个定义不足的问题，转换为一个定义良好的 问题，以便能够找到问题的解决方案。5-UJ 1 s sPROJECTCONTRACTSTAKEHOLDERStools SO FTWARE userneedsREQUIREMENTSVALIDATION ENGINEERING 山 specificationMANAGEMENT CONDITION 匕 os6e需求分析是介于系统分析和软件设计阶段之 间的桥梁。O 一方面，需求分析以系统规格说明、项目规划作为分析 活动的基本出发点，并从软件角度对它们进行检查、调O另一方面，需求规格说明又是软件设计、实现、测试直 至维护的主要基础。O良好的分析活动有助于避免或尽早剔除早期错误，从而 提高软件生产率，降低开发成本，改进软件质量。软件 项目需求是软件开发后继阶段的基础。7reguimgntx engNbcrWg j|8用户的需求变更在软件项目管理过程中，项目经理经常面对 用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整,软件交付日期一再拖延，项目研发人员的士气将越来 越低落，将直接导致项目成本增加、质量下降及项目交 付日期推后。因此，项目组必须拥有需求管理策略。9什么是软件需求软件项目需求管理已经成为软件工程中最为 关键的问题。我在开始设计软件 之前，需要知道你的需求 J我正想让你来 设计我的软件首先，你要 实现什么？我的意思是，你 正在用这个软件 实现什么？10软件项目需求管理软件项目需求管理，使软件系统分析工程师 能够结合软件项目实际，提出切实有效的项 目需求管理策略，解决其在管理软件项目需 求分析时所面临的实际问题，从而降低软件 开发成本提升软件产品的质量，提高软件企 业竞争力。软件需求的抽象层次软件需求可以分为4个抽象层次，分别是原 始问题描述、用户需求、系统需求和软件设计描述。I I原始问题描述用户需求-原始问题空间X_解决方案空间系统需求软件设计描述12PROJECT REQUIREMENTSPROJECTNo:MA-015-02FULL PROJECTNAME:Project OrionDATE:PROJECTMANAGER:A SmithREQUIREMENT LISTIDREQUIREMENT DESCRIPTIONREQUESTED BYCATEGORYPRIORITYACCEPTANCE CRITERIAGive each requirem ent a unique ID.The feature,function,condition or capability that is required from the project,product,service or result.The stakeholder who requested the requirement.The category or grouping of the requirement for example:functional,technical,operational,KPI(result metric),transitional.The priority of the requirement for example:Pl,P2,P3 or MoSCoW(Must hove,should have,could have,wont hove).The criteria that the requirement must have for it to be accepted by the project stakeholders.REQUIREMENTS DEFINITIONS 13j2二需求工程的重要性需求工程的重要性，体现在下面3个方面：O(1)Brooks在他1987年经典文章没有银弹中，阐 述了需求的重要性。开发软件系统最困难的部分就是准 确说明开发什么。最困难的概念性工作，是编写出详细 的需求，包括所有面向用户、面向机器和其它软件系统 的接口。此工作一旦做错，将会给系统带来极大的损害,并且以后对它修改也极为困难。O(2)需求是产品的根源，需求工作的优劣对产品影响 最大。O(3)世界软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。了解客户、最终用户、间 接用户的概念。15需求工程(Requirement Engineering)O指应用已证实有效的技术、方法进行需求分析，确定客 户需求，帮助分析人员理解问题并定义目标系统的所有 外部特征的一门学科。需求工程需求获取需求分析需求开发利益相关者咨 询、评论和语 境规范化对系统的理解对需求省略、冗 余、不一致性的 识别需求验证系统的结构化 文档记录16概述171.1概述 需求分析是介于系统分析和软件设计阶段之 间的桥梁。一方面，需求分析以系统规格说明、项目规划作为分析 活动的基本出发点，并从软件角度进行检查、调整；O另一方面，需求规格说明又是软件设计、实现、测试、维护的主要基础。良好的分析活动，有助于避免或尽早 剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。18 需求，并不是软件系统特有的概念。O任何一件产品、服务在生产之前，都需要首先弄清人们 为什么需要它，用于何处，其次，是设计的产品通过什 么形式和功能来满足这些需求。需求(Requirement)在IEEE软件工程标准 词汇表(1997)中定义为：o用户解决问题或达到目标所需的条件或能力；O系统或系统部件要满足合同、标准、规范或其它正式规 定文档所需具有的条件或能力；O 一种反应上面二点所描述的条件或能力的文档说明。_令 IEEE_19BadGoodRequirementsRequirements20Functional Requirements-/Non-Functional Requirements2122软件需求并不是要解决软件系统“如何做”的问题，它的根本任务在于解决目标系统“做什么”的问题。O需求是连接用户和软件开发团队的桥梁，用户通过需求 描述软件产品，而需求则是软件开发团队的工作基础，所以说没有明确的需求就没有正确的软件。需求来源于用户的一些需要，这些需要被分 析、确认后形成完整的文档，该文档详细地 说明了产品必须或应当做什么。O软件需求也是用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。这种期望是一种心理活动、笠统、不细软、不悔时程的描沐C232.1.1 需求定义软件需求工程的关键问题包括二。不论是合同项目还是自主研发的产品，都必须开展需求 开发和需求管理活动。O开发者对待需求工程的态度可分“被动型”、“主动 型”、“领先型”三种，只有后两种才有可能开发出成 功的产品。24(1)“被动型”O指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷 懒。他们认为，需求是用户的事情而不是自己的事情。开发过程中经常发 生需求变更，导致产品迷失方向，不是半途而废就是陷入停顿的状态。(2)“主动型”O指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作 自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而 不是找借口推卸责任。俗话说，良好的开端是成功的一半，“主动型”需 求工程是开发成功产品的必备条件。(3)“领先型”O是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工 程做到这个程度上，才能使产品立于不败之地，长盛不衰。25需求开发的主要困难与解决方案(1)应用域的知识是无边无际的，任何人都不可能了解所 有行业基础背景知识。(2)当需求分析员缺乏应用领域知识时，他该怎么办？O首先，他要有勇气做事，否则连实践的机会都没有。其次，他应当赶紧补习应用域知识。(3)相当多的开发人员习惯于被动地对待需求开发。O每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为，需 求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什 么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己 负责。(4)用户说不清楚需求或者需求发生变更，这些都是常见 的问题，并不是不能解决，是人们可以设法解决的。O可现实情况是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个 软件开发过程，产生太多的后患。(5)软件企业的领导应当给具有错误观念的开发人员们洗 脑。O需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，就 不能够胜任软件系统分析工作。26软件需求包括3个不同的层次与业务需求 用户需 求和功能需求。o(1)业务需求(Business Requirement)业务需求表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个软件系统，即组织希望达到的 目标。使用愿景(Visio n)和范围(Sc o pe)文档来记录业务需求，这份文档 有时也被称作项目轮廓图(Pr o j ec t Char t er)或市场需求(Mar ket Requir ement)文档。27(2)用户需求(User Requirement)。用户需求描述的是用户的目标，或用户要求系统必须能 完成的任务。O用例、场景描述和事件-响应表都是表达用户需求的有 效途径。也就是说用户需求描述了用户能使用系统来做 些什么。28H，chLeve,BusinessRequirements.卜User euiied RequirementsSystem RequirementsSponsor point of viewScope of the projectBusiness ObjectivesUser point of viewUser GoalsUser inputs&Outputs kFunctional4-What t he syst em do esNon-Functional no w wel l t he syst em c c es it29(3)功能需求(Functional Requirement)O功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。o功能需求有时也被称作行为需求(Behavioral Requirement),因为习惯上总是用“应该”对其进行 描述，“系统应该发送电子邮件来通知用户已接受其预 7E o功能需求描述是开发人员需要实现什么。30(4)非功能性需求(Non-Functional Requirement)O系统需求O业务规则O软件需求规格说明O质量属性O约束Func t io nal r equir ement sNo n-f unc t io nal r equir ement sf unctiorul rvQLMvrMrti Qualitative requirements-Perf ormance-Vecurity-Re ability-UseahlityChangeabihtv/MintairQbilitv-PortabilitvBoundary conditions-StdncUrds-Technology Process31功能需求和非功能性需求功能需求和非功能性需求的区别FRNFRDif f ic ul t t o c apur e32需求管理首先要针对需求做出分析,随后提 出解决方案。实施并验证结果好的需求管理，可使最终产 品更接近于解决需求,提高用户对产品的满 意度,从而使产品成为真正优质合格的产品O需求共识O根据需求设计解决办法O方案设计O必要的修改O任务划分O产品测试33,对于所建议的软件产品，获取需求是一个从 了解、理解到确定不同用户需要和限制的过 程，即要了解用户需要系统完成的任务有哪些o在这些任务中，分析者能获得用于描述系统活动的特定 软件功能需求，这些系统活动有助于用户完成他们的日 常工作任务。O获取用户需求位于软件需求三层结构的中间一层，它描 述了用户利用系统需要完成的任务。3435在整个软件项目实施过程中，需求获取可能是软 件开发中最困难、最关键、最易出错及最需要沟 通、交流的重要方面。O 一旦理解并掌握了用户的实际需求，分析者、开发者就能够找到描 述这些需求的多种方法。开发方只有在掌握用户需求之后才能开始系统设 计工作。O否则，对需求定义的任何改进，设计上都必须进行大量的返工。一 个项目的目的，就是致力于开发正确的系统，要做到这一点就要足 够详细地描述需求，也就是系统必须达到的条件或能力，使用户和 开发人员在系统应该做什么，不应该做什么方面达成共识。O开发软件系统最为困难的部分就是准确说明开发什么，最为困难的 概念性工作便是编写出详细技术需求，这包括所有面向用户、面向 机器和其它软件系统的接口。3637多年来，分析者总是利用情节或经历来描述 用户和软件系统的交互方式，从而获取需求,可以把这种看法系统地阐述成用使用实例 的方法进行需求获取和建模：O 一个使用实例描述了系统和一个外部与执行者的交互顺 序，这体现执行者完成一项任务并给利益相关者(Stakeholder)带来益处，执行者是指一个人，或另一 个软件应用，或一个硬件，或其它一些与系统交互以实 现某些目标的实体，执行者可以映像到一个或多个可以 操作的用户类角色。38Hd 1ELHigh levelBusiness RequirementsSponsor point of view,Scope of the projectBusiness ObjectivesDetailedUserRequirementsUser point of viewUser GoalsUser inputs&OutputsSystem RequirementsFunctional-Wha:the system doesNon-Functional-how well the system does it39实例获取需求方法使用实例为表达用户需求提供了一种方法，而这 一方法必须与系统的业务需求相一致。基于使用实例的方法可以带来更好的效果。401.基于实例的需求获取基于实例的需求获取过程遵循如下步骤：O(1)编写前景文档O(2)确定用户类O(3)确定用例O(4)召开应用程序开发联系会议O(5)分析用户工作流程o(6)确定质量属性和其它非功能需求o(7)通过检查当前系统的问题报告来进一步完善需求o(8)跨项目重用需求2.需求获取的常见困难 1）分析人员专门业务知识的缺乏 2）用户对需求描述不清 3）客户的时间表不合理 4）沟通客户、工程师和项目经理间存在的 隔阂 5）开发团队并不理解客户组织的政治策略6）对需求理解上的偏差42适用于跨文化沟通的沟通模型给出了发送方的当前情绪、知识、背景、个 性、文化、偏见会如何影响信息本身及其传 递方式当前情绪文化：代际国家专业学科性另IJ个性偏见（假设）当前情绪文化：代际 国家 专业学科 性别个性偏见（假设）43EIOptf 3Scqzwq Mnjnrm hr Ford R)cu?y Irym FvrU MoUM SUH DU：23/&I，”I*.巳1ct Fll0vh DMf!30/WCMwry i McChOC 2 nPkUtrc，txchScoFlL gSimdwl RS”“30 2刎：2500(0 00 GBP*晅叵,IoCl Output:9100000 Pm Z：leti bntrm Uf:12.a tIMaI、um”ef o*Frtn:ZrnXr ct SlUtts:_2 w*TZTk i horg lOOar)UTE f _ Jf cd ubourKwxoMnco 2hod：2 Xb0w”4 R Parts 9rtsf Mf K 21【X44I I-需求分析O是指对要解决的问题进行详细的分析，弄清楚问题的要 求，包括需要输入什么数据，要得到什么结果，最后应 输出什么。软件工程当中的需求分析善是确定要计算机 做什么，要达到什么样的效果0e需求分析是做系统之前以桃的-45在软件工程的历史中，很长时间里，人们一 直认为需求分析是整个软件工程中最简单的 一个步骤。但在近十年内，越来越多的人认识到，需求分析是整个 过程中最关键的一个部分。O假如在需求分析时分析者们未能正确地认识到顾客的需 要的话，那么最后的软件实际上不可能达到顾客的需要,或者软件项目无法在规定的时间里完工。46Used Case UlBQFimQ A JInterf ace Anaaio MethodObservationdimrvlewREQUIREMENTS ANALYSISUnder st anding t he basic s-Def init io n.Pr o c ess.&Requir ement Anal ysis Tec hniques47需求分析特点 1）交流困难O需求分析是一项重要的工作，也是最困难的工作。在软件生存周期 中，其它的阶段都是面向软件技术问题，只有本阶段是面向用户的 2）需求动态化O对于一个大型而复杂的软件系统，用户很难精确完整地提出它的功 能和性能要求。一开始，只能提出一个大概、模糊的功能，只有经 过长时间的反复认识才逐步明确。有时进入到设计、编程阶段才能 明确，更有甚者，到开发后期还在提新的要求。这些，无疑给软件 开发带来困难。3）后续影响复杂O需求分析是软件开发的基础。假定在该阶段发现一个错误，解决它 需要用一小时的时间，到设计、编程、测试和维护阶段解决，则要 花2.5、5、25、100倍的时间。48REQUIREMENTS ANALYSISUnderstanding the basic-Definition,Process,&Requirement Analysis Techniques避ObservationBrainstormlnEFocus GroupUsed Case Diacram嶷Intorviaw SurveyJoin Application MethodInterf ace Analysis噩Prototyping492.需求分析任务确定对系统的综合要求，虽然功能需求是对 软件系统的一项基本需求，但却并不是唯一 的需求，通常对软件系统有下述几方面的综 合要求：O(1)功能需求O(2)性能需求O(3)可靠性和可用性需求O(4)出错处理需求O(5)接口需求O(6)逆向需求O(7)将来可能提出的要求502.需求分析任务 1）数据要求O任何一个软件本质上都是信息处理系统，系统必须处理的信息和系 统应该产生的信息很大程度上决定了系统的面貌，对软件设计有深 远的影响，因此，必须分析系统的数据要求，这是软件分析的一个 重要任务。2）逻辑模型O通过数据分析的结果可以导出系统的详细的逻辑模型，通常用数据 流图、E-R图、状态转换图、数据字典和主要的处理算法描述这个 逻辑模型。3）修正计划O根据在分析过程中获得的对系统的更深入的了解，可以比较准确地 估计系统的成本和进度，修正以前定制的开发计划。512.需求分析任务52编写优秀的需求力是没有公式化的方法的。这需要大量的经验，要从过去的文档中发现 的问题学习。O在组织软件需求文档时，严格遵从这些方针。O句子和段落要简练。O使用正确的语法，拼写，标点。O使用术语，要保持一致性，并在术语表或数据字典中定 义它们。O需求编写者还要努力正确地把握粒度。O多个需求尽可能拆分开。整个需求文档细节上要保持一 致。53OK117Properties f or Learning Project-Use Cases118IBM RationalDOORS Next Generation119=,Hel ic o pt er Syst emRequir ement s c ur r ent 0.0 in/H_demo(Fo r mal mo dul e)-DOORSFil e Edit View Inser t Link Anal ysis Tabl e To o l s Disc ussio ns User MATLAB Chang e Manag ement Hel p哥M三目”各那用热 M SrView St andar d viewAl l l evel s I*,南普0喑WSI 7第月驾0-H el ic o pt er Syst emR equir ement s:1 Hel ic o pt er Fl ig ht Co nt r o l Syst eE)2 Int r o duc t io nThis do c ument pr o vides t heS-3 Syst em Desc r ipt io nE 4 Syst em Requir ement sID2021pr uviuub dinuj ue dr iu diuiuuu r diu Lur iir ui udbuu ur i pnui ir ipui Lur nr r idr iub.3 System DescriptionThe f l ig ht c o nt r o l syst em c o nsist s o f pil o t input c o nt r o l s,c yc l ic and pedal s,a f l ig ht c o nt r o l c o mput er and hydr aul ic ac t uat o r s t o c o nt r o l t he main and t ail r o t o r s.A diag r am o f t he syst em is=sho wn in t he f ig ur e bel o w.22PilotInputFhghtnntmlHydraulic ActkwtcrHyckauKc 昌Cumr,匚User nan1%Requir ement s Edit o r回|次Edit Displ ay Anal ysis Repo r t Hel p画I m画画View:|Requir ement s Desc r ipt io nRat io nal eIndexIDSear c hSummar ykt Control Computer/恒Hel ic o pt ef Syst em Requi r ement s,鼬 Impo r t lllir时 J1X2vfejJisi一lij3.13.23.30000da80Ref er enc es t o Hel ic o pt er Syst emR1Hel ic o pt er Rig ht Co nt r o l Syst em 118Int r o duc t io n20Syst em Desc r ipt io n21The f l ig ht c o nt r o l syst em c o nsist s223.0-223The c yc l ic c o nt r o l s t he pit c h o f t h24Syst em Requir ement sKeywo r ds:ARf ieScownHricop t)4ry f rom wthf the whdt23$，?NK)ht timejg|QtytClTMm”1.UMLSt j Um Cm9 f|UieCM.UMSceMMiX，r23(Km Z3.Users 2.3 Usera njUjAOFiMHrAmieapM100ciw121,*?nn p-HF#m3z，rr&eJudoA，F*4m9*t4 BF Ftf n 99vtv tesrsvivxlx9*w MV a4fm TH WUBCt-B fr 1*l*r-t llftt 9f9 wf s B4m99 l BBS 9S1H 0S%9vl Aat 9t&B ft maw tf t*9if 1k9 214 fii yfftv f*/1 tm Hu vsv ac AcaF r 9H*YKi n CAKBIAB*MBlflwn tB tl-uty69BBB9MS IB6Ftt CflBll4H G9XIWC E Huffs son vmv CUH*fj nBwn BPSn*B9 rwufBtf Ks 9 9ui f K ffvs t999 flrtfi*f nviawoE-9W dfs aBnf rf BvflKV4vllt4lf*J V8 n%cmwrtscsvli 0S n rlB*rnf ft f9S4K or K C1K 71VAMMF YSB Aws tVX_BB fj 99f 9if fji FBI fvon*1 18 Flfv I-sls二星於22 Borland CaliberRM是一个基于Web和用于协 作的需求定义和管理工具，可以帮助分布式 的开发团队平滑协作，从而加速交付应用系白令 Cal iber RMFil e Edit Navig at e Sear c h Pr o j ec t Run Windo w Hel pI，x J q，中 s，o，CaliberRM-Eclipse Platform123三种需求管理工具的比较工具RequisiteProDOORSCaliberRM项目开发可扩展性将需求的数据存放在数据库中，而把与是企业级的产品：即，一个DOORS Database能够同时支持许多个不同的项目 需求相关的上下文信息存放在Word文档开发，从而使得新的项目能够复用和共享过去的文件和信息。不同项目（文件 中，用户使用ReqPro时必须安装Word 之间的追踪关系可以跨项目建立。只支持单个项目的开发，即.一个Database只能支持一个 项目的开发，因此无法支持对 过去文件和信息的复用和共 享。对需求变更的管理本身没有变更管理系统，只能依赖于与 Rational的配置/变更管理工具集成Clear Quest本身支持变更管理系统，即变更的提交，评审，应用，并因此可以给指定的用 户分配不同的角色本身没有变更管理系统，只 能依赖于与配置管理工具的 集成，但集成的功能比较弱.无法支持追踪关系对需求基线的管理只能依赖于与Rational的配置/变更管理 工具集成，但只能存储版本，无法比较 需求差异本身具备对需求的基线管理功能，可比较不同基线的需求差异，实现需求基线 管理；多个需求项及追踪关系 的显示一次只能显示一个需求项供用户观看，限制了用户同时直接阅读其它需求项，因此也不能在屏幕上一次显示相互连接 的多个需求项和文件。能够在屏幕上给用户一次显示一个文件中的多个或所有需求项和相互之间的追 踪关系（即支持横向和纵向的需求追踪），从而支持用户同时观看所有相互依赖 的需求项。一次只能显示一个需求项供 用户观看，因此大大限制了 用户同时参考其它需求项的 直观阅读。权限控制无法对不同的用户，对数据库结构自上具有灵活的权限控制，包括：只读，修改，创建，删除，管理等五种级别。权 到下的每一个层次做到灵活有效的权限限控制可以针对每一个用户在每一个database,项目目录，文件，需求项，属 控制。性上实施等可疑link（需求变更）的通知没有自动提示，必须通过追踪关系矩阵 来查找，当追踪矩阵比较大时，非常费 时费力；当link的一方产生变更时，Doors可以自动产生提示符通知另一方，而不需要在 link的矩阵上查找；没有自动提示，必须通过矩 阵来查找，当矩阵比较大时.非常费时费力。数据备份和恢复DOORS在恢复备份的数据时能够保证数据库中已有的文件不会被覆盖。当数 据库中已有同名的文件时，数据库系统会自动的给被恢复的文件另外的名字；由于Doors把所有数据均存放在数据库中，因此数据的备份和恢复过程又安全 既简单与其他工具的集只能与自身的软件工具集成作为独立的软件供应商，Telelogic DOORS不但可与Telelogic自身的其他软件 工具集成，还可与微软,IBM Rational,Mercury等厂商的工具集成异地需求管理无异地使用模式Doors提供灵活的方式实现需求异地管理的方式；Doors强大的性能优势也保障 了大型项目异地需求开发/管理的可能Import and Export（文件的导入导出）DOORS在从Word导入文件时，会把Word文件中的表格，图形和OLE对象原封 不动导入，并可以在DOORS中对导入的表格和OLE对象（如MS Visio图形）进行编辑。在从Word导入文件时，会丢 失所有Word中的表格，图形 和OLE对象，也就谈不上对 它们进行编辑了。2.0 需求管理工具的发展趋当前的软件产品越来越大越来越复杂5需 求信息也相应的复杂化、多样化，需求与需 求之间的关系错综复杂，而目前的多数需求 管理工具中的需求描述方法不能较好地对多 种层次中的需求信息进行描述。O过于笼统的描述会丢失有用的详细信息，而过于详细的 描述又产生了很多无关紧要的信息并导致需求跟踪、变 更管理等功能的极度复杂化，影响到有用部分功能的正 常实现。125软件项目需求管理越来越受到软件界的重视,软 件需求的不确定性是客观的事实，每年由此导致 的项目开发失败也是数不胜数。O需求管理首先要针对需求做出分析，随后提出解决方案。O需求分析是软件工程中的一个关键过程。，在这个过程中，系统分析员和软件工程师确定顾 客的需要.e只有在确定了这些需要后，他们才能够分析和寻 求新系统的解决方法。O需求分析阶段的任务是确定软件系统功能。O需求获取的主要方法包括，访谈和调研、专题讨论会、头脑风暴、场景串联。需求获取的关键，是沟通和交流。126