软件需求管理过程

软件需求管理过程

软件需求管理过程

软件需求管理的过程

• 需求确认(确认需求规格)
  需求获取–>需求分析–>需求规格编写–>需求验证
• 需求变更(开发过程中的需求管理)
  需求获取，需求分析，需求规格编写，需求验证，需求变更

需求获取： 将用户脑子中的东西抓取过来
方式： 问卷，讨论会，情景展示，面谈(最有效)等

需求分析： 是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述

需求分析模型

需求规格编写
需求分析工作完成的一个基本标志是形成了一份完整的，规范的需求规格说明书。

需求验证
对需求规格进行评审，例如评审需求的正确性，一致性，可行性，可验证性等。

需求变更管理： 核心是制定一个变更控制系统，需求变更控制系统可以避免频繁变更需求的混乱局面。

• 确定需求变更控制过程
• 确立变更控制委员会(SCCB)
• 进行需求变更影响分析
• 跟踪所有受需求变更影响的工作产品
• 建立需求基准版本和需求控制版本文档
• 维护需求变量的历史记录
• 跟踪每项需求的状态
• 衡量需求稳定性

4.2、传统需求建模方法

1.原型方法(通过不断评价原型来确定需求的方法) 建模工具：axure等

2.基于数据流建模(是结构化分析方法的主要方法)

基于数据流----结构化分析方法

• 20世纪70年代发展起来的面向数据流方法
• 是一种自顶向下逐步求精的分析方法
• 根据软件内部数据传递，变换的关系进行分析的

基于数据流的技术

• 数据流图（DFD）
• 数据字典（DD）
• 系统流程图

3.基于UML建模

基于UML方法

• 基于面向对象的情景分析方法
• 从用户角度出发考虑的功能需求
• 用例是系统向用户提供一个有价值的结果的某项功能

UML需求视图

• 用例视图（Use Case Diagram）
• 顺序图（Sequence Diagram）
• 状态图（State Diagram）
• 活动图（Activity Diagram）

基于UML方法综述

• 识别出系统的角色（Actor）
• 描述需要的Use Case
• 实现用例视图
• 实现顺序视图，活动视图，状态视图等

敏捷需求建模方法

敏捷思维认为项目需求是慢慢清楚的过程，对于需求，可以采用渐进明晰的分析方法。

Product Backlog： 产品待办事项列表

• 包含产品想法的一个有序列表
• 需求的来源
• 一个长短不定的列表
• 可以是模糊的或是不具体的
• 逐渐完善，越来越明确

Sprint Backlog： 待办事项列表的细化

• 按照迭代计划，逐步细化需求，形成story(故事)
• 鼓励开发人员，测试人员，业务分析人员和产品负责人合作编写故事
• 确保所有的故事都足够小，可以持续交付工作

从用户故事开始(User Stories)

• 作为某类型的用户(As a < type of user >)
• 希望达到什么目的(I want < some goa >)
• 原因如何(So that < some reason >)

如何评价用户故事(Good User Story?)

• Independent(独立性)
• Negotiable(清楚描述)
• Valuable(业务价值)
• Small And Estimatable(小到可估算)
• Testable(可测试的)

故事优先级(Prioritisation of Stories)

用户故事需要被标注优先级

• 基于商业价值
• 价值还必须得到正的投资回报的支持
• 考虑它的风险

客户选择要包含在下一个故事中的故事，根据他们的优先级和进度估计发布。

根据一些规则来对故事排序

1.MosCow

1. Must have(必须实现的功能)
2. Should have(虽重要，但是可以省略的功能)
3. Could have(扩展性功能，要求不急)
4. Want to have(一部分用户的想法)