为什么要文档化需求

为什么使用文档

  • 团队工作与交流
    • PM
    • 架构师
    • 软件设计师
    • 程序员
    • 维护人员
    • ……

文档的注意事项

  • 为什么要标准化
  • 我们怎样用其他方法解决沟通问题

用例文档

  • 在⽤户的⻆度以⽤例⽂本为主描述软件系统与外界的交互
  • 基本职责是把问题域信息和需求传达给软件系统解决⽅案的设计者

示例

软件需求规格说明文档

软件规格说明文档

  • 在软件产品的⻆度以系统级需求列表的⽅式描述软件系统解决⽅案

Excises

  • 在⼀栋⼤楼中有⼀个电梯，现在有⼈打算从1楼使⽤电梯到达x楼
    • 请写出其⽤例的场景描述
    • 根据⽤例场景编写SRS⽚段

用例描述

  • 参与者：
    • 用户，目标是用户乘坐电梯到达x楼
  • 触发条件
    • 用户按下电梯按键
  • 前置条件
    • 电梯正常工作
  • 后置条件
    • 用户乘坐电梯到达x楼
  • 优先级
    • 高
  • 正常流程
    • 1.用户按下电梯按键，电梯系统开始运行
    • 2.电梯从之前的楼层到达1楼
    • 3.电梯门打开
    • 4.用户进入电梯
    • 5.电梯关门
    • 6.用户选择自己要去的楼层
    • 7.电梯开始运行，前往x楼层，显示当前楼层
    • 8.到达x楼层，电梯开门
    • 9.用户走出电梯
    • 10.电梯关门
  • 扩展流程
    • 2a.电梯在到达1楼的过程中，经过的楼层有其他用户按下按键，1楼在其他用户想要前往的方向上
      • 1.电梯在其他用户处停下，执行正常流程3-10，再继续执行流程
    • 2b.电梯在到达1楼的过程中，经过的楼层有其他用户按下按键，1楼不在其他用户想要前往的方向上
      • 1.电梯优先处理正在执行的流程
    • 4a.电梯超载
      • 1.警报响起
      • 2.电梯不关门，直到不超载，执行正常流程5-10
    • 5a.电梯门处有阻碍
      • 1.电梯不关门
      • 2.长时间有阻碍，警报响起
      • 3.没有阻碍，电梯关门
    • 6a.用户没有选择楼层
      • 1.电梯关门，进入下一次工作流程
    • 10a.电梯门处有阻碍
      • 1.电梯不关门
      • 2.长时间有阻碍，警报响起
      • 3.没有阻碍，电梯关门

规格说明

  1. 刺激相应序列
  • 刺激：用户按下电梯上或下按钮
  • 响应：电梯移动到用户所在楼层，电梯开门
  • 刺激：超过预定时间（如10s），电梯门处没有阻碍，且电梯不超载
  • 响应：电梯关门
  • 刺激：电梯感应到超载
  • 响应：警报响起，电梯门保持开启
  • 刺激：电梯正常工作
  • 响应：电梯显示当前所在楼层
  • 刺激：用户按下要前往的楼层按钮
  • 响应：电梯前往对应楼层，并在到达后开门
  • 刺激：电梯在非运行状态时，用户按下开门键
  • 响应：电梯开门
  • 刺激：电梯在非运行状态时，用户按下关门键
  • 响应：电梯关门
  1. 相关功能需求
  • Lift.clock：负责相关功能的计时
  • Lift.outsideButton.pressed：用户按下上或下按钮
  • Lift.open：电梯自动开门
  • Lift.close：电梯自动关门
  • Lift.overweight：电梯超载
  • Lift.show：显示所在楼层
  • Lift.report：电梯警报响起
  • Lift.insideButton.floor.pressed：用户按想要前往的楼层
  • Lift.insideButton.open.pressed：用户按开门键
  • Lift.insideButton.open.closed：用户按开门键

文档化需求的注意事项

技术文档写作要点

  • 简洁
  • 精确
  • 易读（查询）
    • 1、有效使⽤引⾔、⽬录、索引等能够增强⽂档易读性的⽅法
    • 2、使⽤系统化的⽅式组织内容信息，提供⽂档内容的可读性
  • 易修改

系统化的⽅式

  • 使⽤相同的语句格式来描述相似、关联的信息
  • 使⽤列表或者表格来组织独⽴、并列的信息
  • 使⽤编号来表达繁杂信息之间的关系,包括顺序关系、嵌套关系和层次关系
    • 对图、表进⾏编号
    • 对⽂档的章节进⾏编号
    • 对信息内容进⾏标识和编号

可修改性

  • Independent
  • ID
    • 1,2,…,n
    • 1,(1.1,(1.1.1,…)),2,(2.1,(2.1.1,…))
    • Function.task.step
  • Reference, not repeat

需求书写要点

  • 需求书写要点
    • 使⽤⽤户术语
    • 可验证
    • 可⾏性
  • 需求规格说明⽂档书写要点
    • 充分利⽤标准的⽂档模版，保持所有内容位置得当
    • 保持⽂档内的需求集具有完备性和⼀致性
    • 为需求划分优先级

需求评审

验证需求文档

验证需求的方法

  • 评审
  • 开发系统测试⽤例
  • 度量

评审的注意事项

  • 重视需求评审
  • 保证⽤户与客户参与
  • ⽤户对场景与线索表现出了最⼤的兴趣
  • 使⽤检查列表

开发系统测试⽤例

  • 以需求为线索，开发测试⽤例套件
  • 使⽤测试技术确定输⼊/输出数据，开发测试⽤例

建立测试用例

  • 主要是基于规格的技术，设计测试场景的输⼊与输出数据

度量需求功能点

  • ⽤例的数量
    • 平均每个⽤例中的场景数量
    • 平均⽤例⾏数
  • 软件需求数量
  • ⾮功能需求数量
  • 功能点数量

度量的意义

  • 如果平均的⽤例场景数量过低，那么就可能存在对异常流程考虑不周的可 能
  • 如果平均⽤例⾏数过⼤或者过⼩，那么可能对⽤例的细分粒度过⼤或者过 ⼩
  • ⽤例数量、软件需求数量和功能点数量应该是相对⽐例均衡的，如果三者之 间有着⾮常⼤的差距，那么可能会有需求的遗漏

功能点度量

  • ⽤于估算和度量软件系统规模与复杂度的抽象单位
  • 在需求开发阶段，估计代码⾏数误差较⼤，使⽤功能点来估算和度量软件系 统的规模与复杂度则有较好的效果
  • 输⼊数量：⼀次有意义的输⼊，需要程序员进⾏⼀次编程处理
  • 输出数量：系统需要对外展示的内容组，表现为屏幕界⾯、打印输出、错误提示等等
  • 查询数量：⽤户的“命令”输⼊，通常表现为⿏标点击和键盘输⼊（热键）
  • 逻辑⽂件数量：系统内部的持久化数据，包括⽂件、数据表等
  • 对外接⼝数量：与外部系统交换数据的软硬件通信接⼝

功能点测度总数