需求管理(Requirements Management)_sysware.orm需求管理

    翻译：Alex

    需求管理的目的是管理一个项目中的需求并且鉴别需求、计划与产品之间的差异。需求管理实践包括变革管理(Change Management)和可追溯性(Traceability)两个方面。[1]

介绍(Introduction)

    需求管理包含关于权衡(Balance)、沟通(Communication)与调整(Adjustment)的一切内容。为了避免需求分析中一个类超越自身而覆盖了另一个类的功能，团队中成员之间始终如一(Constant)的沟通指关重要。例如，在内部应用的软件开发中，业务需求往往强烈到可能因此而忽略了用户需求，或让人认为在创建用例的时候，用户需求已经了解清楚了。

可追溯性(Traceability)

    需求的可追溯性与需求的全程文档相关。若要达到可追溯性的要求，我们应当保证可以追踪到最初的原始需求以及每一次需求的变更都被记录下来。甚至应当将保证在软件系统完成部署并投入使用之后产生的需求具有追踪的可能。[2]

    需求来自不同的源头，如业务中购买产品的用户、市场经理和实际用户。这些人对软件产品有不同的要求。使用需求可追溯性原则可以保证实现的功能可以被对应到需求分析时需要此功能的个人或是组织。这种方法可以在开发过程中用于区分需求的优先级，判断对于某用户需求的价值。在部署之后当对用户调查(User Study)发现某个功能未被使用时，这种方法还可以帮助我们找到原先该功能需求被列入开发计划的原因。

开发中的阶段(Stages of Development)

    在开发过程的每个阶段中，都有一些关键的需求管理活动和方法。假设我们使用一个五阶段的开发流程：调研(Investigation), 可行性分析(Feasibility)，设计(Design),开发与测试(Construction and Test)和发布(Release)。

    调研(Investigation)

    调研时，最初的需求是来自用户(Users)、公司(Business)、开发团队(Development)的。我们要在这三个方面问一些同样的问题：如目标是什么，有什么限制，正在使用的工具或流程等。只有当这些需求非常清晰了，我们才能开始功能需求分析地工作。

    这里提一点需要注意的地方：不管开发团队多么努力，在项目的初始阶段，需求都无法被完整的定义出来。一些需求会改变，可能是很简单的原因：不想做了，或者是项目组内部或外部的力量影响。因此，一开始的时候，团队成员必须就适应性是成功的重要因素这一点，在思想和行动上达成一致。

    分析阶段(Analysis Stage)的交付件是一个得到所有团队成员认可的需求文档。在后续阶段中最为激烈的开发阶段，这份文档被用于指导开发，避免功能范围扩张(Scope creep)或不必要的变更。随着系统开发的进展，每一个新的功能都将极大的增加新的可能性，因此需求说明(Requirements specification) 将把控方向，将团队共识固定在原有的意见上，并允许团队对范围变更进行受控的讨论(Controlled discussion)。

    当大多数开发组织仍然仅仅使用文档管理需求的时候，一些人已经开始使用软件工具管理需求基线(Requirements baseline)。这些工具使用数据库管理需求，并具有自动追溯（如：链接需求的父子关系、需求与测试用例的对应关系等）、需求基线的建立、版本控制和变革管理的功能。通常这种工具具有导出的功能，可以将需求信息导出到标准文档。

    可行性分析(Feasibilty)

    可行性分析阶段，需求成本(Cost)明确下来。For user requirements, the current cost of work is compared to the future projected costs once the new system is in place.(未翻译) 我们此时应该问这样的问题：“什么样的数据错误增加我们的成本？”，或者“当前操作界面上操作错误(Operator Error)的成本是多少？”确实，新软件的需求常常由公司财务部门的人发现的这些问题而引发。

    业务上的成本应包括诸如此类的问题：“哪个部门的预算为这个项目支付费用？”“市场对于新软件产品应用的预期回报率是多少？”“开发一个新的、易用的系统，我们可以在培训和支持上减少成本而产生的内生投资回报率是多少？”

    技术上的成本与软件开发和硬件成本相关。“我们有没有合适的人选进行开发？”“Do we need new equipment to support expanded software roles?”（未翻译）最后的这个问题是非常重要的一类。开发团队必须调查清楚这种最新的自动化工具是否能提供足够的处理能力，将用户的工作转移到系统上，从而节省人的时间(People time)。

    这些问题也指出了需求管理中的一个基本点。人和工具组成一套系统，这种情况在以电脑或电脑软件为工具的情况下非常重要。人的大脑擅长于并行处理和通过部分数据判断趋势。而CPU则擅长于串行处理并且进行精确的数学运算。因此对软件项目进行需求管理的总体目标就应该是保证自动化的工作被分配到合适的处理器上。例如：“不要让用户记住他在软件的哪个界面上，而是让软件随时告诉用户正在系统的那个地方。”或者“不要让用户在两个界面上输入相同的数据，而要让系统保存数据，并在第二个屏幕中自动填充。”

    可行性分析阶段的交付件是预算(Budget)和项目计划(Schedule for the project)。

    设计(Design)

    假设我们已经精确估算了成本并且具有足够大的利润空间，项目可以推荐到设计阶段。在设计阶段，需求管理的主要工作是比对设计的结果与需求文档，以保证正在进行的工作没有超出范围。同样，适应性是成功的至关重要的因素。有一个关于项目进行中范围变更比较成功的故事。在二十世纪八十年代初期，福特汽车的设计师认为在八十年代末期，汽油的价格将达到每加仑3.18美元。但是在Ford Taurus的设计过程中，汽油价格确围绕在1.5美元每加仑波动。设计师们决定如果汽油价格持续保持较低的水平，他们可以设计一款更大、更舒适并且更强大的汽车。当这款车在全国发售的时候创下了销售记录，主要原因就是其宽大的车身和舒适的驾驶体验。

    然而在大多数情况下，如此程度的背离原始需求会导致问题。因此需求文档成为帮助团队在设计时考虑变更非常重要的工具。

    开发与测试(Construction and Test)

    在开发与测试的阶段，需求管理的主要工作是要保证工作和成本控制在计划与预算中，于是出现了一些工具实现这一需求。一个在这一阶段主要的工具是原型开发和迭代测试。对于软件应用程序，在软件还在架构的时候，用户界面就可以以纸面的形式呈现给潜在的用户，并进行测试。这些测试的结果将被记录在用户界面设计意见中并在界面设计的时候提交设计团队。这样做可以节省他们的时间并且让工作更容易开展。

    版本管理(Release)

    你可能认为在产品发布的时候，需求管理就结束了。这样理解并不准确。从这一点开始，与用户接受性(Application's acceptability)相关的数据需要被收集起来，可以在一个版本调研阶段使用。因此，这一过程又开始了。

    工具(Tools)

    目前市场上已经有桌面和基于Web的需求管理工具。

    INCOSE maintains a database of project tools including Requirements management tools

    建模语言(Modeling Language)

    系统工程建模语言SysML包含了需求图表的定义，开发人员可以以图形的方式组织、管理和追踪需求。   

 

    参考(Reference)

 

• CMMI Product Team (August 2006). "CMMI for Development, Version 1.2" (PDF). Technical Report CMU/SEI-2006-TR-008. Software Engineering Institute. Retrieved on 2008-01-22.
• Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz Requirements Management: Interface Between Requirements Development and All Other Engineering Processes Springer, Berlin 2007, ISBN 354047689X  

    原文：http://www.wiki.cn/wiki/Requirements_management