【原】共性需求复用的形式——用例

GJB5000B需求和开发管理实践域RDM 3.4“开发和重用共性需求”，要求实施GJB5000B三级的组织基于领域进行开发、管理和重用共性需求。标准中给出了开发方法——领域分析与逆向提取，但是没有明确共性需求存储、重用的形式。

那么，共性需求应当采用何种形式存储/复用呢？

如果开发共性需求采用的是领域分析的方法，那么分析的需求文档可能是软件研制任务书或者更灵活的用户需求载体，而在这类需求载体中，需求的描述可能是一个需求标题加上一个段落的需求描述（通常的软件研制任务书），可能是一个用户故事卡片（敏捷开发中的需求载体），这两种形式都不太适合作为共性需求的载体，因为我们进行共性需求的复用，不仅仅是复制粘贴一段需求描述这么简单，我们复用共性需求是希望这些共性需求和其他需求一起构成完整的需求模型，能够快速地勾勒出软件的功能结构。

所以，用以存储和复用开发出来的共性需求的更好的形式是用例。

一个用例的描述通常包括以下内容：

• 执行者（actor）：任何操作软件的人或其它软件。

• 项目相关人员（stakeholder）：对软件有特定兴趣的人或物。

• 主执行者（primary actor）：主动激活与软件的一次交互活动，从而达到某一目标的人或其它软件。

• 用例（use case）：规定软件行为的协议。

• 范围（scope）：待开发的软件。

• 前置条件和保证（precondition and guarantee）：在用例执行之前和之后必须满足的条件。

• 主成功场景（main success scenario）：正常情况下完成这一用例所需的一系列步骤。

• 扩展（extension）：主成功场景执行过程中出现的异常情况。

• 扩展中的编号指在主成功场景中异常情况发生时所处的执行步骤号码（例如，步骤4a和4b指主成功场景中步骤4的两种不同情况）。

• 当一个用例引用另一个用例时，被引用的用例加下画线。

使用用例来描述需求，可以使得需求的描述更为清晰，使得共性需求的搜索更为精准、复用更为方便。

而且，可以使用UML绘制用例图，用例图的使用对于基于模型的软件开发来说，可以更方便地建立需求模型。

用例图示例

用例可依据需求分析中提取出来的术语进行设计，但不是所有的用例都适合作为可复用的用例组件，可复用的用例组件需要在功能相近的一组用例的基础上进行抽象。

这正是：

共性需求咋承载，用例可做不二选

描述清晰好搜索，搭建模型更适宜

参考书目：软件复用：结构、过程和组织，作者：雅各布森，出版社：机械工业出版社