需求工程需求工程过程

《需求工程需求工程过程》由会员分享，可在线阅读，更多相关《需求工程需求工程过程（64页珍藏版）》请在金锄头文库上搜索。

1、 信 息 科 学 与 技 术 学 院第二讲：需求工程过程第二讲：需求工程过程 目的：介绍为软件加强型系统中的复 杂软件设计的需求工程过程，涉及 抽取需求 分析需求 验证需求 管理需求 主要关注点：需求工程中要做些什么信 息 科 学 与 技 术 学 院软件需求工程的内容软件需求工程需求开发需求管理需求建模需求获取需求规格说明需求验证建立基线变更控制需求跟踪信 息 科 学 与 技 术 学 院2.1需求分析员2.1.1需求分析员的职责需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。(是一个角色，而非职务，重要的是具备必要的能力和知识)需求分析员是客户与开发人员交流的中间人，

2、负责将客户对产品的初步想法转化为明确的需求说明，用来指导开发工作。需求分析员必须先充分理解用户对新系统的目标，然后再定义功能和质量需求。由此项目经理才能对项目进行估算，开发人员才能进行设计开发，测试人员才能对产品进行验证。信 息 科 学 与 技 术 学 院2.1.2 需求分析员必备的技能 出色的交流、引导和人际交往能力 技术和业务领域的丰富知识 适合这项工作的相应的个性倾听的技巧有效的倾听要求不能分神，保持专注的姿态和目光接触，以及重复要点以证实你的理解。要抓住对方说的每一句话，从中找出他们因犹豫而没说出的内容。要熟悉合作者的表达习惯，避免用个人的理解方式来过滤客户所说的话。 信 息 科 学

3、与 技 术 学 院交谈和提问的技巧大部分需求是通过讨论得到的，因此必须能够与不同的个人或小组就需求展开讨论。与高级经理或某些固执己见、盛气凌人的人打交道，必须学会通过提出适当的问题，让重要的需求信息显现出来。例如：用户很自然地把注意力集中在系统正常和预期的行为上，然而，很多代码却是为了处理异常而编写的。需求分析员必须研究和了解可能出错的情形，并决定系统如何响应。信 息 科 学 与 技 术 学 院分析能力能够以不同的方式思考问题：有时必须将高层的信息不断细化；另一些情况下需要将某个用户提出的一项特定的需求推广为一组需求，以满足众多的同类用户。要严格评估各种来源的信息，以便消除需求中的矛盾，区分出

4、“需要”与真正的需求。信 息 科 学 与 技 术 学 院协调能力由于所处位置（立场）的不同，各角色人员（如业务人员与IT人员）之间不时会出现紧张关系。一位具有良好的提问、观察、协调能力的中间协调人能够帮助团队建立信任。观察能力敏锐的观察力能够从不经意的闲谈中发现重要信息。通过观看用户工作，如何使用现有程序，可以察觉用户不曾提及的细微之处。信 息 科 学 与 技 术 学 院写作能力需求开发提交的主要结果是书面的需求规格说明，用于在客户、操作人员、管理人员和技术人员之间传递信息。语言驾驭能力极其重要。组织能力在处理获取和分析过程中收集到的大量杂乱的信息时，只有具备良好的组织能力和从混乱、含糊的信息

5、中找出真正意义的耐心和韧性，才能妥善处理快速变化的信息，并将其组织成一致的整体。信 息 科 学 与 技 术 学 院建模能力掌握从传统的流程图到结构化分析模型，直至当今的统一建模语言(UML)等多种分析工具。这些工具中有些用于与客户交流，而另一些则用于与开发人员交流。人际交往能力 具备让彼此利益竞争的人们进行合作的能力。 能够轻松的与组织中各级别的人打交道。 与分布在各地的虚拟团队一起工作。 与拥有不同文化背景或母语的人交流。信 息 科 学 与 技 术 学 院创造力需求分析员不能像抄录员那样只记下客户说过的每句话。一流的需求分析员能够创造需求，构思新颖的产品功能，推测新的市场和商业机会，并且思考

