项目管理之需求分析
项目管理之需求分析
哈尔滨华强电力自动化工程有限公司 王雪梅
黑龙江大学 李海臣
摘要：需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。
关键字：项目管理、工程、需求工程
一、 综述
软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。
软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求：业务需求说明了提供给客户和产品开发商的新系统的最初利益，反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明；用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明；功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
需求工程分为了需求开发和需求管理两个阶段：下面就以这两个阶段说明:
二、需求开发
需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤，当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤。
1． 需求获取：
1）确定需求开发过程：确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集需求活动的安排和进度计划更容易进行。
2）编写项目视图和范围文档：项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。
3）用户群分类 产品的用户在很多方面存在着差异，详细描述出它们的个性特点及任务状况，将有助于产品设计。
4）确定质量属性 确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点，这会使你的产品达到并超过客户的期望，这是一种非功能需求。听取那些描述合理特性的意见：快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。
2． 需求分析
1）分析可行性 分析需求可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
2）确定需求优先级 确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。
3）为需求建立模型 为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
4）编写数据字典 创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。
3． 编写规格说明书
项目视图和范围文档包含了业务需求，而使用实例文档则包含了用户需求。对项目而言必须编写从使用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。
1）采用软件需求规格说明模版: 采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构
2）指明需求来源：指明需求的来源为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要都能追溯每项需求的来源。
3）为每项需求注上标号：为了满足软件需求规格说明的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。为每项需求注上标号制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号。
4）记录业务规范：是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档。
5）创建需求跟踪能力矩阵：建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。
4. 需求验证
1）审查需求文档：对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查。
2）依据需求编写测试用例：根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。
3）编写用户手册：在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能。而辅助需求如质量属性、性能需求及对用户不可见的功能则在需求规格说明书中予以说明。
4） 确定合格的标准：确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用。
三、需求管理
需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。需求约定是需求开发和需求管理之间的桥梁，需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动。
1．确定需求变更控制过程，确定一个选择、分析和决策需求变更的过程。
2．建立变更控制委员会，组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。
3．进行需求变更影响分析，应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。影响分析可以提供对建议的变更的准确理解，帮助做出信息量充分的变更批准决策。
4．跟踪所有受需求变更影响的工作产品当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。
5．建立需求基准版本和需求控制版本文档确定一个需求基准。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
6．维护需求变更的历史记录记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。版本控制是管理需求的一个必要方面。需求文档的每一个版本必须被统一确定。组内每个成员必须能够得到需求的当前版本，必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。
7．跟踪每项需求的状态建立一个数据库，其中每一条记录保存一项功能需求。保存每项功能需求的重要属性，这样在任何时候都能得到每个状态类的需求数量。
8．衡量需求稳定性记录基准需求的数量和每周或每月的变更数量。过多的需求变更"是一个报警信号"，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大。
四、总结
需求工程是帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
