需求分析

• 第1关：需求分析的概念和任务
• • 任务描述
  • 相关知识
  • 作答要求
  • 答案
• 第2关：需求工程
• • 任务描述
  • 相关知识
  • 作答要求
  • 参考资料
  • 答案
• 第3关：需求变更
• • 任务描述
  • 相关知识
  • 作答要求
  • 参考资料
  • 答案
• 第4关：需求规格说明
• • 任务描述
  • 相关知识
  • 作答要求
  • 参考资料
  • 答案
• 第5关：需求管理
• • 任务描述
  • 相关知识
  • 作答要求
  • 参考资料
  • 答案

第1关：需求分析的概念和任务

任务描述

本关任务：根据所学有关软件工程中需求分析的知识，完成相关的选择题。

相关知识

为了完成本关任务，你需要掌握：1.软件工程中需求分析的基本概念以及任务，2.需求分析的方法以及标准。

需求分析
需求分析也称为软件需求分析、系统需求分析或需求分析工程等。

是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

需求分析的任务
需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。

此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。

需求分析的原则
为了促进软件研发工作的规范化、科学化，软件领域提出了许多软件开发与说明的方法，如结构化方法、原型化法、面向对象方法等。这些方法有的很相似。

在实际需求分析工作中，每一种需求分析方法都有独特的思路和表示法，基本都适用下面需求分析的基本原则：

1. 侧重表达理解问题的数据域和功能域；
   对新系统程序处理的数据，其数据域包括数据流、数据内容和数据结构。而功能域则反映它们关系的控制处理信息。
2. 需求问题应分解细化，建立问题层次结构； 可将复杂问题按具体功能、性能等分解并逐层细化、逐一分析。
3. 建立分析模型。
   模型包括各种图表，是对研究对象特征的一种重要表达形式。通过逻辑视图可给出目标功能和信息处理间关系，而非实现细节。由系统运行及处理环境确定物理视图，通过它确定处理功能和数据结构的实际表现形式。

需求分析的内容
需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。

具体分为功能性需求、非功能性需求与设计约束三个方面：

1. 功能性需求 功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。功能性需求是软件需求的主体。

   开发人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。

2. 非功能性需求 作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。主要包括软件使用时对性能方面的要求和运行环境的要求。

3. 设计约束 一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。

例如，要求待开发软件必须使用 Oracle 数据库系统完成数据管理功能，运行时必须基于 Linux 环境等。

需求分析的过程
需求分析阶段的工作，可以分为四个方面：问题识别、分析与综合、制订规格说明、评审：

1. 问题识别 就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。

   这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU
   等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。

2. 分析与综合
   逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。

3. 制订规格说明书 即编制文档，描述需求的文档称为软件需求规格说明书。

注意：需求分析阶段的成果是需求规格说明书，向下一阶段提交。

4. 评审 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作，否则重新进行需求分析。

需求分析的方法
目前，软件需求的分析与设计方法较多，一些大同小异，而有的则基本思路相差很大。从开发过程及特点出发，软件开发一般采用软件生存周期的开发方法，有时采用开发原型以帮助了解用户需求。在软件分析与设计时，自上而下由全局出发全面规划分析，然后逐步设计实现。

从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象四个方法。

1. 功能分解方法 将新系统作为多功能模块的组合。各功能亦可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解 ——
   功能、子功能、功能接口。
2. 结构化分析方法
   结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。

此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。

3. 信息建模方法
   它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是
   E—R 图。

经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是 E-R 图，其基本要素由实体、属性和联系构成。

该方法的基本策略是从现实中找出实体，然后再用属性进行描述。

4. 面向对象的分析方法 面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。

   面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)。

需求分析的特点
需求分析的特点及难点，主要体现在以下几个方面：

1. 确定问题难
   主要原因：一是应用领域的复杂性及业务变化，难以具体确定；二是用户需求所涉及的多因素引起的，比如运行环境和系统功能、性能、可靠性和接口等。
2. 需求时常变化
   软件的需求在整个软件生存周期，常会随着时间和业务而有所变化。有的用户需求经常变化，一些企业可能正处在体制改革与企业重组的变动期和成长期，其企业需求不成熟、不稳定和不规范，致使需求具有动态性。
3. 交流难以达到共识
   需求分析涉及的人事物及相关因素多，与用户、业务专家、需求工程师和项目管理员等进行交流时，不同的背景知识、角色和角度等，使交流共识较难。
