如何进行需求管理 - 范文无忧网

[需求分析具体要怎么写？要包括哪些内容]方法⑴首先调查组织机构情况包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。 ⑵然后调查各部门的业务活动情况 ⑶协助用户明确对新系统的各种要求包括...+阅读

展开全部

下面主要针对需求开发及需求管理两个方面对需求进行分析。

1. 需求开发，从目前我们的实际工作情况来看按顺序主要分成如下几个部分：

· 请教行业专家

行业客户对信息化的需求越来越细化，对专业性以及行业能力的全面性要求越来越高，惟有深入行业，洞察其需求，研发出更适合客户需求的产品，才能成功。因此有必要先请这方面的行业专家对于客户的业务需求进行从流程上的梳理。为什么请行业专家，而不是直接请客户进行交谈，得到其实需求，个人认为主要是因为目前各政府部门、企事业单位对于信息化与业需求的整合这一块缺少经验，大部分情况还不能完全整理出完善、清晰的系统需求来。只有通过行业专家对其实业务流程进行梳理，一方面更容易与客户产生共鸣，另一方面也可以大大减少因为知识方面的差异导致错识需求的产生。

· 和客户交谈

你要面对正确的客户区分不同层次的客户需求，要面对不同层级，不同部门的客户，把客户分类，区分需求的优先级别。如果你做的项目业务是你熟悉的，那还好，如果是你不熟悉的，一定要花点精力学习一下这个行业业务的背景资料，这也是我上面谈到的先请行业专家的原因。毕竟，客户是不可能给你系统地介绍业务的。只有你通晓了行业业务，才能和用户交流，并正确而有效地引导客户，做好需求分析，你不能指望客户能明确地说出需求。当然，这也是系统分析人员的职责所在。在开始做需求的时候，你最后花一点时间搞清楚你接触的客户是不是做实际业务的客户，如果你面对的客户不是将来的系统的实际使用者。你就有点麻烦了。可能他是客户公司派过来的IT部的人，他会提一大堆东西，而这些东西可能根本不是实际业务需要的功能，而他一般还会兴致勃勃地给你一些技术实现的建议。这个时候你就要小心了，如果你听了他的话，你可能在最后才发现，你花了大量精力解决的问题，其实并不是客户真正需要的。而你真正需要关注的，却做得远远不够。

· 参考其他类似软件和系统在经过与客户的沟通，并形成初步的需求之后，不要急成正式的需求，请先参考一下以前的一些系统，去理解一下了解到的需求与原先系统的差异，并去发现是否有些需求会产生错识需求。

· 业务建模

为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

· 需求整理并形成需求规格说明书需求规格说明书的模板我想每家公司都是不一样的，也没有必要都一样，但我认为每个需求规格说明书至少应包括

软件需求一旦通过了评审，就应该基线化，纳入配置管理库。而在配置管理库中的文档或代码不能再轻易进行修改。当有需求要进行变更的时候，就必须提出申请，写需求变更计划，审核通过，才有权限进行需求变更。然后配置管理员一定要做好需求的跟踪。，凡是跟变更需求有牵连的开发人员和测试人员都要同步的通知到和及时让他们做好相应部分的各类文档的修改。

· 需求变更管理

需求的变更管理我个人认为是最容易出问题，一般项目做不完也主要是由此产生。需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式；或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。如何有效的管理需求变更，下面是我公司目前的做法。公司采用Test Director作为需求管理工具，需求人员每次与客户沟通后形成需求调查表，统一录入Test Director，并进行综合及整理后形成需求规格说明书，之后由研发部、产品部、及销售代表（如果有客户参加就更好了）进行需求评审，建立需求基线。制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循变更控制流程进行控制，同时每一笔重要的需求变更都需要客户签字确认才认为需求变更生效。需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。