3. SysML需求建模实战

在IBM Rhapsody中，SysML需求建模不是把Word文档搬进模型，而是把需求变成可追溯、可验证、可分析影响的模型元素。本节围绕需求图、需求属性与ID、追溯关系、需求与用例/测试的关联，以及需求变更影响分析五个关键点展开，重点说明在Rhapsody中如何落地。

一、需求图：把需求组织成可导航的结构

需求图（Requirement Diagram）是SysML中用于表达需求及其关系的专用图。在Rhapsody中，需求图通常包含三类核心元素：需求（Requirement）、包（Package）和追溯关系（Trace、Derive、Satisfy、Verify、Refine等）。需求可以嵌套在包中，形成需求层级；需求之间可以通过«deriveReqt»表示派生关系，通过«trace»表示一般追溯，通过«satisfy»表示设计元素满足需求，通过«verify»表示测试用例验证需求。

实际建模时，建议先建立需求包结构，例如“系统需求—子系统需求—软件需求”三层。每个需求用独立的Requirement元素表示，而不是用注释或文本块代替。Rhapsody中需求元素可以显示为矩形框，框内包含Id、Text等属性。需求图的价值在于：它让需求之间的派生、追溯、满足和验证关系一目了然，而不是散落在文档中。

二、需求属性与ID：让每条需求可识别、可管理

Rhapsody的需求元素支持自定义属性。最关键的属性是Id和Text。Id是需求的唯一标识，建议采用“项目缩写-层级-序号”的格式，例如“SYS-REQ-001”“SW-REQ-012”。Text是需求正文，应使用“系统/软件应……”的规范句式，避免模糊词如“快速”“友好”“尽量”。

除Id和Text外，还可以扩展以下属性：优先级（Priority）、来源（Source）、状态（Status）、验证方法（VerificationMethod）、版本（Version）。在Rhapsody中，可以通过需求元素的Features窗口或属性页设置这些字段。例如，VerificationMethod可取值：Test、Analysis、Inspection、Demonstration。这样，每条需求不仅可读，还可被筛选、排序和统计。

三、需求追溯关系：从需求到设计、到测试

追溯关系是需求建模的核心价值。Rhapsody支持多种SysML追溯关系：

• «deriveReqt»：派生关系，表示下层需求由上层需求推导而来。例如，系统需求“SYS-REQ-001 系统应支持用户登录”派生出软件需求“SW-REQ-005 软件应提供用户名密码校验接口”。
• «satisfy»：满足关系，表示设计元素（类、组件、活动）满足某条需求。例如，类“LoginController”满足“SW-REQ-005”。
• «verify»：验证关系，表示测试用例验证某条需求。例如，测试用例“TC-Login-001”验证“SW-REQ-005”。
• «trace»：一般追溯，用于补充说明或跨层级关联。

在Rhapsody中建立追溯关系时，可以直接从需求图工具栏拖出关系线，也可以使用“Dependency”并选择构造型。建立后，可以通过需求元素的“Traceability”视图查看上下游关系。建议每条需求至少有一条«satisfy»和一条«verify»，否则该需求处于“未实现”或“未验证”状态。

四、需求与用例/测试的关联

需求与用例的关联通常通过«trace»或«refine»建立。用例描述系统行为，需求描述系统约束或能力。一个用例可以追溯多条需求，一条需求也可以被多个用例覆盖。在Rhapsody中，可以在用例图上建立用例与需求之间的依赖关系，并在需求图中反向显示。

需求与测试的关联通过«verify»建立。测试用例可以是Rhapsody中的TestConductor测试用例，也可以是外部测试管理工具中的条目。建议在Rhapsody中为每条需求建立至少一个验证用例，并在测试用例属性中记录验证方法、预期结果和实际结果。这样，需求覆盖率可以通过“已验证需求数/总需求数”计算。

五、需求变更影响分析

当一条需求发生变更时，影响分析的目标是找出所有受影响的设计元素、用例和测试用例。在Rhapsody中，可以通过以下步骤进行：

1. 选中变更的需求元素，打开“Traceability”视图或“Relations”窗口。
2. 查看所有«deriveReqt»、«satisfy»、«verify»、«trace»关系。
3. 沿关系链向下游遍历，列出受影响的子需求、设计类、用例和测试用例。
4. 评估每个受影响元素是否需要修改，并记录变更影响清单。
5. 更新需求版本号和状态，重新运行相关测试用例。

例如，若“SYS-REQ-001 系统应支持用户登录”变更为“系统应支持用户名密码和短信验证码两种登录方式”，则受影响的可能包括：派生需求“SW-REQ-005”、设计类“LoginController”、用例“用户登录”、测试用例“TC-Login-001”。影响分析的结果应反馈到变更控制流程中，确保需求、设计、测试三者同步更新。

六、实操建议与检查清单

在Rhapsody中做需求建模，建议遵循以下检查清单：

• 每条需求是否有唯一Id，且Id命名规则统一？
• 每条需求是否有明确的Text，且使用“应”句式？
• 每条需求是否至少有一条«satisfy»关系指向设计元素？
• 每条需求是否至少有一条«verify»关系指向测试用例？
• 需求之间是否存在«deriveReqt»关系，层级是否清晰？
• 需求是否与用例建立了«trace»或«refine»关系？
• 变更需求时，是否执行了影响分析并更新了相关元素？

需求建模的最终目标不是画出一张漂亮的图，而是让需求成为可追溯、可验证、可变更管理的模型资产。在Rhapsody中，需求图、需求属性、追溯关系、用例/测试关联和变更影响分析共同构成了需求工程闭环。只有把每条需求都纳入这个闭环，需求变更才不会失控，测试覆盖才有依据，设计实现才有源头。