4. 获取的需求难以达到完备与一致
   由于不同人员对系统的要求认识不尽相同，所以对问题的表述不够准确，各方面的需求还可能存在着矛盾。难以消除矛盾，形成完备和一致的定义。
5. 需求难以进行深入的分析与完善
   需求理解对不全面准确的分析，客户环境和业务流程的改变。市场趋势的变化等。也会随着分析、设计和实现而不断深入完善，可能在最后重新修订软件需求。分析人员应认识到需求变化的必然性，并采取措施减少需求变更对软件的影响。对必要的变更需求要经过认真评审、跟踪和比较分析后才能实施。

作答要求

根据相关知识，按照要求完成右侧选择题任务。作答完毕，通过点击“测评”，可以验证答案的正确性。

答案

第2关：需求工程

任务描述

本关任务：根据所学有关需求工程的知识，完成相关的选择题。

相关知识

为了完成本关任务，你需要掌握：1.需求工程的基本概念，2.需求工程的内容以及方法。

需求工程
需求工程是指应用已证实有效的原理、方法，通过合适的工具和记 ，系统地描述待开发系统及其行为特征和相关约束。

需求工程覆盖了体系结构设计之前的各项开发活动，主要包括分析客户要求、对未来系统的各项功能性及非功能性需求进行规格说明，并针对不同的对象可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。

在系统开发中，需求工程往往与体系结构设计交替进行，直到分解的子问题可以单纯地由软件或硬件系统解决。软件需求工程则是对应用于纯 软件系统开发生命期中系统设计之前的第一阶段。

因此，需求工程的目标相当简单明了：确定客户需求，定义设想中系统的所有外部特征。

需求工程的方法
需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上完成需求规范。

为了提高目标软件需求规格的质量，需求工程提出了以下几种方法：

• 结构化需求抽取方法

需求工程支持结构化的需求抽取过程，为需求的抽取过程提供构型未来系统的理念，提供需求抽取的线索、需求描述的框架和需求抽取方法论，明确指出需求抽取过程中所涉及的有关问题及其正确的处理方法，从而保证抽取过程的质量，并提供系统化、工程化的指南和有效的支持工具，使得需求信息的无二义性、完整性和一致性。

• 系统化的需求建模方法

需求工程支持系统化的需求建模过程和途径，为软件需求模型提供预定义的语义解释和预定义的语义约束，支持需求提供者和系统开发者从语义上正确地理解所获得需求信息的含义，使得需求提供者可以正确地判断当前已提供的需求信息是否真正表达了他们自己的意图，也使得系统开发者可以了解自己对需求提供者所提供需求信息的理解程度。

• 形式化的需求验证技术

形式化的验证技术是在形式化需求模型基础之上进一步保证需求信息正确性的手段。 它采用精确的数学语言来表达需求模型，并借助于数学推导的手段, 使得需求模型中含糊的、不完整的、矛盾的以及无法实现的表述能够被准确地发现, 从而尽早得到纠正。

形式化需求验证技术一般分为3类，分别是代数方法、基于模型的方法和基于进程代数的方法，它们分别适用于描述和分析不同类型的软件系统。

形式化需求验证技术的作用分为两个方面: 一方面是验证需求提供者的意图可满足性 (即需求模型的有效性)；另一方面是验证需求模型的可实现性 (即需求模型的正确性)，这一点使得形式化需求验证技术和一般的形式化方法得以区别开来。

形式化需求验证的意义在于：如果方法被正确使用的话，对于特定的语义是有充分定义的。

需求工程的阶段
综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段：

1. 需求获取

通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；

2. 需求建模

为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；

3. 形成需求规格

生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；

4. 需求验证

以需求规格说明为输入，通过符 执行、模拟或快速原型等途径，分析需求规格的正确性和可行性，包含有效性检查，一致性检查，可行性检查和确认可验证性；

5. 需求管理

支持系统的需求演进，如需求变化和可跟踪性问题。

需求工程的内容

• 需求获取阶段

再次，需求获取的开始，代表着软件项目正式开始实施，正所谓万事开头难。综合上述3个点使得需求获取成为软件开发中最困难、最关键、最易出错也是最需要交流的方面。

