您的位置:软件测试 > 软件项目管理 > 开发管理 >
深入理解项目管理之需求
作者:网络转载 发布时间:[ 2013/6/7 15:15:59 ] 推荐标签:

随着对项目管理理解的深入,自己对项目管理的两点有了深刻理解:需求开发与管理、项目组织结构。

一、需求开发与管理

宽泛地讲,需求来源于用户的一些“需要”,这些“需要”被分析、确认后形成完整的文档,该文档详细地说明了产品“必须或应当”做什么。所以如果只有一些零碎的对话、资料或邮件,你以为自己已经掌握了需求,那是自欺欺人。需求是产品的根源,需求工作的优劣对产品影响大。像一条河流,如果源头被污染了,那么整条河流也被污染了。 我们经常看到的是:人们并不清楚究竟该做什么,但却一直忙碌不停地开发。

需求开发与管理面临普遍的问题是:用户说不清楚需求。

有些用户真的不知道需求是什么,或者对需求只有朦胧的感觉,他当然说不清楚需求。例如,早期的政府信息化项目用户通常只有一个朦胧的信息化感觉而已,需求分析中会这样写:"总之,要实现那种能够想到能做到功能。"。如果开发方的营销人员水平比较高,他能够在用户不清楚自己要什么的情况下引导用户“消费”。

有些用户虽然心里明白想要什么,但却说不清楚需求。 比如说买鞋子。我们非常了解自已的脚,但很难用语言说清楚脚的大小和形状。通常拿鞋子去试,试穿时感觉到舒服才会买鞋。一些企业的信息化项目,每个子部门对自身的需要很清楚,但不知道如何从系统角度来要求。

因此,我们可以说项目开发困难的部分也是准确说明开发什么。困难的概念性工作是编写出详细的需求,包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错,将会给系统带来极大的损害,并且以后对它修改也极为困难。为此,需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作,否则会连累整个开发团队的。

业内来看,一个成熟、成功的项目,通常它在前期需求、系统设计投入的工作量比例会大于30%。

1、需求开发 与分析

需求开发的目的是通过调查与分析,获取用户需求并定义产品需求。根据需求调查和需求分析的结果,进一步定义准确无误的产品需求,产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。 一个良好的需求说明书,应该有如下特征:

1.1 正确

需求规格说明书应当正确地反映用户的真实意图,开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的,开发方和用户必须对《需求规格说明书》进行确认。

1.2 清楚

清楚的需求让人易读易懂,包括文档的结构、段落等是否清晰。

1.3 无二义性

“无二义性” 是指每个需求只有的含义。

1.4 一致

“一致”(Consistent)是指各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。

1.5 必要

开发者应当集中精力先完成必要的需求,如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒,应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。

1.6 完备

“完备”(Complete)是指《产品需求规格说明书》中没有遗漏一些必要的需求,比如是否覆盖了所有的功能、性能、交叉、安全等需求。

1.7 可实现

《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的(Attainable)。

“可实现”意味着在技术上是可行的,并且满足时间、费用、质量等约束。

1.8 可验证

《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的(Verifiable)。如果需求是不可验证的,那么用户无法验收软件,可能会发生商业纠纷。

1.9 确定优先级

需求的优先级其实是需求“轻重缓急”的分级表述,例如划分为“高、中、低”三级。一般地,由用户和开发方共同确定需求的优先级。

1.10 阐述“做什么”而不是“怎么做”

开发人员常常身兼数职,可能把需求开发、系统设计、编程等工作从头做到尾。他们经常在整理需求的时候习惯性将如何实现的信息涵盖在需求中,导致需求可读性、可验证性无法保证。

上一页12下一页
软件测试工具 | 联系我们 | 投诉建议 | 诚聘英才 | 申请使用列表 | 网站地图
沪ICP备07036474 2003-2017 版权所有 上海泽众软件科技有限公司 Shanghai ZeZhong Software Co.,Ltd