软件项目的需求开发和管理

摘要需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。

如何从各种各样的应用专业领域中特别是直接从最终用户处捕获需求，并完整、准确地予以描述与分析，需求工程成为研究的热点之一。

本文通过对需求工程的基本概念、需求开发和管理中的主要风险和对策进行研究和总结，希望在实践中加以应用，真正做好需求的开发和管理工作。

关键字：软件项目、需求工程、需求分析、需求开发、需求管理、X围管理、X围变更控制目录1软件需求和需求工程3 1.1软件需求的基本概念31.2软件需求的重要性31.3需求工程的基本概念41.4需求开发过程域41.5需求管理过程域51.6需求工程的一些感悟52需求开发和管理的主要风险63需求开发和管理的主要对策6 3.1建立需求开发和管理工作机制需考虑的几个因素7 3.2需求开发和管理流程73.2.1需求调查73.2.2细化用户需求83.2.3撰写需求说明书83.2.4需求确认93.2.5需求跟踪103.2.6需求变更控制104总结13软件项目的需求开发和管理1软件需求和需求工程1.1 软件需求的基本概念在IEEE软件工程标准词汇表(1997年)中定义软件需求为：1)用户解决问题或达到目标所需的条件或能力。

2)系统或系统部件要满足合同、标准、规X或其它正式规定文档所需具有的条件或能力。

3)一种反映上面1)或2)所描述的条件或权能的文档说明。

实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。

所以我们可以理解，软件需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。

1.2 软件需求的重要性软件需求是整个产品链的源头，需求工作的优劣将直接影响到产品的设计，生产，销售和维护的全过程。

就像一条河流，如果源头被污染了，那么整条河流也就被污染了。

Frederick Brooks在他的经典文章“No Silver Bullet”是这样描述需求的重要性的：开发软件系统最困难的部分就是准确说明开发什么。

最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。

此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。

1.3 需求工程的基本概念1)把所有与需求直接相关的活动通称为需求工程。

2)需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。

3)需求工程的结构图图1：需求工程结构图1.4 需求开发过程域1)需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。

2)需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。

3)需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。

常见的需求分析方法有“问答分析法”和“建模分析法”两类。

4)需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。

系统设计人员将依据《产品需求规格说明书》开展系统设计工作。

1.5 需求管理过程域1)需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。

2)需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。

3)需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。

4)需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

1.6 需求工程的一些感悟1)不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。

2)开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。

a)“被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。

他们认为需求是用户的事情而不是自己的事情。

开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。

b)“主动型”是指开发者积极地开展需求工程中的各项活动。

他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。

俗话说“良好的开端是成功的一半”，“主动型”需求工程是开发成功产品的必备条件。

c)“领先型”是需求工程的最高境界。

开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。

需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。

2需求开发和管理的主要风险由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主观性和可描述性差的特点，因此，需求分析工作往往面临着一些潜在的风险。

这些风险主要表现在：1)用户不能正确表达自身的需求。

这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求。

2)业务人员配合力度不够。

有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用。

3)用户需求的不断变更。

由于需求识别不全、业务发生变化、需求本身错误、需求不清楚或对应政策法规发生了变化等原因，需求在项目的整个生命周期都可能发生变化，一旦发生了需求变化，就不得不修改设计、重写代码、修改测试用例、调整项目计划等等，需求的变化就像是万恶之源，为项目的正常的进展带来不尽的麻烦。

4)忽略了用户的特点分析。

分析人员往往容易忽略了系统用户的特点，系统是由不同的人使用其不同的特性，使用频繁程度有所差异，使用者受教育程度和经验水平不尽相同。

如果忽略这些的话，将会导致有的用户对产品感到失望。

3需求开发和管理的主要对策首先需要建立一个有效的工作机制，只有建立了工作机制，才能保证需求工作按照既定方案执行，需求开发和管理的参与者才会在一种有序的状态下工作。

其次才是充分运用工作机制和个人能力去获取问题、分析问题、编写需求文档和进行需求管理。

