软件项目需求管理简述

需求的概念

    从根本上说，需求来源于用户的“需要”和“要求”，这些“需要”和“要求”被分析、整理、确认后形成完整的文档，该文档详细地说明了产品“应当”实现的功能。

    需求的重要性

    需求是整个产品链的源头，需求工作的优劣将直接影响到产品的设计，生产，销售和维护的全过程。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。目前国内很多软件业普遍存在这样一个现象：人们并不真正清楚到底该做什么，却一直忙碌不停地开发。
Frederick Brooks在他的经典文章“No Silver Bullet”是这样描述需求的重要性的：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面 向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。

    什么是需求管理

    把所有与需求直接相关的活动通称为需求管理。
    需求管理中的活动可分为两大类，
    需求分析：对用户的需求进行整理、分析和完善，形成文档
    需求维护：需求确认，需求跟踪和需求变更

    需求工程贯穿产品生命周期的全过程。

    需求管理的主要内容
    需求分析流程
    需求调查
    首先需求分析员起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。问题表可以是层次化的，随着调查的深入，问题表将不断地被细化。问题表应当以“选择题”和“是非题”为主。
    其次，需求分析员应当确定需求调查的方式，例如： 与用户交谈，向用户提问题。向用户群体发调查问卷等。
    还可以从用户的工作流程，相关文档以及行业标准、规则中提取需求。分析已经存在的同类软件产品，提取需求。
    最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，进行需求调查。
细化用户需求
    根据用户需求调查，对用户的需求进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。例如采用Rational 的Rose工具进行需求的建模分析。
撰写需求说明书
   需求分析员按照指定的文档模板撰写《需求说明书》。如果待开发的产品分为软件和硬件两部分的话，则应当撰写《软件需求说明书》和《硬件需求说明书》。

    需求确认

    需求确认是指开发方和客户方共同对《需求说明书》进行评审，双方对需求达成共识后作出承诺。需求确认包括两方面的工作：“需求评审”和“需求承诺”。
    需求评审： 对需求的必要性和可行性进行分析，确定需求文档。
    需求承诺： 开发方和客户方的对通过了正式技术评审的《需求说明书》作出承诺，按照“变更控制规程”执行，明确指出需求的变更将导致双方重新协商成本、资源和进度等。

    需求跟踪

    需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。
    需求跟踪有两种方式：
    正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
    逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
    正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。需求跟踪矩阵保存了需求与后继工作成果的对应关系。

    需求变更控制

    需求变更的原因：
    随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。
    市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。
    需求变更控制的目的：
    提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。
    如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。
    需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先建立“游戏规则”。