在工作开展中，主要是就业务流程、组织架构、软硬件环境和现有系统等相关内容进行沟通，挖掘系统最终用户的真正需求，把握需求的方向。在需求获取调研会中首先对需求获取方法作了验证。现行的需求获取方法一般有基于调查的需求获取方法、基于用例的需求获取方法、原型法等几种方法。各种需求获取方法各有利弊。

• 需求分析阶段

需求分析与需求获取是密切相关的，需求获取是需求分析的基础，需求分析是需求获取的直接表现，两者相互促进，相互制约。

需求分析与需求获取的不同主要在于需求分析是在已经了解承建方的实际的客观的较全面的业务及相关信息的基础上，结合软、硬件实现方案，并做出初步的系统原型给承建方做演示。承建方则通过原型演示来体验业务流程的合理化、准确性、易用性。同时，用户还要通过原型演示及时地发现并提出其中存在的问题和改进意见和方法。

• 文档编写阶段

需求开发的最终成果是，在对所要开发的产品达成共识后，所编写的具体的文档。需求文档是在需求获取和需求分析两个阶段任务结束时生成的，所以文档要包含所有需求。

• 需求确认阶段

需求确认主要是针对《需求规格说明书》的评审，保证需求符合优秀需求成熟的特征，并且符合好的需求规格说明的特征。

在需求确认阶段需要保证以下几点：

① 软件需求规格说明正确描述了预期的满足各方涉众需求的系统能力和特征；

③ 需求是完整的、高质量的；

④ 需求的表示在所有地方都是一致的；

⑤ 需求为继续进行产品设计和构造提供充分的基础。

• 需求跟踪阶段

需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，确保产品依据需求文档进行开发，建立与维护“需求——设计——编程——测试”之间的一致性，确保所有工作成果符合用户需求。

需求跟踪是一项需要进行大量手工劳动的任务，在系统开发和维护的过程中一定要随时对跟踪联系链信息进行更新。需求跟踪能力的好坏会直接影响产品质量，降低维护成本，容易实现复用，同时，需求跟踪还需要建设方的大力支持。

• 需求复用阶段

在软件项目实施过程中，许多不同项目间存在着许多相似的需求，尤其是类型相同的项目在不同的用户群众的实施中，需求的相似性就更加明显、更加普遍了。

有了需求复用，建设方就能快速的形成一个需求的原型，这样，后期的需求工作只需要在此原型的基础上进行修改、扩充和完善即可，大大提高了需求分析的工作进度。所以，对于需求的复用就需要加以重视。

对于需求复用，首要责任就是要提取可复用的需求，对需求复用的理解和扩充。其次就是要保证需求复用不存在冲突。

• 变更控制阶段

需求变更在软件项目开发中是不可避免的。无休止的需求变更只会造成各种资源无休止的浪费，但是其中也不乏有许多是必要的、合理的需求变更。

对于需求变更，首先是要尽量及早的发现，以避免更大的损失。其次，是要采取相应的、合理的变更管理制度和流程，这样同样可以降低需求变更带来的风险。

• 版本控制阶段

版本控制是管理需求规格说明和其他项目文档必不可少的一个方面，也是需求变更文档化管理的最有效办法。可以详细记录发生需求变更的需求文档版本的版本，发生变更的原因，变更发生的控制记录，并对变更后的需求文档进行唯一版本 的标识。使得每个成员都能及时访问最新版本的需求文档。

实施版本控制的基础是需求基线，所谓需求基线就是项目组成员一经承诺将在某一特定产品版本中实现的功能性和非功能性需求的集合。需求基线的确定可以保证项目的涉众各方可以对发布的产品中希望具有的功能和属性有一个一致的理解。

作答要求

根据相关知识，按照要求完成右侧选择题任务。作答完毕，通过点击“测评”，可以验证答案的正确性。

参考资料

《CMMI 3级软件过程改进方法与规范》

答案

第5关：需求管理

任务描述

本关任务：根据所学有关需求管理的知识，完成相关的选择题。

相关知识

为了完成本关任务，你需要掌握：1.需求管理的基本概念，2.需求管理的流程和任务。

需求管理
需求管理（ Requirement management ）是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。

一套需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。

不同的需求组合起来，构成了一套完整的需求模型。用户需求决定了系统设计所要解决的问题，所要带来的结果。可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。

需求管理的过程，从需求获取开始贯于整个项目生命周期，力图实现最终产品同需求的最佳结合。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。

需求管理能够确证：

