软件开发 迭代-快速迭代开发

需求管理对软件项目的重要性

信息技术革命正在迅速更新我们生活的社会。 信息技术不再仅作为一种独立的技术存在。 各行各业对信息化手段和技术的采用越来越突出，对软件的需求越来越大。 与这个蓬勃发展的软件产业的前景相反，软件产业落后的生产方式已经不能满足当前信息时代的高速增长。 软件需求，大型信息系统的成功率仍然很低。

以计算机软件和集成电路技术为主导的信息技术革命正在迅速更新我们所处的社会。信息技术不再仅仅作为一种高科技技术存在，而是广泛渗透到生产、经营和管理过程中，成为一种辅助手段。他们发展的手段和管理工具。

信息的采集、分析、处理、整合和发布是信息产业的核心内容软件开发 迭代，都离不开软件。 软件是计算机的核心，信息社会需要许多功能灵活的软件系统。

然而，自20世纪60年代以来，全球软件行业落后的软件生产方式已不能满足当今信息时代快速增长的软件需求，传统的软件开发方式和软件产品设计流程已不能满足当今多元化的业务需求，从而导致软件开发和生命周期维护过程中出现一系列严重的问题。

所以我认为“软件项目中的需求管理”是软件项目成败的关键，对项目的成败起着决定性的作用。 下面将说明需求管理在软件项目中的重要性。

现阶段需求管理存在的问题主要体现在以下几个方面：

1. 软件项目范围、进度和成本估算的准确性低。

软件项目开发的实际成本远高于预估成本； 同时，与预期进度相比，实际进度延迟数月甚至数年。 这种现象降低了软件组织的可信度。

2. 客户对最终交付的产品满意度较低。

软件开发人员在没有清楚地了解用户需求并且没有对他们面临的问题领域进行准确分析和设计的情况下开始开发和编写程序。 实际产品偏离了客户的预期功能，无法解决客户的真实需求，导致客户满意度下降。

3、软件产品质量不尽如人意。

软件质量保证技术在软件开发过程中没有得到彻底采用，必然导致软件产品出现质量问题。 没有审计、审查和彻底测试的软件必然是低质量的并且容易出错。

4、软件不可维护，生命周期短。

软件程序中的错误难以改正，当新的需求或需求发生变化时，原有的架构不易维护，无法根据用户的新需求改变原有的架构。 缩短了软件的使用寿命，增加了软件的成本。

5、软件缺少配套文档。

软件产品应该有一套完整的文档。 然而，在进度和成本的约束下，文档的编写和更新也让软件组织疲惫不堪，每个人对文档内容的深入程度和阐述程度都不尽相同。 另外，企业缺乏配套的文档系统和文档模板，给文档编写带来了困难。软件的二次开发也缺乏相关文档。

二次开发和维护增加了很多困难和问题。

6、系统集成项目的软件成本不断上升。

集成电路技术的发展日趋成熟，生产自动化水平不断提高，使得硬件采购成本不断下降。 但是，由于人工成本的增加，软件成本随着通货膨胀、软件规模、软件数量的增加而逐年上升。

由此不难看出，需求管理不善是造成软件危机的根本原因，体现在以下几个方面：

1、在软件开发最终交付之前，客户自己并不知道自己真正的需求；

2、由于需求人员技能有限，收集遗漏、模糊、误解的需求；

3、在软件开发的过程中，需求是不断变化的；

4、需求管理人员没有更好的把握需求的变化，导致后期维护成本不断增加，导致项目失败。

由于软件管理是一门新兴学科，缺乏实用的方法论和理论工具。 软件开发不同于传统制造业。 软件开发过程是一个逻辑思维过程，软件产品的质量取决于人员。 综合性人才的缺乏也导致了现有的软件开发模式无法适应当今的软件需求，导致了软件危机。

但是现在软件开发的规模还在不断增加。 随着互联网时代的到来，软件从桌面走向互联网，从小规模使用走向企业管理信息化，软件开发规模越来越大。一个软件项目的开发工作不再是个人或单一角色可以承担的事情。

