需求发现

  • 自悟
  • 交谈
  • 观察
  • 小组会
  • 提炼

需求的获取

需求获取的任务

  • 发现和分析问题的原因/结果关系
  • 与用户进行各种方式的交流
  • 按照数据、过程和接口观察问题的不同侧面
  • 获取的需求文档化,形式用例、决策表、决策树

需求获取应遵循的原则

  • 深入浅出的原则
  • 以流程为主线的原则

需求获取的过程

1).开发高层的业务模型

2).定义项目范围和高层需求

3).识别用户类和用户代表

4).获取具体的需求

5).确定目标系统的业务工作流

6).需求整理与总结

需求分析阶段任务

  • 获取需求

    • 通过启发、引导从客户(或用户)那里得到的原始需求是他们的业务要求(needs)
  • 分析需求

    • 完整性
    • 正确性
    • 合理性
    • 可行性
    • 充分性
  • 需求定义
    • 编写需求规格说明
  • 验证需求
    • 对编写的需求规格说明进行评审

需求的作用

  • 现代系统中软件的作用
  • 软件在系统工程中的作用
  • 自顶向下和自底向上的开发

需求的定义

需求的基本性质

  • 必要性
  • 无歧义
  • 可测的
  • 可跟踪
  • 可测量

需求的分类

  • 功能需求
    • 业务需求(why)
      • 范围文档
      • 特性
      • 价值
    • 用户需求(what)
      • 用例说明文档
    • 系统需求(how)
      • 系统行为
      • 需求规格说明文档
  • 非功能需求
    • 性能
    • 外部接口
    • 设计约束
    • 质量属性

需求规约

一个需求规约时一个软件所有需求陈述的正式文档,是软件的概念模型

基本性质

  • 重要性与稳定性程度
  • 可修改
  • 完整
  • 一致

格式

  • 引言
  • 总体描述
  • 特定需求

作用

  • 双方的技术合同书
  • 项目管理控制点
  • 产品设计的起始点
  • 测试和使用的基础

系统需求规格说明

需求分析阶段的重要任务之一是根据分析的结果编写需求规格说明,经过严格评审并得到用户确认之后,作为这个阶段的最终成果。 按照国家标准GB/T 8567—2006《计算机软件文档编制规范》,涉及需求规格说明的文档有“软件需求规格说明(SRS)”、“数据需求说明(DRD)”等。

应该包含在SRS中的内容

  • 功能 :软件应该提供什么功能?
  • 外部接口 :软件如何与人、系统硬件和其他系统等进行相互作用?
  • 性能 :软件系统在运行速度、可用性、响应时间、恢复时间等方面有什么要求?
  • 特性 :软件系统在可移植性、可维护性、安全性等方面有什么考虑?
  • 设计约束 :是否存在必要的标准、开发语言、数据库、资源限制、运行环境等因素的影响和策略?

不应该包括在SRS 中的内容

  • 项目开发计划
    • 诸如成本、人员、进度、工具、方法等
  • 产品保证计划
    • 诸如配置管理、验证与测试、
       质量保证等
      
  • 软件设计细节
    • 需求通常用于表达“做什么”,
       而不描述“如何做”
      

编写需求规格说明的原则

  • 原则1:只描述“做什么”而无须描述“怎么做”
  • 原则2:必须说明运行环境
  • 原则3:考虑用户、分析员和实现者的交流
    • 对形式化和自然语言之间作出恰当的选择
    • 明确的理解最重要,不存在十全十美的软件规格说明书
  • 原则4:力求寻找到恰如其分的需求详细程度
    • 一个有益的原则就是编写单个的可测试需求文档
    • 建议将可测试的需求作为衡量软件产品规模大小的尺度
  • 原则5:文档段落不宜太长
    • 简短
    • 记住:不要在需求说明中使用“和/或”、“等等”之类的词
  • 原则6:避免使用模糊的、主观的术语
    • 如用户友好、容易、简单、迅速、有效、许多、最新技术、优越的、可接受的、最大化、最小化、提高等
    • 不可验证
  • 建议:采用一种标准的SRS 模板

SRS模板

需求规格说明的质量要求

  • 正确性
  • 一致性
  • 完整性
  • 可验证性
  • 无二义性
  • 可修改性
  • 可跟踪行

需求评审

评审的主要内容

1)功能 2)性能 3)接口 4)数据 5)硬件 6)软件 7)通信 8)正确性 9)完整性 10)可行性 11)一致性 12)兼容性 13)清晰性/无歧义性 14)安全性 15)健壮性 16)可理解性 17)可修改性 18)可测试性和可验证性 19)可维护性 20)可追踪性 21)可靠性 22)其他

需求评审中的常见风险

1)需求评审的参与者选取不当 2)评审规模过大(10-30页) 3)评审组规模过大(3-7人) 4)评审时间过长(2h以内)

需求管理

需求跟踪

需求跟踪性是 维护需求与软件制品之间的映射 (例如设计对象、用例、测试用例、已实现的软件组件等),以满足整个开发生命周期的需要。

  • 建立需求跟踪性的过程
    • 识别并唯一地标识SRS 中的每一个需求
    • 建立和更新SRS 中的跟踪矩阵
    • 工作制品的创建者负责增加该制品与需求的跟踪信息
    • 跟踪矩阵应该作为工作制品的一部分进行审查

需求变更管理

需求管理的所有活动中,最重要的是—— “需求变更管理”,包括: 识别出的问题-->问题分析和变更描述-->变更分析和成本计算-->变更实现-->修正后的需求

项目需求及需求规约

results matching " "

No results matching " "

results matching " "

No results matching " "