• 我们确知客户的需求是什么（质量）；
• 满足客户需求的最佳解决办法（统一性）。

著名学者 Crosby 对于质量的定义是”同需求保持统一”。从这个意义上说，需求管理正是从质量出发以确定需求。每个人都应当始终明白他们所做的具体任务其意义何在。然而，在一个产品的生命周期里，其需求性是能动的，是处于变化之中的。需求管理本就是一个动态的过程，离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。

需求管理流程
需求管理可细分为如下几个流程：

• 问题分析

问题分析可以通过了解问题及涉众的最初需要，并提出高层解决方案来实现。它是为找出”隐藏在问题之后的问题”而进行的推理和分析。

问题分析期间，将对”什么是面临实际问题”和”谁是涉众”等问题达成一致。而且，您还要从业务角度界定解决方案，以及制约该解决方案的因素。您应该已经对项目进行过商业理由分析，这将便于您更好地预计能从构建中的项目中得到多少投资回 。

• 理解涉众

提供这些信息主要出处的个人在本项目中称为涉众。如果您正在开发一个在您公司内部使用的信息系统，那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员。通常讨论将在业务模型这一级上展开，而不是在系统这一级上展开。如果正在开发一个要在市场上出售的产品，那么您可以充分调动营销人员，以便更好地了解该市场中用户的需要。

获取需要的活动可使用这样一些技巧：访谈，集体讨论，概念原型设计，问卷调查和竞争性分析等。获取结果可能是一份图文并茂的请求或需要列表，并按相互之间的优先级列出。

• 定义系统

定义系统指的是解释涉众需求，并整理为对要构建系统的意义明确的说明。

在系统定义的初期要确定以下内容：需求构成，文档格式，语言形式，需求的具体程度（需求量及详细程度），需求的优先级和预计工作量（不同人在不同的实践中通常对这两项内容的看法大不相同），技术和管理风险以及最初规模。

系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。

• 项目规模

为使项目高效运作，应仔细根据所有涉众的需求确定优先级，并对项目规模进行管理。有的开发人员仅仅重视所谓的”复活节彩蛋”（即开发人员感兴趣或觉得有挑战性的特性），而不是及早将精力投入降低项目风险或提高应用程序构架稳定性方面，这已使太多的项目蒙受损失。

为确保尽早解决或降低项目中的风险，应以递增的方式开发系统。要慎重选择需求，以确保每次增加都能缓解项目中的已知风险。要达到目的，您需要和项目的涉众协商每次迭代的范围。通常，这要求具备管理项目各个阶段的期望结果的良好技能。

我们认为用例方法是传达系统目的和定义系统细节的一种行之有效的方法，它常与简单的可视化原型结合使用。用例有助于为需求提供一个环境，利用它可生动地说明系统使用的方式。

系统详细定义的另一个构件是说明系统采用的测试方式。测试计划及要执行测试的定义将会说明要核实哪些系统功能。

• 需求变更

定义需求时无论怎样谨慎小心，也总会有可变因素。变更的需求之所以变得难以管理，不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性，而且也因为对某个需求的变更很可能影响到其他需求。

应确保赋予需求一个有弹性的结构，使它能适应变更，并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系。管理变更包括建立基线，确定需要追踪的重要依赖关系，建立相关项之间的可追踪性，以及变更控制等活动。

需求管理的任务
可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化。需要始终保持注意的是，需求性是始终处于变化之中的。

需求管理需要完成的任务包括：

• 明确需求并达成共识；
• 建立关联；
• 根据不同需求设计相应解决办法；
• 进行系统优化；
• 提出设计方案；
• 监控和解决可能出现的问题以及需要做出的改变；
• 控制不同开发任务的开展；
• 对最终产品做出评测；
• 监控可能出现的重复开发；
• 提出项目实施时间表；
• 确定最终用户界面。

有时候我们所进行的需求分析只停留于分析本身，而没有进一步去思索我们为什么要进行需求分析。需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下药、量体裁衣，才能才设计开发中去伪存真，不断改进。

“需求之需求”正是强调了贯穿始终的需求分析的重要。离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。需求管理所产生的效益或许并不明显，或许要日后才能体现，但是无序的，没有经过精心策划的需求管理是不可能产生效益的。

下面介绍前述内容没有涉及到的几点：

• 需求共识

