为了建立一个真正满足客户需求的系统，项目团队首先必须确定系统要解决的问题。然后，团队必须确定涉众，从中获得业务和用户需要，对其进行描述，并区分它们的优先级。从这一组高层期望或需求出发，对产品或系统特性集达成一致意见。
详细的软件需求应该以客户和开发团队都能理解的形式写下来。我们发现，使用客户的语言来描述这些软件需求在取得理解和共识的过程中是最有效的。这些详细的软件需求随后用作系统设计规约的输入，或者作为实施和验证所需的测试计划及过程的输入。软件需求还应该促进初始用户文档规划及设计。
图 8 - 需求管理结构概述
为了推动需求管理，项目团队应该：
对项目的常用词汇表取得一致。
制定系统前景，描述系统将要解决的问题以及系统的主要特性。
至少获得五个重要领域的涉众需要：功能、可用性、可靠性、性能和可支持性。
决定使用哪些需求类型。
为每一个需求类型选择属性及属性值。
选择需求的说明格式。
确定创造一种或多种需求类型的团队成员，以及那些对此有贡献或仅仅进行查看的团队成员。
决定所需的可追踪性。
制定变更需求需遵守的提议、复审、决议程序。
开发一个追踪需求历史的机制。
为团队成员和管理人员创建进度和状态报告。
这些必要的需求管理活动与行业、开发方法和需求工具无关。它们同时也很灵活，能够在最严格、变化速度最快的应用软件开发环境下执行有效的需求管理。
文档简介
用文档来描述需求的决定值得认真考虑。一方面，书面记录是人们广泛接受的一种交流形式，对大部分人来说，这是自然不过的了。另一方面，项目的目标在于产生系统，而不是文档。
常识和经验告诉我们，问题不在于是不是要记录需求，而是怎么记录。文档模板为需求管理提供了一种统一的格式。Rational RequisitePro 不仅提供这些模板，还提供其他特性，将文档内的需求链接到一个包含所有项目需求的数据库。这种独一无二的特性不仅允许需求自然地记录下来，同时还能存放在关系型数据库里，便于访问和管理。
文章来源于领测软件测试网 https://www.ltesting.net/
