如何做好需求统筹Word文件下载.docx

如何做好需求统筹Word文件下载.docx

《如何做好需求统筹Word文件下载.docx》由会员分享，可在线阅读，更多相关《如何做好需求统筹Word文件下载.docx（5页珍藏版）》请在冰豆网上搜索。

现在的软件项目中返工开销几乎占了总开发的一半，而导致返工的主要原因是需求分析不明确。

从而引发项目开发中的一系列更改。

这些更改可能导致浪费大量的资源、软件项目无法按时完成等严重问题。

二、明确项目干系人

从项目的启动开始，项目管理团队就要识别项目客户方干系人包含哪些人和组织，通过沟通协调确定他们的需求和期望，尽最大可能地明确项目干系人中的决策者在项目中所起到的作用，以确保项目获得成功。

很多项目往往都是由客户单位的信息科技部门主导，项目经理在前期接触时，跟这些信息科技部门接触的比较多，而没有和业务部门或系统开发完成后的实际的使用者接触。

这类人员对技术比较精通，但对应用部门的相关业务可能不是特别熟悉，从而导致项目组获取到的需求发生偏差，在软件开发完成后和用户的实际需求相差甚远，导致用户频繁提出需求更改，更有甚者推翻重建。

因此，项目经理在与客户初次接触时应首先明确干系人，识别项目干系人及其角色，确定项目组的组织架构，确定项目组各干系人的职责范围，确定对需求实现的最终决策者。

三、合理获取需求

对需求的了解分为四种情况：

开发方和用户方都清楚项目需求；

开发方不清楚项目需求但用户方清楚；

开发方和用户方都不清楚项目需求；

开发方清楚项目需求但用户方不清楚。

针对这四种情况，需求调研人员可以采用访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、界面原型法、标杆对照、系统交互图、文件分析等方法来获取客户的需求。

可以对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。

用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。

因此需求调研分析人员应善于想用户所想，不但要确定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的需求。

这就要求需求调研分析员要尽快完整地熟悉相关业务，从而能够站在用户的立场看待软件需求，这样才能设计出真正符合客户需求的系统。

四、分析需求的可行性

在需求获取过程中，项目组收集的需求往往存在以下几问题：

（1）需求范围超出合同范围；

（2）对同一功能，各干系人提出的需求不一致；

（3）存在明显不合理的需求；

（4）对需求理解发生偏差。

因此对获取到的需求进行有效、准确的分析是必不可少的步骤。

在项目建设过程中，不同的项目用户方干系人其愿望和追求的目标可能会存在不一致，有些干系人的期望值较高，远超合同建设范围；

而有些干系人提交的需求，相互之间不一致，造成需求冲突。

因此需求分析人员应对获取到的需求进行整理并进行有效分析。

对于超出合同范围的需求，可由商务一起协调进行增补或在二期中进行建设；

对于需求不一致的，可召开项目协调会，由甲方最终决策者拍板确定或寻求平衡点折衷处理；

对于需求理解偏差和客户描述不清的需求，可通过原型界面法，反复确认。

因为对于需求分析是需求管理中很重要的一个工作部分。

对获取到的需求，进行优先级评估。

需求分析人员应分清客户提出的需求，哪些特性是必要的，哪些是重要的，是需求开发的主要部分，设定这些需求的优先级，并与客户进行讨论明确。

因为开发者应该按照客户的观点决定项目需求的优先级；

开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。

在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。

尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

在需求分析过程中，应尽量使用已有的软件组件来实现，以节省资源。

需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。

所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

很多时候，用户的想法在实际实施过程中是不现实的。

若一味地求全和盲目遵从用户的设想，将为项目的后续工作带来很大的风险。

因此应尽量避免在需求分析中包含技术实施上有难度的功能。

五、撰写清晰的需求文档

在准确领会客户的意图后，软件需求规格说明书就是需求分析阶段需要产生的最主要的文档。

准确而详细地编写一份清晰、准确的需求文档是很困难的。

因此很容易留下模糊不清的需求，但是在开发过程中，必须解决这种模糊性和不准确性，在编写文档时，开发人员严禁采用“猜测”的方式编写。

在需求文档中暂时加上“待定”标志是个好方法。

用该标志可指明哪些是需要再进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。

客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。

如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

需求规格说明书的每个功能点的描述要通俗易懂，能够使客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。

所以分析说明书对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户对同一个问题有两个截然不同的理解。

需求规格说明书一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，一个模块一个功能的逐一的审核，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题。

需求文档完成之后，并不是把它扔给后面的设计人员就了事了。

作为项目组其他成员，对需求的有效性也起到某种程度的验证作用。

虽然软件项目的生命周期按照各种开发模型有不同阶段的划分，但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。

特别是高科技的软件开发项目，上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检验，通过检验有时也有必要对上一阶段的工作结果进行相应的调整，需求分析也是如此。

因此，无论是同一阶段不同人员之间，或是不同阶段人员之间都应根据需要相互协作，相互配合，共同完成软件开发任务。

六、做好项目需求变更管理

在软件项目建设过程中，需求变更是不可避免的，但在开发生命周期中，变更越在晚期出现，其影响越大；

变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。

所以，一旦客户发现需要变更需求时，请立即通知分析人员。

分析人员及时评估，为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。

在不放弃所提出的需求变更情况下，对每项要求的变更进行分析、综合考虑，最后做出合适的决策。

需求发生了变化，随之而来的将是不得不修改设计、重写代码、修改测试用例、调整项目计划等问题，对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，这将为项目的正常进展带来诸多的麻烦，开发小组也要为此付出较重的代价。

当然在软件项目建设过程中，并不是所有的需求变更都能够被采纳，要学会适当的拒绝，通过变通的方法实现。

否则这个项目不能按时完成，进度无限期滞后。

因此在需求变更过程中最难办的事情就是拒绝客户提出的需求变更请求，通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。

因此作为一名项目经理，你应当规范需求管理，对客户的需求变更进行评估分析，对变更带来的影响、成本和得失告知客户。

七、用好企业级需求管理工具

VisualRM是维普时代基于多年需求管理项目实践，参照CMMI、PMBOK5、COBIT标准，打造的一款企业级的需求内容管理产品，以需求内容（条目）的实现过程为主线，实现企业级需求过程的一体化管理。

VisualRM帮助客户构建企业级需求管控过程，快速形成高质量需求，快速获取最新最可信需求、快速沉淀并盘活需求资产。