需求分析

作为软件产品的需求分析，我们是否应该注重具体的实现？对需求文档的撰写、需求描述，是否应该涉及到具体的实现呢？还是应该在功能上给予说明即可？

学习掌握用户需求

一个项目中需求调研的充分与否是项目日后成败的关键要素之一，这一点我想没有哪位项目经理不认同吧？不过咱说的需求调研可不只是拿张纸记记客户说什么就完了，调研顾名思义就是调查和研究客户的想法，我感觉应从以下几个步骤入手。

很多需求分析人员都有这样的经历，在捕获需求时，根据客户的阐述，做了记录，然后开发出了系统，客户却说很多地方不符合他们的意思，要求修改。我们分析一下捕获需求过程中存在的问题。

用例（Use case）已经成为被广泛使用的需求开发技术。围绕着用户和他们的目标，而不是产品的功能，这大大提高了开发出能真正满足客户需求的软件产品的可能性。然而，由于对用例所知甚少，造成用例的神秘感与日俱增，很多开发团队也在试图成功地运用用例技术。本文将针对已经开始应用用例技术的分析师，特别指出五处应避免的用例应用陷阱。

变更控制的目的是管理变化。变更控制对项目成败有重要影响，事前要明确定义，事中要严格执行。实施变更之前有四个重要控制点：授权、审核、评估和确认；在实施过程要进行跟踪和验证，确保变更被正确执行。

最近正在做新产品的需求分析，对需求分析阶段的很多问题又有了重新的认识，在此结合以前的经验，就软件需求分析阶段的各个任务，做一下总结，与大家分享。

铱星系统可以作为这个的一个反例，keso把铱星系统的失败归结为超过了消费能力，但在我看，铱星系统失败的原因很多，其中一个就是铱星系统没有找准用户的需求，作了很多用户不需要的功能。在非洲某个国家里面的某个地点的通讯和我有什么关系，甚至中国新疆某个地点的通讯和我有关系吗？那么凭什么要我为铱星这些我用不到的功能付钱。

昨日的需求的陷阱-简单不简单的评论中，有一位朋友写下的评论。看我之后我感觉这个话题有点沉重，项目该如何处理，或许不是一两句话可以说清楚的。不过对于任何人来说，遇到这种项目就像遇到鬼一样可怕，完全就是一个恶梦的开始。

客户的参与是发布一个优秀软件的关键因素，在项目的开始阶段就应该努力致力于为你的项目征求各个客户的意见。软件需求的成功，和软件开发的成功都取决于开发者是否尽可能地采纳客户的意见。为了征求客户的意见，我们该如何学习/快速掌握用户需求？

在很多人的印象中，敏捷软件开发是种类似黑客行为的过程，是程序员最爱的勾当。不写文档，不作需求分析，没有项目经理，做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要，因此在经过考虑后，放弃了敏捷方法。

收集用户需求（你也可以将它称作启发用户需求，如果你更喜欢这个花哨的名称）一般比较困难，现在让我们考虑一下为什么这个过程如此艰难，当你面对这个问题时你会采取什么办法处理。我想，此时，有两个问题你必须先考虑：即何为用户的隐含需求（即未明确表达出来的需要），何为明确需求，如何在它们之间进行转化，以及这种转化的意义？

辛辛苦苦的熬了几个月，软件开发终于快要告一段落了。系统功能已经基本完成了，在准备按部就班的完成最后的测试时，客户突然提出要改变某些非功能性需求。这对于软件开发团队来说，不亚于晴天惊雷。

很多人都没有意识到业务需求阶段应该做些什么事情，实际上业务建模是最重要的一件事情。不要觉得业务建模这个词很深奥，让人模不着头脑。其实所有做过需求分析的人都做过业务建模，比如你了解企业的运作模式就是一种你脑海中的业务建模。但是大多数人都没有科学的、系统的、文档化的做过业务建模。

软件需求，只有三个要素：Actor、系统边界、输入输出。

软件的需求分析的主要目的是，通过与用户广泛的交流得出所要完成的目标系统必须具备那些功能，应该为用户完成些什么工作。即确定"目标系统必须做什么？".需求分析相当于从用户到软件工程人员之间架设了一道桥梁，软件工程人员通过需求分析得到用户的需求，成为软件编制所实现的目标。

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

需求来自于用户，不论是用什么方法，首先应是找到我们需要访问的对象，然后对对象进行分类，再逐步对对象进行访问。具体访问过程中可以针对不同的访问对象采用不同的方法，根据访问的内容进行确定。本文要讨论的是，如何确定我们的访问对象，以及如何对确定用户对象进行调查。

在编写合同或者招标书时，经常有性能需求方面的章节。在编写这部分内容时，文档撰写人经常会觉得无从下手。笔者根据实际工作中碰到的项目，将实际项目中可能使用性能需求进行汇总。

软件的需求分析必须要有对原业务的一个深入了解、提取、抽象、升华的过程，管理软件需求分析尤其如此。