回答。

问题历史：

最初在IT项目中，系统分析师主要关注业务需求，而技术限制被忽视或传递，从而导致不切实际或过于昂贵的解决方案。

问题：

技术限制并不总是被声明——客户可能不知道它们，开发人员可能没有考虑到这些限制，导致结果与基础设施或集成系统的能力相矛盾。

解决方案：

系统分析师主动与架构师、DevOps、QA和集成商进行访谈：

• 确定技术栈、业务和基础设施依赖关系。
• 将需求与架构原则进行协调：SLA、容错性、可扩展性、许可或安全限制。
• 记录并验证业务要求与能力之间的折衷。
• 应用“情景分析”和“非功能性需求”的方法。

关键特征：

• 早期记录所有相关负责人的限制和依赖。
• 文件化折衷和隐性限制。
• 持续将项目解决方案与公司的架构相对照。

有陷阱的问题。

如果隐性技术限制没有明确说明，可以忽视它们吗？

正确：不能。隐性技术限制（例如，集成超时、消息大小限制）始终需要进行深入研究和记录，即使它们没有明确说明。

分析师是否应该参与架构会议/研讨会？

正确：是的，系统分析师是业务与架构师之间的桥梁，向双方传达需求并记录解决方案。

仅收集业务需求，是否足够而不分析遗留限制？

正确：不够。遗留代码、许可证、集成（legacy）有时会导致比明确要求更多的限制。

常见错误和反模式

• 低估隐藏限制和旧系统的依赖。
• 忽略“非书面”的架构规则。
• 只记录业务部分而不考虑技术可行性。

生活中的例子

负面案例： 分析师记录了基于业务流程的集成，但未了解接口中数据传输速度的限制。

优点：快速实现规格。 缺点：系统未能承受负载，业务损失了资金和时间。

正面案例： 分析师参与了架构会议，识别了限制（最大线程数=100，每10秒一次集成），与业务商定了截止限制。

优点：解决方案可行，集成稳定。 缺点：不得不妥协减少功能，并向客户解释这一点。