正确功能的正确解决方案
如果我所做的只是将价格信息发布到网上，我可以到最近的小学里找个人来编写 HTML。如果我要做的是尝试采用多种语言跨越国界扩展我的供应链，并确保可以全天候地访问，那么我的功能和容量就必须更为可靠。
开发和设计解决方案的体系结构时需要考虑的最重要的事项之一就是所需的对应功能和容量级别。
经验丰富的专业人员可以帮助客户将业务需求转换为业务意图。业务意图更为模糊，但更与“基本需求”和“投资回报”一致。
笔者相信业务需求和IT 功能存在重叠。正是由于这个模糊不清的界线使得体系结构设计成为了一个困难而费时的过程。不管是采用瀑布式还是迭代方法，规划和需求分析阶段始终都很单调乏味。客户很少知道他们需要什么，经验丰富的专业人员有责任帮助客户将业务需求转换为IT功能。
这并不能通过只使用良好的工具和方法来实现，因为每个项目都是独特的。尽管两家公司相似，但他们都会告诉你各自的业务具有独特性，并将这些不同之处视为他们的竞争优势。很多时候，文化、地域和地理位置对业务需求的影响决定着IT解决方案。政府法律法规和 标准可能要求技术人员根据部署解决方案的场合对相同的业务需求采用不同的方法来设计。
捕获和交付构件的技术，包括用例、场景文档、Rational Unified Process (RUP)—应当在参与的客户中一致地实现。如果在项目进行中，客户改变了主意（业务需求）和决定，例如系统不需要24x7的可用性，而只需要8x7的可用性即可，因为他们不希望承担24x7解决方案所带来的高成本，仍然可以很好地使用这些构件。
管理不确定性和易变性
由于这是一个与人相关的问题，将组织的业务需求转换为 IT 要求的挑战并不能仅靠使用工具或方法得以解决。
业务需求和IT要求有很大部分都是重合的;即对于某些人而言业务需求指的是“我已更改的或新的业务流程是什么样的？”而对其他人而言，则指的是“我如何借助对应的关键成功因素实现一系列业务目标？”还有些人觉得，这可能只意味着为一系列业务干系人提供功能，如新设备或新页面，或者仅是新的自动化业务规则执行而已。
重要的事实是:业务需求和IT要求之间是否存在差别？这可能会引出一通长篇大论，但我的观点是，缺乏术语以及用来讨论这个问题的共同语言本身就是一个问题。
我们的挑战是业务需求和要求通常仅得到了部分理解，而且通常具有易变性。很多开发方法都在通过引入迭代开发、工具以及其他技术来适应这个不确定性和易变性。但这些方法仅解决了这个问题的一部分，因为这个不确定性和易变性仅是此问题的一部分而已。在假定特定方法是最优的方法之前，要求流程必须了解要进行的项目的类型。
项目类型因大小、范围、组织关心的重点、文化、对解决方案的认识、当前环境以及其他因素的不同而有所差异。各种项目类型要求我们对每个项目采用不同的方式来处理将组织的需求转换为 IT 要求的问题。不同的类型项目要求在开发方法、工具以及应如何管理要求方面采取不同的处理方式。
由于这是一个与人相关的问题，将组织的业务需求转换为 IT 要求的挑战并不能仅靠使用工具或方法得以解决。认为可以通过改善工具或创建新开发流程、方法或技术来完全解决此问题的想法是错误的。
经验丰富的专业人员知道将组织的业务需求转换为 IT 要求的过程中必须根据一系列因素进行调整。这些因素包括:对业务需求了解多少？对IT要求了解多少？最终的解决方案的概貌如何？
文章来源于领测软件测试网 https://www.ltesting.net/