6、让客户惊喜的方法。能够帮助用户发现隐含的需求，并且找到新方法来满足这些需求。信 息 科 学 与 技 术 学 院2.1.3 需求分析员必备的知识除了前面提到的专门技能和性格特点，还需具备从实践中积累的广博的知识。l掌握和熟练运用不同软件开发模型中的需求管理技术l充分理解项目管理、风险管理和质量工程，有助于避免因需求问题导致项目失败。l对商业软件：掌握产品管理理念，了解如何定位和开发企业软件产品。掌握应用领域的知识是减少与客户间误解和避免需求失败一个重要的因素。信 息 科 学 与 技 术 学 院2.1.4 如何培养需求分析员优秀的需求分析员是培养出来的，而不是训练出来的。这项工作包括很多面向人而不

7、是技术的“软性技能”。不同背景的人能力水平有着不同的展现：实践经验、工程技术、项目管理、技术和工具、质量以及个性。如下是不同背景的人转而成为需求分析员的优劣势：信 息 科 学 与 技 术 学 院从用户转为需求分析员很多企业的IT部门中都有由用户转行而来的业务分析员。优势：这些用户对所从事工作领域的业务和工作环境有着深刻的理解，了解现有系统和业务流程，熟悉专业语言，容易获得原来同行的信任。劣势：容易自认为比用户更了解需求，而不尊重实际使用者的意见。局限于现有工作模式，跟不上业务的最新发展。信 息 科 学 与 技 术 学 院从开发人员转为需求分析员优势：熟悉技术和开发流程，了解实现的难易，易于引导

8、用户少走弯路，善于创造需求，技术专家的背景容易获得用户的尊重。劣势：需求开发工作对人员技能和个性的要求与软件开发工作不同，不少开发人员对用户缺乏耐心。容易陷入具体技术和软件本身，而不是用户的需求。开发人员要想成为需求分析员，需多掌握业务领域知识，提高“倾听、协商、引导”等软性技能水平。信 息 科 学 与 技 术 学 院主题专家有些软件组织雇用某些有高职位背景的专家级用户担任需求分析员或用户代表，这些人精通产品，并且在应用领域内有着丰富的经验。问题：容易根据自己的偏好定义系统的需求。往往希望实现高端、全能的系统，而忽略了实际现状。主题专家更适合作为用户代表来配合需求分析员的工作。信 息 科 学

9、与 技 术 学 院2.2软件生命周期与软件需求工程过程2.2.1软件生命周期 最经典也是最早提出的软件生命周期模型是瀑布模型，它给出 了一个系统的 严格顺序的软件幵发方法，每个阶段之间具体比 较严格的划分，也有固定的制品 作为阶段幵始和结束的标志。 其他软件生命周期模型包括，增量式模型，演化式 模型等，基 本上都是在瀑布模型的基础上演化出来的。从瀑布模型上演化 出来后 面的这些模型，是因为在实际的项目中很少能严格遵循 这些活动之间的顺序。比 如，增量式模型是以迭代的方法运用 瀑布模型，以解决不能一次性完成所有软件 需求，而必须以一 种增量的方式不断丰富和完善软件产品。而演化式模型则用来 应对初

10、始的软件需求没有明确的定义，需要不断与软件需求提 供方沟通，逐步使 软件需求明确化和完整化，或者刻画软件系 统随时间的推移而演化的过程。信 息 科 学 与 技 术 学 院2.2.1软件生命周期 随着软件技术的进步和软件加强型系统应用深入和普及，瀑布模 型本身也在 不断发展，如下图所示，早期的版本一般按分析、设 计、编码、部署划分的生 命周期。而在(Pressman,2005) 中的一 个比较新的版本是按沟通、策划、建 模、构建和部署等五个阶段 划分软件生命周期。从中不难看到，由于软件设 计和编码技术的 发展和成熟，软件幵发的核心任务或活动已经转向与软件需求相 关的活动，在早期瀑布模型中，第一个

11、活动“分析”与软件需求相关 ，而在后来 的瀑布模型中，有三个活动“沟通”、“策划”和“建模”都 与软件需求相关。这 样的认识上的变化，一方面说明了软件需求 工程的必要性已经得到普遍的汄可， 另一方面也说明了软件需求 工程的方法和技术将在软件幵发过程中起到越来越重 要的作用。早期瀑布模型 更强调前期活动的瀑布模型信 息 科 学 与 技 术 学 院2.2.2需求工程的过程综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段： （1）需求获取：深入实际，确定待开发的软件系统的用户类，通过与用户 的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户 的需求； （2）需求分析及建模

