答案

在预项目阶段，业务分析师识别与预算、时间、资源、法规要求、技术兼容性、公司内部政策或市场外部条件相关的关键业务限制。分析师详细记录这些限制，重点强调它们对需求和可能绕过方案的影响。

用于记录的特定部分在需求规格中，例如：

**限制：**
- 最大预算 — 500万卢布
- 最迟在2024年9月1日启动
- 系统仅在现有基础设施（Linux服务器）上运行

关键特点：

• 在设计开始前全面分析限制。
• 评估它们对业务需求、设计和项目架构的影响。
• 与客户记录并定期澄清限制。

针对性问题。

限制是否是业务需求的一部分？

不，限制是实现需求的外部条件或框架，而不是需求本身。

可以忽略非正式的限制吗？

不可以。即使是非正式的限制（例如，公司内部规则）也极为重要，必须识别并纳入文档中，否则项目可能会被搁置。

业务分析师是否对技术限制的准确描述负责？

是的，分析师必须描述业务和技术限制，虽然技术细节的具体描述可以与架构师或技术专家协商。

常见错误和反模式

• 对限制的详细描述不足，导致过程中出现后续“惊喜”。
• 忽略隐性限制（例如，许可、品牌等）。
• 依赖口头协议而没有适当的文档。

生活实例

负面案例： 在一个银行项目中，没有考虑数据存储的法律限制。

优点：初期进程更快 缺点：在最后审计中产品未通过，遭到封锁，公司不得不紧急重新设计架构。

正面案例： 分析师从第一天起就让法律部门参与讨论，并记录每个符合152-FZ法的限制。

优点：问题在初期得到检测，解决方案立即考虑到法律 缺点：需要更多时间来协调文件。