答案。

问题的背景:

随着IT项目的复杂性和参与专业人员数量的增加，出现了一个问题：商业利益相关者需要明确的描述，技术团队需要详细且技术上准确的信息。没有通用标准，因此历史上系统分析师成为了两者之间的“翻译者”，根据目标受众调整需求的形式化程度。

问题:

商业方面的人很难阅读图表和规范，不了解UML/BPMN术语。而开发人员不仅需要用户故事和总体视图——他们需要明确的标准、图表、API图表和数据格式。如果分析师选择了错误的需求格式，就会产生误解、功能不一致和逾期交付的风险。

解决方案:

• 确定关键角色/人物以及利益相关者，并与他们进行一系列采访或调查，以了解他们的经验、期望和需求。
• 对于商业委托人——使用场景（用户故事）、BPMN图表、术语表、互动原型和线框图。尽量避免过度细节化。
• 对于开发——准备结构化的技术规范（SRS、类图、ER图、API描述、验收标准），确保单一解释。
• 对于实施人员和测试人员——提供单独的检查清单、验收标准、测试用例和交互图。

关键：同一组需求以适合每个目标受众的格式进行形式化，避免歧义。

关键特性:

• 需求格式适应受众的能力和期望
• 使用多个相互一致的表示来描述相同的需求
• 在完整性和过度细节之间选择“黄金中间”

具有陷阱的问题。

可以将SRS（软件需求规范）模板传达给所有项目参与者而不进行更改吗？

不可以。同一文档对于不同角色并不有效——对于商业委托人而言，SRS的内容难以理解，而实施团队可能缺乏所需的细节。需求必须针对每个目标受众进行调整。

常听到：“BPMN和UML图完全取代了书面需求描述——这是真的吗？”

不是真的。图表是强大的视觉补充，但总是需要附加解释，因为许多利益相关者（特别是商业）不了解符号。如果没有描述性的部分，会留下很多未理解的细节。

可以在同一部分混合商业和技术需求吗？

不推荐。这会使不同角色的信息寻求与理解变得困难，并导致实施阶段的错误。需要清晰地结构化文档，区分商业需求、技术规范、非功能性期望和验收标准。

常见错误和反模式

• 仅使用单一格式的需求适用于所有角色
• 在不必要的地方过度细节化（“为商业提供的图表多如牛毛”）
• 滥用专业术语
• 缺乏术语表，导致歧义

生活中的例子

负面案例

分析师准备了一份庞大且多页的SRS文档，用英语写，并包含复杂的UML图表。商业利益相关者甚至没有打开它，实施团队凭借目测做出判断，导致集成环节出现缺陷。

优点：

• 从形式上看，文档齐全

缺点：

• 商业并未理解功能
• 多次返工和修改
• 开发人员忽略了部分需求

正面案例

为商业创建了一份包含互动原型和关键商业术语的演示文稿，为技术团队准备了单独的技术规范和API管道。文档在Confluence中维护，并附加有讨论状态。

优点：

• 快速协商
• 开始工作时的缺陷最少

缺点：

• 初始调整模板需要花费时间