户的需要。此外还经常会有一份工作合同来约束开发团队和软件使用方之间的工作关系。开发团队要把握好这三个因素之间的互动关系，把它们互相关联起来进行有机的管理，这能大大提高项目成功的几率。
经验3:重视非功能性需求(Constraints)
对于编写需求说明书而言，涉及法规遵从和提高软件系统质量的非功能性需求（又称约束条件，Constraints）同样重要，它们通常包括软件的性能、界面和可维护性等方面。
编写良好需求应包含对约束条件的覆盖，原因是一旦如下领域（例如，性能、可靠性和易用性等）在开发完成后出现缺陷，通常都无法在系统中对其进行重新设计。因此，在项目初期将所有类型的非功能性需求考虑在内，可帮助开发团队大幅提高项目成功的几率。
经验4:将需求可视化(Visualization)
大多数需求分析人员发现建模有助于直观化文字形式的需求。无论是在白板上绘图、使用Microsoft PowerPoint演示工具，还是仅仅在脑海中构建一个模型，都可视为一种建模方法。以上这种图型化的文档应与文字形式的需求描述一起统一管理，以确保一致性、可跟踪性和变更控制能力。可视化需求建模提供了一种与客户及最终用户沟通的简单而有效的方法，通过该方法可较容易地掌握客户和最终用户的需求。此外，图型化还有助于阐明需求，增进软件项目所有相关人员之间的沟通与协作。
经验5:使需求具备可测试性(Testable)
产生良好需求的另一种行之有效的方法，就是从初期就确保每个需求具备明确的可验证性，这种做法不仅有助于为项目后续阶段做好准备，还可以帮助编写者保持正确的思路。
对于非功能性需求此规则也同样适用，例如，对于“软件必须具有高可用性”这种表述的需求我们无法进行测试，而改写成明确的“普通用户应能够在3分钟内生成一个报告”就使该需求具备了可验证性。
经验6:在客户需求和开发能力之间找到平衡
许多情况下，较少的需求数量有助于产生更加优秀的需求描述。软件工程项目不可能实现既采纳和满足企业所有用户的需求、营销理念和商业计划，同时还符合预算并能按期交付。项目经理必须找到客户需求和开发能力之间的平衡点，确定可为客户带来最大价值，并帮助企业提升创新能力的那些需求，而不是一味地试图满足用户所有需求。
经验7:管理好需求变更
大多数软件工程项目中，来自用户的需求经常会发生变化。随着项目的进展，开发团队要保持清醒的头脑、按照工程要求做出相应调整，并响应不断变化的市场形势和客户需要。仅仅编写出完美的首版需求描述是不够的，如果未能对需求的变更过程进行恰当管理，那么控制不善的变更便可能导致系统和软件功能缺失、返工以及利润损失。开发团队应该实施可靠的、可重复的变更控制流程，借助Telelogic DOORS?、Telelogic Change?等工具，实施成熟的变更管理解决是一个良好途径。
经验8:善于利用监测与跟踪工具
复杂的项目都要求实现自动数据收集功能和简便的报告流程，以简化项目管理工作。同样地，项目经理和所有利益相关者都应拥有计量和趋势的“管理面板”，该面板可帮助他们快速监视项目活动（如，进展、增长和实际需求的变动等）。
项目经理应将其主要精力放在制定决策上，而不是放在手动收集数据和编制报告方面。更为重要的是，必须高水准地显示主要需求的监视信息，从而使用户能够根据异常情况实施管理，并迅速查明故障区域。如果某需求或整个子系统变更频繁，则表示应就该需求对客户进行二次调查。如果执行阶段出现大规模返工的情况