需求分析：技术语言和业务语言统一

    在软件开发领域，人们越来越多地提到需求。和其他领域一样，这里的需求源自用户的“需要”，而不同则在于开发软件系统最困难的部分就是准确说明开发什么，这就是软件项目的需求。

    为什么我们如此多的关注需求？原因恰恰在于我们无法有效地获取需求，我们无法准确地表述需求，而需求的变化对于整个项目的成本、周期影响极大，所谓“一石激起千层浪”。所以，想让项目获得成功，首先要做好需求分析。

    什么是需求？

    要了解需求的本质，首先需要明确需求是为谁负责的？是用户还是开发人员？当然用户是上帝，我们所做的一切工作对他们负责，但是客户的愿望并不全是需求，只有从业务要求开始，考虑开发实际情况，在此基础上建立了开发承诺的才能称之为需求。

    1997年IEEE软件工程标准词汇表对软件需求的定义为：

    用户解决问题或达到目标所需的条件或能力。
    系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
    一种反映上面1或2所描述的条件或权能的文档说明。
    请注意该定义中“条件或权能”、“合同和规范”这些词，通俗地说，“需求”就是用户的需要，包括用户要解决的问题、达到的目标，以及实现这些目标所需要的条件，表现形式一般为文档形式。
 
   虽然需求工作被越来越多的提及，但是在项目开发工作中，很多人对需求的认识还远远不够。小到几十万元，大到上亿元的软件项目，它们的需求都或多或少的存在各种问题，原因是多方面的：开发者的重视程度、技术原因、人员组织原因、沟通、机制等，都表明做好软件需求开发是一项系统工作，而不是简单的技术工作。 

    需求开发和管理

    什么才是好的需求？装修过房子的人应该知道，装修开始之前，设计师都会给出一份设计图或者效果图，客户满意了才开始动工。开发软件和装修房子一样，一份好的需求就是在开发前做出交付时的效果。要做到这一点，这需要从业务、功能和系统三个层次分别进行分析和描述。

   需求分析的过程包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、验证等一系列产生需求的活动，分为四个阶段：需求获取、分析、制订规格和验证。这四个阶段不一定是遵循线性顺序的，它们是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括变更控制、版本控制、需求跟踪和状态跟踪等工作。

    从工作流程上，需求分析过程从用户愿望开始，获取需求，分析需求，形成规格文档；经过迭代验证，产生需求变更，形成新的规格文档，并进行版本控制；反复进行该迭代验证过程，直至双方确认，形成建立开发承诺的需求文档。

    如何做好需求分析？

   需求分析对分析人员提出更高要求，它不仅需要分析人员具有丰富的需求分析经验和良好的专业素质，还要求分析人员具有良好的学习能力、公关能力、语言能力和组织能力。在实际工作中分析人员要面对不同单位、不同部门的不同人员，他们可能有着不同文化、不同关系和不同的管理水平等，面对如此纷繁复杂的环境，如何做好需求分析工作呢？这里从需求开发和需求管理两个方面介绍一些相关的方法。

    首先，需求开发可采用的方法很多，不同的开发方式有着不同的分析方法： 

    绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
    可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。 
    需求优先级：确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。 
    系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。 
    图形分析模型：绘制图形分析模型是编制软件需求规格说明的重要手段。它能帮助分析人员理清数据、业务模式、工作流程，以及它们之间的关系，找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图等。
    需求管理的目的则是控制和维持需求，保证项目开发过程的一致性。需求管理的方法主要包括：

    确定需求变更控制过程。制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。
    进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门更好地做出决策。
    建立需求基准版本和需求控制版本文档。确定需求基准，这是项目各方对需求达成的一致认识，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
    维护需求变更的历史记录。将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。
    跟踪每项需求的状态。可以把每一项需求的状态属性（如已推荐的、已通过的、已实施的或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。

    需求分析：统一技术与业务语言

    需求分析工作离不开这样两个人群：业务人员和技术人员。而他们两者说话的语言是不一样的：一个谈业务，一个说技术。需求分析的目标就是使两者在软件项目上说一种语言，将两者“捆绑”得最贴合，项目成功的可能性就越大。