摘要：需求开发是软件项目开发过程中十分重要的工作，也是项目最终能够取得成功的基础。本文参考其他的同行，总结了笔者这几年软件开发过程中所遇到的问题，针对问题提出相应的对策。项目管理者联盟
项目管理者联盟
关键词:需求获取 需求开发 需求分析项目管理者联盟
引言项目管理者联盟
项目管理者联盟
无论是ERP项目还是小型的软件开发领域，包含需求、设计、编码和测试四个阶段，其中需求是整个软件开发的最关键的一个输入，据统计，不成功的项目中有30~40%的问题是由需求造成的。大量的研究表明需求阶段发现和纠正错误的代价是软件开发各阶段中成本最低的，越是后期的变更，成本越高，良好的需求开发对提高软件成功率和避免失败具有重要的意义。项目管理者联盟
blog.mypm.net
如何正确地获取用户的需求，围绕其进行管理，以便最终交付给用户符合其期望的产品是需求工程的任务。需求工程的研究产生了如CMM（能力成熟度模型）、UML（统一建模语言）、RUP（Rational统一建模过程）、CASE（用例）等管理方法和开发工具，软件思想家温伯格（Gerald M.Weinberg ）先生指出“CMM只是一种标准，UML也只是一种记录需求的工具，而不是捕获需求的方法，需求的管理主要还是靠经验”。准确而有效获取用户需求、精确表述用户需求并得到用户认可，是软件项目开发成功的最重要的里程碑之一。本文针对需求开发中存在的风险进行探讨总结，整理出其预防措施，期望以后对软件项目的需求分析进行风险预防、控制等提供参考。项目管理者联盟
项目管理者联盟
一、什么是需求?项目管理者联盟
training.mypm.net
1997年IEEE软件工程标准词汇表对软件需求的定义为：用户解决问题或达到目标所需的条件或能力。系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。用通俗地说，“需求”就是用户的需要，包括用户要解决的问题、达到的目标，以及实现这些目标所需要的条件，表现形式一般为文档形式。需求分为需求开发和需求管理，而需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。如图1所示，整个活动构成软件开发生命周期的需求分析阶段。如何帮助用户提出准确的需求、理解和分析用户环境是需求获取的过程。为问题涉及的信息、功能及行为建立模型并将用户需求精确化、完全化是需求分析的过程，最终形成需求规格说明书是编写规格说明书的过程，将需求说明书交付用户并得到用户认可是需求验证的过程。需求获取、分析、编写需求规格说明和需求验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的进行。
二、需求开发四步骤项目管理者联盟
项目管理培训
1、需求获取club.mypm.net
项目管理者联盟
针对大项目如企业ERP的需求获取，采取的办法(1)、成立需求分析小组，划分任务，细化侧重点，为获取用户需求做好准备工作。(2)、访谈用户获取问题，了解用户的功能需求同时，还需要注意用户的非功能需求(如：用户界面、响应时间、自动恢复时间等)。访谈用户前，首先要了解和划分用户的类型，针对用户的情况可以划分组别，详细描述出他们的个性特点及任务情况。其次，就要选择好每类的代表，对其进行访谈和调研，每类用户代表都能对其负责的方面有代表性并能做出决策，2005年我单位准备上ERP系统，当时北京某软件单位到我司作调研的时候，下属单位都是选择行政“一把手”参与调研。每次的交流都需要有记录，对于交流的结果还可以分类，以便于后续的分析活动开展。PgMp.mypm.net
项目管理者联盟
2、需求分析club.mypm.net
项目管理者联盟
调研人员对于收集的需求信息要做进一步的分析和整理，判断哪些是软件必须提供的，哪些是软件目前无法满足的，哪些用户需求会衍生出很多的隐性需求，还有哪些是用户没有想到的需求。这是一个需求分析人员消化用户资料的过程。
项目管理者联盟
这个过程主要通过建立模型来描述用户的需求，实际上是抽象图形化的过程。一般用图形表示系统的整体结构、用原型等方式向用户提供可视化的界面、用系统可性行分析来说明软件的效果和效率、用UML描述系统的需求及内部关系。项目管理者联盟
项目管理者联盟
3、编写需求规格说明书项目管理者联盟
项目管理者联盟
需求规格说明书也称为功能规格说明、需求协议或系统规格说明，它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。它是开发设计的蓝本，也是系统测试和用户文档的依据。PgMp.mypm.net
项目管理者联盟
4、需求验证training.mypm.net
PgMp.mypm.net
需求验证是为了确保需求说明书准确无误、完整地表达必要的质量的一种方式。客户、分析人员、设计人员、测试人员等利益相关人员经过多次的评审后的需求说明书就可作为需求管理的基线。用户和开发方对软件项目内容的描述是以需求规格说明书作为基础，它是软件验收时合同双方确认的重要依据。转自项目管理者联盟
talent.mypm.net
三、需求开发中存在的困难以及对策项目管理者联盟
项目管理者联盟
在软件项目开发过程中，风险无所不在，如何有效规避风险，尤其是需求开发过程中的风险（需求风险）。本文按着需求开发的过程提供几条建议：转自项目管理者联盟
项目管理者联盟文章
1、需求获取项目管理者联盟
项目管理者联盟
问题一：用户对于自己的需求不太清楚或工作繁忙无暇理清需求。在很多的实际开发过程中，第一种情况就是用户对自己真正的需求并不十分明确，他们认为计算机是万能的，只要简单地说一说自己想要得到什么样的结果就行了。对于自己的业务规则、工作流程都不愿说谈。笔者在2006年曾准备开发一个医院的库房管理系统，当本人开始做需求调查的时候，就是存在用户无法准确有效地表述功能需求的问题。针对这种情况，其对策是：需求分析人员一定要深入用户工作场地，仔细查看用户的资料和报表，与不同层面的用户交流、沟通，且要多了解用户实际工作的场景，有条件的话，可以做一个“实习生”亲身体验用户的日常工作。站在用户的角度帮助用户分析需求。关注用户工作的每个细节，搞清用户的真实需求，以最大可能减少后期地需求变更。第二种情况就是业务人员配合力度不够。有的用户日常工作繁忙，他们不愿决付出更多的时间和精力向分析人员讲解业务。面对这种用户，其对策是：需求分析人员改变沟通技巧，讲清楚软件需求的重要性，见缝插针，抓住关键点，向其咨询，以用例和模型的方式向其演示，达到用户和分析人员互相了解和理解。 项目管理者联盟
bbs.mypm.net
问题二：用户与需求分析人员缺乏有效沟通，双方误解需求。人们在交流的时候，经常会发生“答非所问，问非所求”的事情，软件用户与开发人员缺乏有效沟通方法，交流上存在障碍，用户与开发人员存在知识背景差异，都从自己的角度，使用自己的专业术语或语言表达方式来描述和理解问题，使得双方并不能够很好地就软件需求达成共识。2005年北京某公司到我公司做调查，对方技术人员常挂在嘴边的就是“BOM”，但作为用户还没有完全接受这个词，他们用得最多的是流水号、生产线、配套件等。一般说来，用户不太容易从计算机的角度去理解自己的需求问题。从而使需求描述的不一致，不规范，多义性。笔者今年夏季为某事业部编写库房管理软件的时候，笔者采用快速原型化开发了此软件，双方出现了误解的情况，比如：针对“数量”，我理解为整数，但实际上库房数据中“数量”就是以小数为单位，她认为我应该理解了这个问题，实际上她前面输入的数据的确都是整数，使用到一定的程度，结果显示大相径庭。对策：分析人员需要花更多的时间去了解系统用户的特点，多学习用户行业的专业术语，用用户看得懂的语言来表达需求的内容。其次，分析人员除了需要过硬的专业知识，还要具备较强的沟通交流能力。谦虚、诚恳地向用户学习，才能探索出用户的真正需求。如果能在用户方找到即对生产过程了解，又懂计算机知识的行家来为开发人员与用户牵线架桥则是最好不过的事情。club.mypm.net
项目管理者联盟
问题三：用户的需求不断变更 项目管理论坛
项目管理者联盟
由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因，随着客户对项目的越来越深刻的理解，对他过去提出的需求要求一变再变，面对这种情况：需求人员要意识，做软件就像装修房子，永远可以找到需要增加的东西、需要改变的地方，“需求的变化是永恒，需求不可能是完备的”。因此我们在需求获取的时候，一方面应该跟用户讲清楚需求开发的重要性，让用户明白减少后期的需求变更的重要性，且随意的需求变更带来的风险（成本增加、进度延后等）必将由用户和开发者共同承担。另一方面也需让用户明白：开发者和用户更多的是战略合作伙伴关系，其共同的目标是：开发出适合用户需要的软件。club.mypm.net
training.mypm.net
2、需求分析 项目管理者联盟
项目管理者联盟
问题一：主次不分 需求分析人员常站在自身的角度去理解用户的需求造成主次不分。而实际上不同的系统对系统的功能与非功能性需求要求很不一样。比如，金融系统一般对系统的安全质量要求比较高。企业ERP系统一般对信息传递速度要求高一些。针对这种情况，首先需求分析人员可以借用当前的需求分析工具和图形的方式，明确用户的功能需求和非功能需求，特别注意产品性能、使用性、完整性、可靠性等非功能性需求。其次就要充分考虑到哪些需求是相对固定的需求，哪些可能会产生变动的需求，哪些需求会牵一发而动全身，区分这些需求，设定用户的每项需求、特性或使用实例的优生级并安排在特定的产品版本或实现步骤中，以应付客户后期的需求变更。项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