3.1 建立需求开发和管理工作机制需考虑的几个因素1)抓住决策者最迫切和最关心的问题，引起重视。

用户方决策者对项目的关心重视程度是项目能否顺利开展的关键，决策者的真实意图也是用户方的最终需求，因此，在开发过程中要利用一切机会了解决策者关心的问题，同时也要引导他们了解和重视项目的开发，当决策者认识到项目的重要性时，需求分析工作在人力、物力、时间上就有了保障。

2)建立良好的沟通环境和氛围。

分析人员与用户沟通的程度关系到需求分析的质量，因此建立一个良好的沟通氛围、处理好分析人员与用户之间的关系显得尤其重要。

3)需求质量控制要制度化。

需求的变化是软件项目不可避免的事实，因此需求质量控制是一项艰苦的工作，要保证该项工作的顺利实施，就必须有制度保证，这个制度可以在项目质量控制方案中制定，该方案主要是具体化、定量化的描述用户要求，形成全面、一致、规X的软件需求分析规格说明书，明确需求分析规格说明书的工作程序和要素，规X开发活动，为后续软件设计、实现、测试、评审及验收提供依据。

3.2 需求开发和管理流程3.2.1需求调查1)首先，需求分析员起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。

问题表可以是层次化的，随着调查的深入，问题表将不断地被细化。

问题表应当以“选择题”和“是非题”为主。

2)其次，需求分析员应当确定需求调查的方式。

例如：与用户交谈，向用户提问题，向用户群体发调查问卷等，还可以从用户的工作流程，相关文档以及行业标准、规则中提取需求。

分析已经存在的同类软件产品，提取需求。

3)最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，进行需求调查。

3.2.2细化用户需求根据用户需求调查，对用户的需求进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。

例如采用Rational 的Rose工具进行需求的建模分析。

3.2.3撰写需求说明书需求分析员按照指定的文档模板撰写《需求说明书》。

《需求说明书》的参考模板如下：图2：《需求说明书》参考模板3.2.4需求确认需求确认是指开发方和客户方共同对《需求说明书》进行评审，双方对需求达成共识后作出承诺。

需求确认包括两方面的工作：“需求评审”和“需求承诺”。

1)需求评审：对需求的必要性和可行性进行分析，确定需求文档。

2)需求承诺：开发方和客户方的对通过了正式技术评审的《需求说明书》做出承诺，按照“变更控制规程”执行，明确指出需求的变更将导致双方重新协商成本、资源和进度等。

3.2.5需求跟踪需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。

需求跟踪有两种方式：1)正向跟踪：检查《需求说明书》中的每个需求是否都能在后继工作成果中找到对应点。

2)逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《需求说明书》中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。

不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。

需求跟踪矩阵保存了需求与后继工作成果的对应关系。

3.2.6需求变更控制3.2.6.1 需求变更的原因在软件项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。

虽然需求变更的表现形式千差万别，但究其根本不外乎以下几种原因：1)X围没有圈定就开始细化。

细化工作是由需求分析人员完成的，一般是根据用户提出的描述性的、总结性的短短几句话去细化的，提取其中的一个个功能，并给出描述（正常执行时的描述和意外发生时的描述）。

当细化到一定程度后并开始系统设计时，X围会发生变化，那细节用例的描述可能就有很多要改动。

2)没有指定需求的基线。

3)没有良好的软件结构适应变化。

3.2.6.2 如何控制需求变更为了将项目变更的影响降低到最小，就需要采用项目X围变更控制方法。

进行项目X围变更控制的主要依据是X围管理计划、变更请求和提供了项目执行状况信息的绩效报告。

按照现代项目管理的概念，一个项目的生命周期分为启动、计划、执行、监控、收尾五个过程组。

X围变更的控制不应该只是项目实施过程考虑的事情，而是要分布在整个项目生命周期的全过程。

1)项目启动、计划阶段的变更预防。

对于任何项目，变更都无可避免，也无从逃避，只能积极应对，这个应对应该是从项目启动的需求分析阶段就开始了。