软件项目需求管理课件

第4章软件项目需求管理

第4章软件项目需求管理本章目录4.1软件需求概述4.2需求管理方法与内容4.3软件项目的任务分解4.4软件需求的变更控制4.5案例与讨论本章目录4.1软件需求概述4.1软件需求概述 4.1.1软件需求的层次划分 14.1.2用户需求与特点分析2

4.1.3系统需求与类型划分 3

4.1.4软件需求规格说明书 5544.1软件需求概述 4.1.1软件需求的层次划分 14.1.4.1.1软件需求的层次划分软件需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么样的性能。软件人员要准确理解用户的要求，进行细致的调查分析，将用户的需求陈述转化为完整的需求定义，再由需求定义转化为需求规格说明。软件需求可以按照层次进行划分，其内容包括业务需求、用户需求、功能需求、软件需求规格等层次。

4.1.1软件需求的层次划分软件需求是指用户对软件的功能和4.1.2用户需求与特点分析（1）用户需求直接来源于用户。

（2）用户需求需要以文档的形式提供给用户审查。

（3）可以把用户需求理解为用户对软件的合理请求。

（4）用户需求主要是为用户方的管理层撰写的，但是用户方的技术代表、软件系统今后的操作者及开发方的高层技术人员，也有必要认真阅读用户需求文档。

4.1.2用户需求与特点分析（1）用户需求直接来源于用户。4.1.3系统需求与类型划分系统需求是比用户需求更具有技术特性的需求陈述。它是提供给开发者或用户方技术人员阅读的，并将作为软件开发人员设计系统的起点与基本依据。系统需求包括多个方面，可以从不同角度进行类型划分。而从项目开发角度看，软件需求主要包括两大类型：功能需求、非功能需求。

4.1.3系统需求与类型划分系统需求是比用户需求更具有技术4.1.4软件需求规格说明书1．需求规格说明书的重要性软件需求规格说明书详细地说明了软件产品“必须做什么”，以及对模糊的部分“不做什么”，还包括软件应该“做成什么样”等。需求规格说明书在后面的开发、测试、质量保证，以及相关项目管理功能中都将起到重要的作用。

2．需求规格说明书的结构框架

3．需求规格说明书的编写要求（1）条理清晰。

（2）结构完整。

（3）内容一致。

（4）可测试性。

4.1.4软件需求规格说明书1．需求规格说明书的重要性4.2需求管理方法与内容 4.2.1需求管理的含义14.2.2需求管理的复杂性2

4.2.3需求管理的方法34.2.4需求管理的过程44.2需求管理方法与内容 4.2.1需求管理的含义14.2.4.2.1需求管理的含义需求管理就是一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。

4.2.1需求管理的含义需求管理就是一种获取、组织并记录系4.2.2需求管理的复杂性软件的需求管理的复杂性主要体现在以下几个方面。

(1)需求的描述问题。(2)需求的完备程度问题。(3)需求开发的工期问题。(4)需求的细致程度问题。(5)需求的变化问题。4.2.2需求管理的复杂性软件的需求管理的复杂性主要体现在4.2.3需求管理的方法

在需求管理中，可以采用的方法主要包括以下一些方面。

（1）确定需求变更控制过程。（2）进行需求变更影响分析。（3）建立需求基准版本和需求控制版本文档。（4）维护需求变更的历史记录。（5）跟踪需求的状态。（6）衡量需求的稳定性。4.2.3需求管理的方法在需求管理中，可以采用的方法主要4.2.4需求管理的过程需求管理的过程从需求获取开始，一直贯穿于整个项目生命周期，其目的是力图实现最终产品同用户需求的最佳结合。在整个需求管理过程中，主要包括了以下内容。1．需求获取2．需求确认

3．建立需求状态

4．需求验证

5．需求承诺

6．需求跟踪

7．需求变更控制

4.2.4需求管理的过程需求管理的过程从需求获取开始，一4.3软件项目的任务分解 4.3.1工作分解结构14.3.2工作分解的操作步骤2

4.3.3工作分解结构的表示形式3

4.3.4任务分解的注意事项 44.3软件项目的任务分解 4.3.1工作分解结构14.3.24.3.1工作分解结构在进行需求分析时，当要解决的问题过于复杂时，可以将问题进行分解，直到分解后的子问题容易解决，然后分别解决这些子问题。定义任务或活动的方法可以通过建立工作分解结构(WBS)的技术来实现。

4.3.1工作分解结构在进行需求分析时，当要解决的问题过于4.3.2工作分解的操作步骤一般来讲，任务分解的主要步骤如下。（1）确认并分解项目的主要组成要素。

（2）确定分解标准，按照项目实施管理的方法分解。（3）确认分解是否详细，明确责任。

（4）确定项目交付成果。（5）验证分解的正确性。

（6）建立一套编号系统，以便区别各个工作。

