软件需求
- 方案级需求：站在技术视角展开
- 业务驱动需求：站在用户视角展开，关注问题级需求
从方案级需求还原出问题级需求：
因为客户是问题专家，而非解决方案专家，他提出的方案未必能够完美地解决他遇到的问题。需求分析师是“问题解决者”，而不是简单的需 求传递者。
组织应用类软件系统需求全景图：
组织应用类软件系统需求分析18项关键任务：
更／优化型需求分析模板：
示例：
价值需求
价值需求从黑盒子视角回答三个本质性问题：
- 整个软件系统为客户解决了什么问题、创造了什么机会？
- 对于系统而言，最关键的干系人有哪些？
- 各个重要干系人对系统的关注点是什么？有哪些担心（阻力点）？
价值需求分析关键任务及产出：
| 任务 | 产出 |
|---|---|
| 执行好目标分析 | 多份《问题卡片》，场景化地定义项目目标 |
| 干系人识别 | 一张《干系人列表》，列出所有关键干系人 |
| 干系人分析三个任务 | 多份《干系人档案》 |
详细需求
详细需求从灰盒子视角完成三个主题的分析：
- 功能需求：为了给客户提供业务、管理、维护支持，需要提供哪些功能？
- 数据需求：系统所涉及的问题域中有哪些数据，之间是何关系？
- 非功能需求：所处的业务环境会带来哪些约束和质量要求？
软件系统功能主线可分为业务支持、管理支持、维护支持三个角度展开。
- 业务支持
- 首先是固化、优化业务流程，因此业务流程是核心
- 其次是业务延伸到新的通道（诸如手机端），这从本质来说也是一种流程的重构，核心还是业务流程
- 最后是将个人能力转化为组织能力，而这种能力存在于具体的业务场景中，因此“专家场景”是核心
- 管理支持
- 事前风险避免，通过增加管理流程
- 事中风险控制，通过“规则”和“审批”
- 事后总结优化，通过“数据分析”
- 维护支持
- 初始化、配置、排错等
业务支持需求分析的“任务—产物”示意图：
管理支持需求分析的“任务—产物”示意图：
维护支持需求分析的“任务—产物”示意图：
数据需求主线的“任务—产物”示意图：
非功能需求主线的“任务—产物”示意图：
补充分析的“任务－产物”示意图
价值需求篇
目标／愿景分析
- 需求＝预期－现状
- 目标就是问题和机会
- 目标的三种描述方式
- 定性描述
- 定量描述
- 场景化描述
干系人识别
干系人分析
系统分解子篇
业务子系统划分
从技术实现角度来划分子系统是比较典型和常见的做法，但这种做法并不利于“业务驱动”、“用户为中心”思想的落地。
业务接口分析
功能主线子篇
业务流程识别
企业或组织的核心价值在于响应外部客户的服务请求，通过一系列的协作满足服务请求，为客户带来价值，同时为企业／组织带来价值。也就是说，企业、组织中每个成员的工作都是属于某个流程的，而且是多个流程；我们应该寻找到线头，即流程的源头——服务请求，也就识别出了业务流程。
端到端流程：
- 完整：服务请求从提出到满足的全过程
- 边界：职能边界和系统边界
业务流程分析与优化
分层业务流程的参考框架：
业务流程8要素
- 五个基本要素（分工、活动、协作、产物关系、分支）
- 三个管理要素（审核、规则、异常）
业务场景识别
- 用例即业务场景，而一个完整的业务场景应该是独立的、可汇报的、可暂停的单元。
- 用例粒度是由组织分工决定的。
业务场景分析
细化业务场景的业务步骤：
- 重在人机交互而非人机界面，重在用户意图而非用户动作
- 不是写程序，而是结构化陈述
- 遍历步骤分析困难，导出功能
- 识别环境与规则：性能、易用性和部署环境相关
管控点识别与分析
业务报表分析
维护需求分析
数据主线子篇
数据主线的重点在于范围与关系，也就是哪些数据要纳入系统，它们之间的关系是什么，而领域建模正是解决这两个问题的关键。
领域建模
业务数据分析
质量主线子篇
标识关键质量需求
质量场景分析
补充篇
业务规则分析
约束分析
参考
版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