软件需求管理过程

软件需求管理过程

软件需求管理的过程

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

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

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

需求分析模型

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

• 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(一部分用户的想法)