4.3.2工作分解的操作步骤一般来讲，任务分解的主要步骤如4.3.3工作分解结构的表示形式进行任务分解时，可以采用图表、清单等不同的形式，来表示任务分解的最后结果。1．图表形式

2．清单形式3．类比方法

4.3.3工作分解结构的表示形式进行任务分解时，可以采用图4.3.4任务分解的注意事项对于规模较大的软件项目而言，在进行工作分解的时候，要注意以下几点内容。（1）应注意收集与项目相关的所有信息。（2）对于项目最底层的工作要非常具体，而且要完整无缺地分配给项目内外的不同个人或者是组织。（3）对于最底层的工作包，一般要有全面、详细和明确的文字说明。（4）任务分解的规模和数量因项目而异，先分解大块的任务，然后再细分小的任务。（5）WBS中所有的分支并非都必须分解到同一水平，各分支的组织原则可能会不同。（6）在WBS完成之后，在其基础上就可以对每个工作包所投入的资源、人力进行分解和估算。

4.3.4任务分解的注意事项对于规模较大的软件项目而言，在4.4软件需求的变更控制 4.4.1不可避免的需求变更14.4.2需求变更的原因分析2

4.4.3管理需求变更的请求34.4.4需求变更的控制流程44.4软件需求的变更控制 4.4.1不可避免的需求变更14.4.4.1不可避免的需求变更在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项到研发和维护。需求的变更可以发生在任何的阶段。需求变更可能来自开发方、客户或产品供应商等，也可能来源于项目组内部。软件开发人员必须接受“需求会变动”这个事实。在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软件的核心建筑在稳定的需求上，同时要留出变更空间。

4.4.1不可避免的需求变更在软件项目的开发过程中，需求变4.4.2需求变更的原因分析1．范围没有圈定就开始细化

2．没有良好的软件结构适应变化

3．用户改变需求

4.4.2需求变更的原因分析1．范围没有圈定就开始细化4.4.3管理需求变更的请求应仔细评估已建议的变更；挑选合适的人选对变更做出决定；变更应及时通知所有涉及的人员；要按一定的程序来采纳需求变更等。

1．控制需求渐变的策略

2．项目周期内的变更控制

4.4.3管理需求变更的请求应仔细评估已建议的变更；挑选合4.4.4需求变更的控制流程下是一个需求变更控制流程的示例。

4.4.4需求变更的控制流程下是一个需求变更控制流程的示例4.5案例与讨论案例4-1讨论题1．本例中，W公司CRM软件系统建设遇到了什么困境？产生的主要原因是什么？2．从文中叙述分析：W公司市场部门最初提出的用户需求，是想实施一个什么类型的CRM系统？而IT部门为其推荐的是何种类型的CRM系统？IT部门为什么这么做？3．如果你是本例中的李高翔，你下一步将会怎么做？4.5案例与讨论案例4-1讨论题4.5案例与讨论案例4-2讨论题1. 为什么会出现用户需求变更？这个问题能够避免吗？2. 如果你的项目遇到需求变更问题，你会采用哪种方式去应对？3. 分析本案例中两种应对需求变更方式的各自优缺点。你倾向于哪种方法？4.5案例与讨论案例4-2讨论题第4章软件项目需求管理

第4章软件项目需求管理本章目录4.1软件需求概述4.2需求管理方法与内容4.3软件项目的任务分解4.4软件需求的变更控制4.5案例与讨论本章目录4.1软件需求概述4.1软件需求概述 4.1.1软件需求的层次划分 14.1.2用户需求与特点分析2

4.1.3系统需求与类型划分 3

4.1.4软件需求规格说明书 5544.1软件需求概述 4.1.1软件需求的层次划分 14.1.4.1.1软件需求的层次划分软件需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么样的性能。软件人员要准确理解用户的要求，进行细致的调查分析，将用户的需求陈述转化为完整的需求定义，再由需求定义转化为需求规格说明。软件需求可以按照层次进行划分，其内容包括业务需求、用户需求、功能需求、软件需求规格等层次。

4.1.1软件需求的层次划分软件需求是指用户对软件的功能和4.1.2用户需求与特点分析（1）用户需求直接来源于用户。

（2）用户需求需要以文档的形式提供给用户审查。

（3）可以把用户需求理解为用户对软件的合理请求。

（4）用户需求主要是为用户方的管理层撰写的，但是用户方的技术代表、软件系统今后的操作者及开发方的高层技术人员，也有必要认真阅读用户需求文档。

4.1.2用户需求与特点分析（1）用户需求直接来源于用户。4.1.3系统需求与类型划分系统需求是比用户需求更具有技术特性的需求陈述。它是提供给开发者或用户方技术人员阅读的，并将作为软件开发人员设计系统的起点与基本依据。系统需求包括多个方面，可以从不同角度进行类型划分。而从项目开发角度看，软件需求主要包括两大类型：功能需求、非功能需求。

