这些因素在项目进行期间会不断地发生变化。这正是采用敏捷编程、 IBM Global Services 方法、RUP或其他流程的技术人员不能盲目认为其采用的方法就是正确的方法的众多原因之一。
没有捷径，立即动手，不要等待
如果无法足够详细而清晰地将干系人的需求用书面形式表述出来，则您就没有完成捕获项目要求的任务。
IT架构师在项目的生命周期的初始阶段扮演的主要角色之一是捕获关于干系人的需求的信息。IT架构师必须听取客户和干系人的看法，理解他们的业务需求，并系统地以增量方式形成IT解决方案的结构更为详细的结构。这个过程通常不仅是靠通过经验积累就能完成的，而且必须为一种有所控制的方法。
生活中的两个事实也可应用到 IT 解决方案的开发中: 几乎没有真正的捷径;最好现在就动手，而不要等待。
笔者和客户一起工作时，我常常发现在构建 IT 解决方案中为软件开发项目记录的需求级别非常少。这种定义缺乏的原因是由于将业务需求细化为可操作的 IT 要求是一项很困难的工作，需要经验丰富的人员（这就是为什么 IT 架构师是极其宝贵的 资源的一个原因），将业务需求细化为 IT 要求是一项艰巨的任务，需要将精力放在细节上，而且是一个迭代的过程。
此处要指出的是，必须花大量的时间来详细说明解决方案的需求。统计数据表明，在前期花的时间越多，在开发过程的后期阶段花的时间就越少，从而可以缩短开发周期。
有很多方法可用于将业务需求细化为较高抽象级要求，然后再将此类要求细化为技术 IT 要求。建模是从干系人捕获初始功能要求集的一个主要方法。通过创建用例、建模过程流和形成统一建模语言（Unified Modeling Language，UML）交互关系图，您可以开始将业务要求细化为更为详细的定义，系统必须支持或启用所定义的这些功能。在复杂环境中会使用包括以下内容的更为复杂的方法:组件业务建模或者面向服务的模型体系结构。
这些方法可以确保 IT 要求与业务目标一致，从而让公司能够真正实现 SOA 的价值主张。
从需求进行转换来选择要用于构造解决方案的技术或产品可能成为一个挑战。架构师从过去项目中获得的经验将影响这些决策，但架构师还必须忠实地对每个要求（对满足需求极为重要的 IT 功能）进行评估。确定了 IT 功能后，架构师可以将这些功能映射为体系结构组件（然后映射到技术和产品），从而以增量的方式向他们的解决方案结构添加更为详细的定义。
文章来源于领测软件测试网 https://www.ltesting.net/
