需求分析

需求分析的方法有很多，以前也曾经是工作的一部分。只是，眼前的问题不是需求分析的方法的问题，而是需求分析的管理问题。

对于开发小组的使用成员(包括用户)来说，需求确定是极具认知性和创造性的活动。

做软件需求最重要就是分解用例场景，没有用例就不是需求。

可行性分析是要决定“做还是不做”。需求分析是要决定“做什么，不做什么”。即使可行性分析是客观的、科学的，但决策仍有可能是错误的。因为决策者是人，人会冲动，有赌博心态。如果可行性分析表明做某件事的成功率是10%，失败率是90%，倘若该事情的意义非常大，决策者也许会一拍脑袋：“豁出去，干！”于是这世界就多了一份极喜与极悲。

需求在软件项目中扮演着及其重要的角色。不管哪种类型的项目，无论是新产品开发，还是外包项目，开发队伍都面临着普遍存在的需求问题，比如如何获取有效的需求、如何处理需求的变更等等。这些问题有其共性的一面，也有和项目类型相关的一面。本文着重讨论了在新产品开发项目中的一些需求问题，以及避免和解决这些问题的建议。

有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。

总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。

作为一个软件项目经理，在项目开发进行中，你是否遇到过这样的问题：客户的一个电话，就推翻了之前你与客户、与你自己的开发团队，经过再三讨论而确认定下来的需求。之后你就重新开始了和客户、和你的开发团队进入新一轮的需求谈论中，甚至是无休止的谈论。甚至要重新设计现有的架构。

首先你要找那些让你提交这些报告的人，问明白他们说的这些报告究竟需要涉及什么内容，给什么人看，格式和文档的风格要求是什么。如果他们不能告诉你一个满意的答案，就没有必要给他们一个他们自己都不知道想不想要的东西。

项目需求分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。 在原则上，需求阶段监理应尊重承建方的项目管理和项目分析能力；在具体的任务开展上，以不深入、不干扰承建方的自主权为主，除非在项目合作过程中发现承建方的项目管理以及项目分析能力存在很大的差距和不足。

需求分析的重要性，笔者相信已经深入人心。如何做好需求调研，大家说起来也已经一套一套了。笔者这里从另一个层面来谈谈需求分析，即如何来判断你需求是否可以过关。笔者试图通过四个问题，来检验你需求.....

百度百科的“产品经理”词条中，第一句话是这么描述的：“自1927年，美国P&G(宝洁)公司出现第一名产品经理(Product Manager)以来，产品管理(Product Management)制度逐渐在越来越多的行业中得到应用和推广，并且取得了广泛的成功。”

一个网站项目的确立是建立在各种各样的需求上面的，这种需求往往来自于客户的实际需求或者是出于公司自身发展的需要，其中客户的实际需求也就是说这种交易性质的需求占了绝大部分。面对对网站开发拥有不同知识层面的客户，项目的负责人对用户需求的理解程度，在很大程度上决定了此类网站开发项目的成败。因此如何更好地的了解、分析、明确用户需求，并且能够准确、清晰以文档的形式表达给参与项目开发的每个成员，保证开发过程按照满足用户需求为目的正确项目开发方向进行，是每个网站开发项目管理者需要面对的问题。

Eclipse平台是一个具有一组强大服务的框架，这些服务支持插件，比如 JDT 和插件开发环境（PDE）。它由几个主要的部分构成：平台运行库、工作区、工作台、团队支持和帮助。

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。设计良好的界面能够引导用户自己完成相应操作，起到向导作用。

需求分解是将需求分解成一个个的功能点。先写出大的模块，然后子模块，然后细分成各个功能点，模块的个数名称，子模块的层数，名称，功能点均可维护。同时每个功能点后面还有开发人员和维护人员的记录。开发人员和维护人员可以根据不同时期叠加。

基于行业应用的信息系统，其业务政策依赖性比较强，业务需求每年都有变化，一般基于这类需求的系统开发周期如果跨越自然年度，几乎很难进行需求定位。如何把握业务需求，成为项目成功建设的关键。

不同的软件开发过程对于需求变化的解决办法是不同的。统一软件开发过程（UP、RUP）的解决办法是预防和控制需求的变化。

首先你要找那些让你提交这些报告的人，问明白他们说的这些报告究竟需要涉及什么内容，给什么人看，格式和文档的风格要求是什么。如果他们不能告诉你一个满意的答案，就没有必要给他们一个他们自己都不知道想不想要的东西。

软件需求包括3个不同的层次――业务需求、用户需求和功能需求。