同样的完成。 然而，大多数项目管理人才不熟悉软件开发方法，软件开发人员缺乏管理技能。 信息交换的延迟、误解和对项目最终目标的误解可能会破坏软件项目。 软件开发项目的开发人员不能有效、独立地处理大型软件开发的所有关系和各个分支，容易出现疏漏和错误。

软件产品的复杂性不断加深，规模的扩大必然带来结构上的更多分支。 传统的结构分析方法已经不适合当今信息化的软件产品需求。 软件开发工作无法一次迭代完成，而是根据用户需求的优先顺序，与客户共同协商，分阶段定制产品交付周期。 随着信息技术的发展，产品的用户数量和实施规模不断增加。 这也导致软件使用场景越来越多，软件功能的复杂度加深，需求管理的紧迫性也越来越大。

在这场软件危机下，新的软件开发方式不断被探索和探索。 以下六点被认为是解决软件危机和为客户开发好的系统的最佳软件实践：

1、迭代开发：在软件开发的初期，无法获得完整准确的用户真实需求。 这是因为随着项目的进展，客户对最终产品的要求在整个软件开发阶段不断变化。 现代软件开发提倡的迭代开发，让需求在每次迭代中发生变化，通过不断的细化加深对问题的理解。迭代开发不仅可以降低延迟交付的风险，还可以支持生产可交付版本在每一次迭代过程中，都可以提供给客户试用，既减轻了客户的等待，又产生了积极的反馈，推动了发展。

头发工作人员。

2. 需求管理：客户业务建模过程贯穿整个开发周期。 随着项目进入迭代，新的和变化的需求使得业务模型不断根据最新的需求进行修改，指导开发等后续工作。

3、使用组件架构进行开发：组件是软件技术的重大技术突破。 组件让重用成为可能，系统的灵活性大大提高。 基于高内聚低耦合的模块化组件架构，降低了管理复杂度，提高了代码复用。

4、建立可视化模型：uml逐渐成为软件工程师广泛采用的建模工具，软件从业者一致认为可视化建模在需求管理中发挥着重要作用。 客户和开发人员都可以尽早获得有关软件结构和行为的信息，尽早发现隐藏的风险，从而从中受益。

5. 验证软件质量：软件质量评估不再是交付后的或单独的活动，而是从定义需求基线的那一刻起就随着生命周期持续进行。

6. 变更控制：控制、跟踪、监控和修改需求变更。 在变更开始时，确定变更原因并确认变更范围，然后采用适当的变更处理方法。 主动控制项目中产生的变更，而不是被变更所控制。

需求管理对软件项目的影响：

需求管理随着软件产业的发展而逐渐成熟。 软件行业发展初期，软件规模较小，软件产品开发的重点是代码编写、产品

对需求分析的关注较少。 当开发技术不再是软件产品的瓶颈，客户对软件的需求越来越复杂，生命周期的概念出现在软件行业，需求分析自然成为其初始阶段。

随着软件系统规模化和信息化的发展，需求分析是整个项目的基础，其定义的业务基准在整个软件项目中越来越重要，直接关系到项目的成败。

美国1995年以来的一项调查显示，通过对美国8000个软件项目的跟踪分析，由于需求相关原因导致的项目失败率高达45%，缺乏明确的需求和缺乏用户批准的需求基线占项目失败的 25%。 需求管理是项目范围管理的基础。 只有明确了用户需要的产品范围，才能作为后期开发的前提。 如果一开始没有明确的业务范围和业务模式，就会让后期的发展脱轨。

需求管理活动分为两部分，一部分属于需求开发，一部分属于需求管理：

1. 需求开发是通过对客户及其行业的调查分析，捕捉用户需求软件开发 迭代，定义系统需求的过程。

2、需求管理是建立客户与承包方对产品需求的一致认可，就需求管理方法和手段达成一致，共同控制需求变化的过程。 需求开发又可以分为“业务分析”和“系统分析”两个阶段。 需求管理又可以分为：需求确认、需求跟踪、需求变更控制。需求确认是指项目甲乙双方共同审核需求文档，甲乙双方

需求基线约定好后，再做纸质约定，使需求文档具有评审验收的效果。 需求跟踪是指通过比较需求基线与项目最终产品的匹配关系，持续维护“需求跟踪矩阵”，以确保产品按照客户提出的需求进行开发。 需求变更控制是指按照“变更建议-范围分析-方案选择-审核确认”的流程处理需求变更，确保项目中的需求变更处于可控过程中，不会因损失而导致项目失败的控制。

