sp; 项目团队的任何成员都可以建议分析人员在术语表中添加词汇，但是整个项目团队必须对词汇的定义达成一致。作为开发人员，您必须保证清楚地理解了影响您正负责开发的系统领域的关键词汇。
技巧5：坚持项目远景以帮助提供解决方案的环境
为了帮助获得对正在构建的软件应用程序的理解，项目领导人或者分析人员应该将项目团队要解决的特定业务问题文档化。由于时间压力，很多软件团队没有花时间分析他们将要解决的业务问题。相反，他们将重点放在他们负责的特定需求上，并且尽可能快地转移到设计上。如果没有理解业务问题，开发人员就面临着开发出来的产品不不能满足客户希望的风险。
让我们暂且考虑一下车模配件吧，完全包装在一个很好看的盒子里，盒子上印着一个完整的汽车。您打开之后会看到说明书以及大量需要粘合在一起的零部件。如果您只是一头扎进说明书，开始构建您的车模，那么您将不能得到包装盒上所描绘的漂亮的小汽车。您将得到一个不伦不类的东西。然而，如果仔细研究盒子上的图片，然后再根据说明书组装汽车，那么您将得到正确的最终产品，一辆令您兴奋的小汽车。在这项比喻中，盒子上的汽车图片就像是远景，说明书就是需求。同样，在软件项目中，项目团队需要知道远景，以便为客户构建正确的解决方案。作为开发人员，在您研究需求并开始设计之前，先检查项目的远景文档。如果它不存在，那么可以向项目领导人或者分析人员提出该问题，并坚持让他们为您开发一个。这样就可以节省大量的时间，避免浪费在开发无用软件上。
技巧6：采用用例来说明系统功能
以用例的形势表达功能性需求，以更好地理解用户如何使用该软件。通过创建软件的用法故事，用例帮助我们整理需求细节，并避免了开发人员的很多猜测工作。用例在为技术和非技术人员提供需求表达格式方面具有独特作用。它们创建了一个通用描述，表达了软件应该为用户提供哪些功能。通过避免需求传统的用户和系统表示（通常导致技术性稍差的分析人员和技术性很强的开发人员之间的脱节），用例给予软件团队对预期系统功能达成一致理解的更好机会。
此外，用例故事板是构建用户接口原型以确认需求的另一种不错的方法。用例故事板是关于用例中描述的功能如何以用户接口表示的逻辑和概念性描述。用例故事板尤其适用于理解可用性需求。它们代表了用户接口的高级理解，并且开发起来比实际的用户接口更快。用例故事板因此可用于在各种用户接口被原型化、设计和实现之前对其进行讨论。
编写良好的用例已成为一种实践，IBM Rational 在 Rational Edge (http://www.therationaledge.com)上提供了关于如何编写良好用例的在线研讨会和各种文章。此外，对于现有的 IBM Rational 客户，Rational Developer Network 上也有大量的信息。
利用工具自动完成需求管理过程
在进行需求管理时能给予软件团队的最大帮助就是过程指南。一个 RM 工具本身可能有帮助，但是只能达到过程还不错的程度。此外，RM 工具只能帮助自动完成部分过程。比如，没有工具能够取代项目团队成员之间的交流需要。为了成功，首先把重点放在您机构的 RM 实践上，并保证它们是健康的，能够正常工作。只有此时，您的项目团队才能从使用 RM工具中获益。
IBM Rational 提供了完整的 RM 解决方案，包括 IBM Rational Unified Process? (RUP?)中的过程指南、利用 Rational RequisitePro? 进行的工具自动完成，以及来自 Rational University (http://www.rational.com/uni