软件工程中的需求管理及注意事项

用户需求是软件项目的第一步，用户需求是否能够如实的反映用户的真实需求是关系到软件项目成败的关键，也是保证软件项目质量的关键，同时也是软件项目实施的基础。需求管理包括计划组织、用户需求调研、用户需求文档撰写、需求评审和变更管理五方面工作。

1.计划组织

开展用户需求调研工作，首先需要制订需求调研计划，明确调研的目标、方法、时间、地点和参与人员。用户需求调研不是一次就能够完成的，在调研的过程中，项目组成员应对每一次调研的成果进行总结分析，在有必要的情况下对调研计划进行修正，应当注意的是任何用户需求调研都是有时间限制的，不能够因为各种可能的突发因素而使得调研进度无法得到保证，这也就需要在调研计划当中进行预先的评估，并提出针对各种可能因素的处理预案。

在计划中另一个需要注意的问题是参与调研的人员构成，人员构成主要包括项目组成员、用户以及外部专家三个部分。不同的调研目标参与的人员是不同的，比如对项目宏观目标的调研可能就需要用户的主要管理人员和外部专家的参与，但是对于项目的某个具体工作要求，此时用户具体负责此项工作的人员参与就可以了，是否还需要其他人参加则需要考虑工作的相关性，很多时候在进行需求调研的时候会忽视工作的其他相关人员，导致需求之间不能够顺利的衔接。

在制订计划的过程中应该与用户项目负责人进行沟通，而不是在计划制订结束后简单的告知。用户需求调研的成效很大程度上取决于用户的配合程度，同时调研过程中用户的正常工作是会被干扰的，此时就需要事先进行充分的沟通和协调。用户项目负责人是沟通、协调工作的关键角色，而且通过用户项目负责人可以了解用户项目的真实需求。

2.用户需求调研

在完成调研计划后就可以开展相应的需求调研工作，具体需求调研工作有很多种方法，比如文献检索、问卷调查、实地考察、面谈等。一般情况下用户需求调研是从文献检索开始，文献检索能够为需求调研人员提供有关项目的基本理论基础。通常项目组成员并不是相关项目业务领域的专家，此时如果直接与用户进行沟通，结果就是“鸡听鸭讲”，特别是在相关业务领域当中牵涉到很多专业词汇和术语的时候，沟通是无法顺利进行的。

在具备了对项目业务领域基本的知识之后，可以开展实地考察或面谈的工作，这个时候既是了解用户的需求，同时也是项目组加深对相关业务知识的理解。直接的问卷调查在这个时候不被推荐，原因在于如果问卷采用开放式的问卷，不能够保证用户能够真正的配合，而采用客观问卷，因为对用户的需求和业务都不是较深的理解，也无法提出针对性的问题。

当项目组对用户业务和需求有了一定的了解之后，可以将重点放在与项目直接相关的需求调研之上，此时可以采用面谈和问卷调查的方式。为了避免在调查过程当中出现遗漏的情况（这种情况经常发生，每个人更关注的是自己关心的领域），在面谈过程中可以考虑采用“头脑风暴法”，头脑风暴的做法并不复杂，将所有相关人员召集在一起，不做具体主题的要求，不进行任何意见的评论，仅要求提出对于这个项目的看法。

在每次需求调研结束后，需要提出调研总结报告。调研总结报告是后续用户需求文档的基础，同时也是开展下一次调研活动的准备。一般调研总结报告包括调研目标、时间、地点、参与人员、调研过程的概述、调研结论，以及对下一步工作的建议，其中最重要的是后面两项。

3.编写用户需求文档

当整个用户调研过程结束后，应编制用户需求文档。用户需求文档是项目正式文档之一，是后续开展系统分析、设计、测试和验收工作的主要依据之一，同时也是项目组与用户之间后续工作沟通的基础。用户需求文档有时被称为用户需求说明书，也可以称为用户需求规格说明。格式可以采用相关标准格式也可以自定义格式。(www.xing528.com)

