软件需求管理过程
软件需求管理过程
软件需求管理的过程
- 需求确认(确认需求规格)
需求获取–>需求分析–>需求规格编写–>需求验证 - 需求变更(开发过程中的需求管理)
需求获取，需求分析，需求规格编写，需求验证，需求变更
需求获取： 将用户脑子中的东西抓取过来
方式： 问卷，讨论会，情景展示，面谈(最有效)等
需求分析： 是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述
需求分析模型
需求规格编写
需求分析工作完成的一个基本标志是形成了一份完整的，规范的需求规格说明书。
需求验证
对需求规格进行评审，例如评审需求的正确性，一致性，可行性，可验证性等。
需求变更管理： 核心是制定一个变更控制系统，需求变更控制系统可以避免频繁变更需求的混乱局面。
- 确定需求变更控制过程
- 确立变更控制委员会(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
- Must have(必须实现的功能)
- Should have(虽重要，但是可以省略的功能)
- Could have(扩展性功能，要求不急)
- Want to have(一部分用户的想法)