软件项目也遵循项目管理的一般原则，包括项目范围管理、进度管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理等过程。

需求管理可以粗略地理解为范围管理。 需求管理定义的软件功能基线确定了项目的产品范围，明确了要开发的系统具有哪些功能，不具有哪些功能。 需求管理定义的基线是双方共同遵守的，为后续工作提供基石。

只有在明确需求基线的基础上，才能在其之上制定进度管理计划，层层分解任务。 实现进度的控制，可以在时间节点根据需求基线进行小规模的测试工作。 在此之上，软件组织中的成本管理团队可以根据进度计划制定成本绩效管理计划，并根据员工工作完成情况统计员工的绩效信息。 这一切都基于需求管理定义的明确需求基线。

只有实现了范围、进度、成本的动态管理，质量管理、人力管理、沟通管理才具有现实意义。 软件质量保证团队可以根据需求基准对完成的系统组件进行早期跟踪测试； 人力资源部也可以

可随时对排程进行人力资源调整； 明确的需求基准可以减少团队成员之间的冲突，并使沟通变得简单有效。

需求管理提倡的早期准确挖掘客户需求，可以使项目人员及早发现和发现项目中的风险隐患，在项目早期减轻或避免潜在风险。 同时，清晰的需求基线可以为元器件产品采购带来判断标准。

综上所述，需求管理是有效实现项目管理各个环节的基础。 只有为项目打下坚实的基础，后续工作才能顺利开展，实现业主和开发商的双赢。

需求管理方法：

1、业务背景分析：业务背景分析可以通过了解客户的初始需求，提出概念性的解决方案来实现。 就是通过分析推理，找出客户真正的需求。 在业务背景分析过程中，甲乙双方将就“业务背景”、“项目利益相关方”等问题达成共识。

2.初步需求建模：需求来自客户的各个层面，如来自客户决策层、管理层、执行层、第三方等。掌握如何准确判断需求的判断和来源，以及如何接近这些来源并从中获取原始需求信息。 在此基础上，整合提取的原始需求，建立初始需求模型。

3、需求模型改进：根据客户需求，进一步梳理拟建信息系统明确的功能规范。在需求阶段明确定义和度量以下内容：需求基线、文档类型、内容形式、需求描述层次、需求优先级和可预测的工作量，可能的技术和管理风险，以及系统的最大

初始规模。

4. 项目规模：为了使项目工作成功，需求经理应该优先考虑所有涉众的需求并管理需求的范围，而不是过早地投入精力进行大量的开发工作。 为了确保及早发现和减轻项目中的风险，软件组织更愿意以增量和迭代方式开发系统。 更谨慎地对待需求，让每一个额外的内容都能降低项目中的风险。 为取得良好的管理效果，需要需求经理和客户共同协商每次迭代的范围。

5. 需求变更：不断变化的需求之所以难以管理，不仅是因为一个新特性的需求变更需要额外的时间来实现，还因为某个需求变更很可能会影响到其他已实现的需求。 为此，需求管理者应该建立一个弹性的业务模型结构，使其具有灵活性、适应变化的能力，并保证需求来源的可追溯性。 管理变更包括建立需求基线、确定需求来源关系、建立相关需求项之间的可追溯性，以及持续开展变更控制活动。

综上所述，需求管理作为软件工程的一部分，越来越受到各个软件组织的重视和认可。 其重要性和必要性已为广大计算机从业人员所认可。 越来越多的软件组织建立了自己的需求管理团队，负责从项目初期的业务获取和建模，以及需求的全生命周期管理。 越来越多的资深软件开发人员也从编码工作转向需求管理和实践方法的探索。 扎实的技术基础让他们更容易掌握判断需求的能力。同样，越来越多的工程技术人员和领域专家也在不断加强自己的软件知识，以及实际业务背景和需求管理

管理方法的结合，必将提高需求建模的准确性。 在这种双向结合的前景下，相信在不久的将来，软件需求工程理论与实践相结合，将会产生更贴近实际的技术和方法，软件质量的提升就在眼前角落。