在定义需求的流程中，业务分析师在什么时间，以及怎样把开发人员引入到这过程中呢？

在需求定义流程中引入开发人员看起来非常自然。毕竟，即使他们没有明确地介入到这一流程中，开发人员也确实定义了所有类型的需求，当他们构建软件时。他们做的无数的需求（有些可感觉到，有些感觉不到），这些需求是关于编写什么代码，以及怎么编写。但通常情况下，这类决策要需要根据正式程度做一些改进。业务分析师可以提供正式的框架，帮助开发人员开发技术需求。

两种收集需求的常见模型，虽然有时会事与愿违，但依然保留着。第一个，也是老模型，它围绕着软件开发只是技术编程这一误解构建的。开发被视为是一种黑艺术，只能由电脑科学家完成。这样，整个开发团队由编码程序员组成，他们可能完全知道，也可以不完全知道实际的代码需求。这一模型开始提升为业务分析师的角色，敏捷项目经理和测试人员更加成为了开发团队的中心。

第二个错误的模型仍然根深蒂固，但同样危险。有人说需求是要创建软件的特性。确实，开发人员在定义产品如何工作中是中心的角色；但这实际上是更高水平设计的形式，而不是需求。开发人员确实比业务人员更了解数据架构、界面和其它关键因素，这些在使工作正常运行所实施的解决方案中都要考虑到。然而，这些因素需要构建在业务相关需求的坚实基础之上。

开发人员还需求知道的是，业务分析师提供了更好理解的业务实际的需求。开发人员可能具有相关的，有价值的业务洞察力。然而，这些洞察力并不他们角色所需要的，而且与不是他们的核心能力。与业务分析人员首先需要坚实的理解业务需求。然后把开发人员引入到定义软件需求中，来满足业务需求。