需求映射矩阵

未学,跳过

RMM模版

RMM-需求映射举证


组织结构图

组织结构图模版

组织结构图:Organization Chart 很多人认为组织结构图不可以作为需求模型,然而对许多类型的项目而言,组织结构图是项目中最初使用的模型之一。
一个项目可以有三个层面的组织结构图:部门、角色、人员。
组织结构图只显示组织实体的层级关系。
broadcasting

例子

broadcasting broadcasting broadcasting

创建组织架构图

创建组织结构图的流程是:
定位现有的组织结构图 –> 确定级别 –> 完成组织结构图

使用组织结构图

  • 识别有需求的人
  • 确定内部用户
  • 确定外部用户
  • 使用组织结构图和处理流程的完整性

在审查流程的步骤时,应该针对组织架构图交叉检查那些步骤,确定相关的部门、团体和角色包括在组织架构图中,
并参与审查。为了保证良好的覆盖,不遗漏任何组织,可以对流程的每一步提出问题:

  • 谁执行的这个步骤
  • 我是否已经见过他们

常见错误

  • 不使用组织结构图来确定干系人
  • 只包括项目团队成员

参考文献

  1. 《软件需求与可视化模型》第三部分 — Joy Beatty && Anthony Chen

特性树

特性树模版

特性树是一种可以显示功能之间关系的模型。
broadcasting

示例:
broadcasting

创建特性树

broadcasting

识别特性

考虑一个产品概念特性时,需要先考虑同级的高层次特性,再通过特性树进行发现。

组织特性

  • 多个特性的子特性:当一个子特性是多个特性的子特性时,选择一个相对访问较多的特性分支。不要在特性树上重复同一子特性
  • 没有父特性的子特性:可能有几个子特性,不确定它们的父特性,那么单独建一个父特性把这些子特性连上去即可

创建特性树

  • 不要过早定稿,因为很难移动。当组织结构初步成形后再将特性移入定稿。
  • 寻找缺失特性
  • 用于头脑风暴和特性组织的亲和图

使用特性树

可以在项目早期完成特性树,用于描述项目范围

  • 组织需要
  • 组织需要的工作
  • 推导出需求

常见错误

  • 在一个级别上特性数目不对:7+/-2准则对于方便使用特性树很重要。确保在任何特性下不超过10个子特性
  • 在整个特性树上的命名一致。

参考文献

  1. 《软件需求与可视化模型》第二部分 — Joy Beatty && Anthony Chen

处理流程

处理流程模版

它描述了有人来执行的业务流程,展示了要执行的活动,执行这些活动的顺序,以及用户为实现预期结果
而做出的不同决定。处理流程不要与系统流程混淆,处理流程描述用户要执行的行动,系统流程描述系统
要执行的活动。

处理流程总有方向箭头连接流程步骤,箭头指明流程所遵循的所有可能的路径,每个流程都有明确的起点和终点。 处理流程使用BPMN(业务流程模型和符号)的一个子集就可以进行描述。

broadcasting

例子

broadcasting broadcasting

创建处理流程

  1. 确定流程步骤
  2. 创建L1处理流程
  3. 创建L2处理流程
  4. 必要时创建L3处理流程

创建L1处理流程

应该在项目创建初期创建L1处理流程,显示流程的全部范围,引发额外的处理流程。
与企业干系人合作,勾画出最粗略的活动,定义端到端的完整的解决方案。

  • 创建图表
    • 每一个步骤都应该是<动词> + <宾语>
    • L1层次过高通常不会有分支,因为层次过高很难准确显示分支
    • L1、L2、L3每一级的步骤可以设置编号,编号在自己的级别保持唯一性
  • L1的范围
    • L1中包含整个端到端的流程,甚至包含一些不在项目内的步骤
    • 当L1完成后,展示给企业的干系人,让他们审查完整性和正确性

创建L2处理流程

完成L1流程的创建与审查之后,开始定义L2的处理流程。通常L1处理流程中的每一步都有自己的L2处理流程。

  • 如果L1流程的步骤超出了项目的方位,就不需要创建L2了
  • 如果需要可以把L1的多个步骤(简单、相关)组织在一起连到一个L2处理流程 broadcasting

具体步骤:

  • 识别流程步骤: 召开提案会议、观察用户、执行现有的步骤、审查现有流程和处理流程
  • 写作步骤: 确保流程都有相似的细节程度,为L3流程保存较详细的细节
  • 考虑7+/-2原则,每个级别不超过10个步骤
  • 命名方式:[用户] + <动作> + <宾语> + [在系统]
  • 使用泳道:许多用户、用户组在一个处理流程中交互执行,泳道是很有用的。
  • 添加其它流程的引用

必要时创建L3处理流程

什么时候需要创建L3处理流程? 如果L2的处理流程数量超过20个,或者更多;
或者开发和测试人员需要呈现额外的细节;

使用处理流程

  • 针对听众提供不同层次的细节
  • 主持提案和评审会议
  • 推进完整性
  • 推导出需求

常见错误

  • 详细程度与流程不相符
  • 审查者不了解细节的层度
  • 审查者忘记查看流程全貌
  • 流程有太多的步骤
  • 系统反应和用户操作混淆
  • 不包括项目流程之外的流程

参考文献

  1. 《软件需求与可视化模型》第三部分 — Joy Beatty && Anthony Chen

—  原创作品许可 — 署名-非商业性使用-禁止演绎 3.0 未本地化版本 — CC BY-NC-ND 3.0   —