在整个开发的生命周期中维护在用户与分析人员之间的交流是尤其有效的。双方都应该理解他们拥有相同的目标：建立满足质量要求的可以解决问题的方案，同时成本是可接受的。如果他们的关系是围绕着争论关于什么是以前达成的一致和谁应该为此付钱，而不是建立一个正确的方案的话，那么项目就陷入了麻烦之中。这并不意味着分析人员应该接受所有的需求或者最终用户不应该作出变更的请求。相反，这意味着所有的项目相关的人员应该在提出需求和最终进入到订单中的需求进行一个平衡以形成更好方案的开发。他们需要认可当他们过分的严格时，应该通过一些讨论以达到一个折中的方案，并且要作积极的改变以保持项目按照计划进行。当然，这一点做起来要比说的有难度。但是朝着有效的 团队协作的第一步是在分析人员与最终用户之间建立起有建设性的对话。
过度的指出预想的需求是不明智的
传统的开发方法提倡详细的预先需求，并且在过去的多年里很多人觉得项目失败是因为他们的需求对启动项目是不够详细的。但是增加需求说明的详细程度将会减少的回报。在一些情况下，项目团队需要不断的构建方案，并假设需求在整个项目周期不断的改进。记住：软件项目的主要目标是在尽可能低成本的条件下生成可执行的能够解决手工形式的业务问题的代码。一旦你的需求到达了一定的细化程度，将他们定案的最廉价的方法是对系统进行部分的实现以可以向最终用户进行演示。同时你可以一起确定你还需要提供什么样的其他能力。定案需求通常要经过几次的迭代，在迭代期间你可以调整需求、设计和代码，然后对测试进行引导。
在项目周期的后期你可以不必正式的文档化很多的详细的需求；代码本身可以提供足够的文档，并且很少在团队中误解什么是需要实现方面存在 风险。这依赖于正被开发的系统自然的改变了参与的人数、系统期望的生命跨度、和约的义务和附加的质量 标准的需求。最后，也许是最重要的，你应该象驱赶技术风险一样在项目中尽早驱赶商业上的风险。在细化预想的需求上花费过多的时间会使你的注意偏离出降低关键的风险。
开发人员的新思想
扩大了的职责包括详细设计、实现和单元测试。
成为需求工作中的一部分：帮助阐明需求然后创建符合需求的方案。
成为了测试工作的一部分：按照测试先行的设计原则开发代码。
尽可能的重用已存在的方案而不是重新构建方案。
文章来源于领测软件测试网 https://www.ltesting.net/
