|
宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。需求是产品的根源，需求工作的优劣对产品影响最大。我们经常看到的是：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。training.mypm.net
需求调研中面临最普遍的问题是：用户说不清楚需求项目管理论坛
有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，例如，早期的政府信息化项目用户通常只有一个朦胧的信息化感觉而已，需求分析中会这样写："总之，要实现那种能够想到就能做到功能!"。如果需求调研人员的水平比较高，他就能够在用户不清楚自己要什么的情况下引导用户“消费”。项目管理者联盟
有些用户虽然心里明白想要什么，但却说不清楚需求。 比如说买鞋子。我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋。一些企业的信息化项目，每个子部门对自身的需要很清楚，但不知道如何从系统角度来要求。pmp.mypm.net
需求分析的结果——需求分析说明书项目管理论坛
需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。一个良好的需求说明书，应该有如下特征：项目管理者联盟
1 正确并且清楚training.mypm.net
需求规格说明书应当正确地反映用户的真实意图，开发者和用户自己都要明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。清楚的需求让人易读易懂，包括文档的结构、段落等是否清晰。club.mypm.net
2 一致并且无二义性blog.mypm.net
“无二义性” 是指每个需求只有唯一的含义。“一致”是指各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。blog.mypm.net
3 必要并且完备项目管理者联盟
开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。“完备”是指《产品需求说明书》中没有遗漏一些必要的需求，比如是否覆盖了所有的功能、性能、交叉、安全等需求。项目管理者联盟
需求变更——让我们热烈欢迎它吧bbs.mypm.net
需求变更通常会对项目的进度、人力资源、经费产生很大的影响。如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，会导致产品的部分内容需要重新开发。这是要坚决避免的。项目管理者联盟
如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。项目管理者联盟
其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。项目经理博客
需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题的一个办法是事先建立规则：如开发方与客户方达成“事不过三”的约定，即允许客户变更三次需求;如果客户第四此变更需求，开发方有权提请客户补偿开发投入。项目管理者联盟
需求变化是开发人员最讨厌的一件事了。可是，就像我们常说"哭不能解决问题"一样，讨厌能解决问题吗?拒绝客户的变更要求，要求客户在需求规格说明书上签字。这些做法只能是适得其反。没有任何正面的、积极的意义。需求变更要求我们的开发工作要迭代式进行，包括需求、设计、实现等阶段。这样才能将变更风险减到最小。www.mypm.net 项目管理者联盟
|