首先，用户需求通过非术语的形式进行表述，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。这里的”用户”泛指在实际应用环境中每一位可能使用最终产品的人。如果一个产品不能满足客户所需，那么设计方案再出色也无济于事，许多方案有很高的技术设计水准却最终不能获得成功，其原因正在于此。可以把产品功能说得天花乱坠，但却无法改变用户需求决定最终产品基本模式的事实。

需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。因此用来进行需求分析的语言组织应当使所有相关人员，包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一个人在项目中所起的作用。因而需求管理需要解决的第一位也是最基本的任务就是明确需求，并使所有相关人员达成共识。

我们在进行系统设计时，应当首先建立一个需求模型，但不能是为了建模而建模，需求模型实际是最终产品的抽象化表现。需求模型的建立使我们在明确需求的基础上更进一步，使我们知道我们将要生产何种产品，该产品都具有那些功能。同时，创建需求模型的过程也使开发者明确自己的工作如何同整个项目有机地结合在一起。建立需求模型应当充分研究不同类型、不同架构建模方式的可行性，切忌主观武断。

• 系统优化

任何设计都应以考虑用户需求为优先，用户需求的满足程度即成为衡量设计优劣的标准。在一个项目设计周期中，开发人员经常会面临选择，以提炼需求，决定开发的优先次序，并在不同的实施方案中作出选择。这些选择必须考虑到收益与付出地平衡比例，这种选择的重要性尤其在建立需求模型的后期凸现出来。基本需求在这时都已明确，而实施方案还未敲定，为了使用户的基本需求得到落实，一定程度的开销用于搭建不同构架的需求模式是合理的。假使我们已经有了一套翔实的需求分析，我们甚至不必将每一套方案都付诸实行，就可以成功地对系统设计进行优化。

面对不同的可行性而需要作出选择时，我们也必须参照收益与付出的比例关系。例如，在被要求提供计划书时（Request for Proposal），我们应当尽量做到每一份计划书的提供都物有所值。

• 方案设计

明确需求后，开发人员就可以进行方案设计。通过对用户需求和设计方案之间所存在关联性进行分析比较，我们就能够对设计方案进行评估。

• 方案修改

方案的设计不可能是一成不变的，经常会有方案设计同需求相悖的情况。如果我们无法准确把握用户需求同方案设计之间的关系，我们就无法在需要对方案进行必要修改时正确判断。优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。

• 任务划分

一个大的开发项目可能涉及20?30组不同的开发队伍，人员包括技术工程师、软件工程师以及具体项目主管等等，而每一个模块都有它自己的开发工具和开发语言。

主持一个大项目的开发并不是件容易的事，总体项目主管的首要任务是对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。总体项目主管可以将细化的不同模块的需求分析交给不同的开发队伍，对于开发进程的监控只需参照需求的解决情况，对于具体的开发细节则不必过问太多。

不同的开发队伍会使用不同的开发语言和开发工具，会使用不同的符 和标记。相反，作为总体项目主管所使用的语言、符 和标记等则必须简单易懂，以使所有的开发人员都等理解。换言之，总体项目主管应当使用自然语言，或只涉及少量的，简单的术语和专用词汇。

• 产品测试

需求的满足情况是决定最终产品成败的判定基础，对最终产品的测试评估必须以产品所试图解决的需求为标准。

这里有一个需求、产品和测试系统之间的关系问题，确定需要进行的测试属于总体开发主管的工作范畴，虽然具体工作并非都要由开发主管来亲自完成。

• 重复开发

对于总体开发主管而言，针对方案设计的修改是一项经常性的工作（因为修改而造成的影响则应当尽可能减小）。在进行项目开发时，随着开发进程的深入，各种修改的建议和问题的 告是屡见不鲜的，每解决一个问题，就是将产品同其需求性的结合又完善了一步。存在问题正是需求性尚未满足的表现。

方案设计的完善和需求性的满足是同步的，因此真正的用户对于产品的评价和建议尤其具有重要意义。在那些一步到位的产品设计中，真正用户无法左右开发进程；但在一个能够进行重复设计、重复开发的产品生命期中，开发人员应当及时搜集用户对于产品的反馈信息，并将这些信息结合到下一步的开发工作中去。

作答要求

根据相关知识，按照要求完成右侧选择题任务。作答完毕，通过点击“测评”，可以验证答案的正确性。

参考资料

产品经理如何进行需求管理

答案