12、：主要对收集到的需求进行提炼、分析和认真审查， 确保所有参加人员取得一致共识。找出错误、遗漏和不足，为最终用户所看 到的系统建立模型，根据软件需求信息建立软件系统的逻辑模型或需求模型 。需求模型作为对需求的抽象描述，尽可能多的捕获现实世界的语义，并确 定非功能性需求和约束条件和限制。 （3）形成需求规格：根据收集的需求信息和逻辑模型生成需求模型构件的 精确的形式化的描述，作为用户和开发者之间的一个协约编写需求规格说明 及其文档。 （4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型 等途径，分析需求规格的正确性和可行性； （5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问

13、题。当需 求发生变更时，对需求规格说明及需求变更实施进行管理。需求工程也是一 个项目工程，因此也包括了项目的管理。信 息 科 学 与 技 术 学 院2.3 需求获取l需求获取是需求工程的主体内容之一。获取需求是一个确定和理解不同涉众的需要和约束的过程。l涉众团体( 所有能够影响软件系统的实现,或者被实现后的软件系统所影响的个人和团体 )之间的相互沟通，识别需要的过程。涉众团体通过这个过程提取、定义需求。需求获取既涉及技术问题，也涉及社会交往问题。 难点：缺乏领域知识,应用领域的问题常常是模糊的、不精确 的； 存在默认的知识,如难以描述的常识问题； 存在多个知识源,且多知识源之间可能有冲突； 客

14、户可能的偏见，如不能提供或不想告知你所需要了解的事 情。信 息 科 学 与 技 术 学 院案例3个月前，甲新加入一家公司。很快他进入到一个项目里 ，这个项目是为某公司提供一个信息管理系统，主要是管 理供应商的情况。当时项目刚处于初期，主要是获取需求 ，做DEMO，然后去为客户作演示。其中主要是甲做开发。 甲以前主要一直做系统的开发和设计工作，加入这个项目 后，公司希望他作为项目的PM，来推动这个项目往前走。 然而,甲对这个客户行业（某工程行业）非常不了解，因 此对获取需求毫无办法，虽然他也希望能参考一些类似的 系统，但一直没有找到。所以基本上就是公司有客户关系 的人零零碎碎的发过一些需求，然后

15、他去照着做。最近， 客户终于认为甲做的系统并不适合他们。所以这个项目可 以说是失败了，于是，公司认为甲没有达到要求，解除了 合同。信 息 科 学 与 技 术 学 院需求获取的过程：确定需求开发计划建立项目前景与范围确定调查对象实地收集用户需求信息确定非功能需求和约束条件信 息 科 学 与 技 术 学 院2.3.1 确定需求开发计划确定需求开发计划的基本任务是确定需求开发的实施步骤，给出收集需求活动的人员、具体安排和进度。需要重点注意的是：l针对不同层次的调查对象，安排的调查人员在阅历和经验上的对等原则。l调查人员的沟通和业务理解能力必须适当。l用户的时间延误、文档确认的时间要在计划进度中预留。

16、信 息 科 学 与 技 术 学 院2.3.2确定产品前景与项目范围本阶段的任务是帮助投资管理人、产品经理弄 清楚“为什么要作这个项目？”，组织的业务目标以及系统最终版本具备哪些功能的长远规划。产品前景（product vision）描述了产品用来干什 么，它最终会是什么样子。项目范围（project scope）确定当前的项目要解决 产品长远规划中的哪一部分。项目范围的细节体现 于项目定义的需求基线。产生文档：前景与范围文档。信 息 科 学 与 技 术 学 院前景与范围的关系前景关系到整个产品。当产品的战略定位或业务目标随时间发生改变时，前景也会变化。范围则只与一个特定项目，或实现产品功能下一增量的某次迭代相关。产品前景包括了每一个计划产品版本的范围信 息 科 学 与 技 术 学 院通过业务需求定义前景回顾：业务需求（ business requirement）表示组织或客户高层次的目标。来源：项目投资人、购买产品的客户、实际用户的管