4.1.3系统需求与类型划分系统需求是比用户需求更具有技术4.1.4软件需求规格说明书1．需求规格说明书的重要性软件需求规格说明书详细地说明了软件产品“必须做什么”，以及对模糊的部分“不做什么”，还包括软件应该“做成什么样”等。需求规格说明书在后面的开发、测试、质量保证，以及相关项目管理功能中都将起到重要的作用。

2．需求规格说明书的结构框架

3．需求规格说明书的编写要求（1）条理清晰。

（2）结构完整。

（3）内容一致。

（4）可测试性。

4.1.4软件需求规格说明书1．需求规格说明书的重要性4.2需求管理方法与内容 4.2.1需求管理的含义14.2.2需求管理的复杂性2

4.2.3需求管理的方法34.2.4需求管理的过程44.2需求管理方法与内容 4.2.1需求管理的含义14.2.4.2.1需求管理的含义需求管理就是一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。

4.2.1需求管理的含义需求管理就是一种获取、组织并记录系4.2.2需求管理的复杂性软件的需求管理的复杂性主要体现在以下几个方面。

(1)需求的描述问题。(2)需求的完备程度问题。(3)需求开发的工期问题。(4)需求的细致程度问题。(5)需求的变化问题。4.2.2需求管理的复杂性软件的需求管理的复杂性主要体现在4.2.3需求管理的方法

在需求管理中，可以采用的方法主要包括以下一些方面。

（1）确定需求变更控制过程。（2）进行需求变更影响分析。（3）建立需求基准版本和需求控制版本文档。（4）维护需求变更的历史记录。（5）跟踪需求的状态。（6）衡量需求的稳定性。4.2.3需求管理的方法在需求管理中，可以采用的方法主要4.2.4需求管理的过程需求管理的过程从需求获取开始，一直贯穿于整个项目生命周期，其目的是力图实现最终产品同用户需求的最佳结合。在整个需求管理过程中，主要包括了以下内容。1．需求获取2．需求确认

3．建立需求状态

4．需求验证

5．需求承诺

6．需求跟踪

7．需求变更控制

4.2.4需求管理的过程需求管理的过程从需求获取开始，一4.3软件项目的任务分解 4.3.1工作分解结构14.3.2工作分解的操作步骤2

4.3.3工作分解结构的表示形式3

4.3.4任务分解的注意事项 44.3软件项目的任务分解 4.3.1工作分解结构14.3.24.3.1工作分解结构在进行需求分析时，当要解决的问题过于复杂时，可以将问题进行分解，直到分解后的子问题容易解决，然后分别解决这些子问题。定义任务或活动的方法可以通过建立工作分解结构(WBS)的技术来实现。

4.3.1工作分解结构在进行需求分析时，当要解决的问题过于4.3.2工作分解的操作步骤一般来讲，任务分解的主要步骤如下。（1）确认并分解项目的主要组成要素。

（2）确定分解标准，按照项目实施管理的方法分解。（3）确认分解是否详细，明确责任。

（4）确定项目交付成果。（5）验证分解的正确性。

（6）建立一套编号系统，以便区别各个工作。

4.3.2工作分解的操作步骤一般来讲，任务分解的主要步骤如4.3.3工作分解结构的表示形式进行任务分解时，可以采用图表、清单等不同的形式，来表示任务分解的最后结果。1．图表形式

2．清单形式3．类比方法

4.3.3工作分解结构的表示形式进行任务分解时，可以采用图4.3.4任务分解的注意事项对于规模较大的软件项目而言，在进行工作分解的时候，要注意以下几点内容。（1）应注意收集与项目相关的所有信息。（2）对于项目最底层的工作要非常具体，而且要完整无缺地分配给项目内外的不同个人或者是组织。（3）对于最底层的工作包，一般要有全面、详细和明确的文字说明。（4）任务分解的规模和数量因项目而异，先分解大块的任务，然后再细分小的任务。（5）WBS中所有的分支并非都必须分解到同一水平，各分支的组织原则可能会不同。（6）在WBS完成之后，在其基础上就可以对每个工作包所投入的资源、人力进行分解和估算。

4.3.4任务分解的注意事项对于规模较大的软件项目而言，在4.4软件需求的变更控制 4.4.1不可避免的需求变更14.4.2需求变更的原因分析2

4.4.3管理需求变更的请求34.4.4需求变更的控制流程44.4软件需求的变更控制 4.4.1不可避免的需求变更14.4.4.1不可避免的需求变更在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项到研发和维护。需求的变更可以发生在任何的阶段。需求变更可能来自开发方、客户或产品供应商等，也可能来源于项目组内部。软件开发人员必须接受“需求会变动”这个事实。在进行需求分析