在编写用户需求文档时，应当注意文档的阅读者包括用户和项目组成员，一般用户都不是计算机领域的专家，同样项目组成员也不是用户业务领域专家，因此在使用相关术语的时候应尽量进行解释，也可以编制统一的术语表，避免用户和项目组成员在理解的时候发生偏差。此外在编写用户需求文档的时候应尽量避免出现二义性，应准确的表达用户的实际需求。

在编写用户需求文档的时候，需要注意的另外一个问题是需要对用户需求根据项目的实际情况进行甄选，也就是用户需求文档要能够反映出未来系统的设计实现，因此并不是用户提出的所有需求都需要在用户需求分析文档中出现，不出现的需求有两种情况：所提出的需求与最初的合同要求不符，比如在合同中没有提出需要手机App，但用户提出希望用手机App来实现；所提出的需求超出了现有的技术能力，同时需求可以通过其他的手段，比如人工来解决。

4.需求评审

在完成用户需求文档之后，需要提交相关的评审小组对文档进行评审。评审小组由项目组成员、用户和外部专家三部分人员构成，必要的时候企业的研发总监或技术总监应该参与。在提交用户需求文档之前，项目组应对文档内容进行初审，特别是质量管理人员需要对文档的格式、规范进行审查，应保证提交的文档是合规的。

在完成初审进行正式评审之前，应将用户需求文档发给评审小组成员，并留有足够的时间使评审小组成员能够进行充分的阅读和审核。在这个过程中也可以开始收集评审小组的意见，并进行修改，但修改过程必须在限定的时间内完成，修改结束后需要将修改结果反馈给评审小组成员。

在评审的时候，由项目经理或需求分析人员对文档进行解释说明，之后由评审小组成员提出意见，对所反映的意见如果不存在大的分歧，可以在评审会议上解决，如果存在较大的意见分歧，则需要在会后进行进一步的调研修改。通过评审后的文档根据意见修改后需要再次发给审评小组审议，是否需要再次召开评审会议取决于上次会议的结论。最终定稿的需求分析文档需要经项目组与用户双方签字确认，并进入项目配置文档库，作为之后项目开发的基线。

5.变更管理

用户需求的变化在软件项目中是不可避免的，造成需求变化的原因有很多，比如政策变化，在做一些政府项目的时候，政策变化导致需求发生变化的情况非常多，特别是在新旧政策发生交替的时候；业务流程变化，可能在项目执行过程中，企业发生内部重组或业务流程优化，这时与之相关的软件系统需要随之变化；项目认识的深化，在项目执行过程中不论是用户还是项目组成员都会随项目进展而对项目的认识逐步深化，此时会发现在最初需求分析阶段遗漏或者是错误的东西；领导变化，当项目组更换领导或用户更换领导，可能会出现新任领导与原任领导对项目需求不一致的情况；系统测试或试运行，在系统测试或试运行阶段是可以发现业务流程当中不合理的地方，有些时候软件完全模拟手工操作流程并不是非常合理的。

当需求发生变化的时候，并不代表项目组要完全按照变化的需求来进行修改，其原因在于在项目进展过程中，如果随时因为需求变化而对软件进行修改，那么项目将变的不可控制，其质量也无法获得保证。对于所有的需求变化，项目组都需要在进行评估之后决定是否进行修改。评估的过程包括：对所提出的需求变更进行核实，所有的变更都应该是书面提出的，口头提出的要求应该被忽略；经过核实的需求，项目组需要对变更需求所造成的影响进行评估，如果是在合理范围内（比如对某个流程的优化）同时对进度的影响不大，项目组可以直接采纳变更，并修改项目基线；如果在合理范围内但对项目进度的影响较大，此时项目组就需要提请评审小组，由评审小组做出相关决定；如果认为不在合理范围内，项目组可以通过协商拒绝也可以提交评审小组决议。在需求变更中最严重的情况发现变更是必须的，而且对项目整体设计的影响是推倒性的，此时必须通过双方高层的协商决定是否停止项目。

所有采纳的变更都应进入项目配置管理，并修改项目基线，同时需要修订项目进度计划、设计方案、测试方案等与项目相关的所有文档。