|
|
| 需求分析过程指南（iSpace建模） |
|
俎涛，火龙果软件 |
|
需求分析负责把用户的需求转化为系统的定义。这需要一系列循序渐进的工作。
下面提供需求分析的工作指南，包括：
• 工作流程
• 角色职责
• 工件：模型、文档、条目
视频： 需求分析过程指南（iSpace 建模） |
| 工作流程 |
| 需求分析的顶级工作流程如下图所示： |
|
| 需求分析工作流程说明如下： |
| 需求分析师收到用户的原始请求，然后进行需求调研，基于需求调研的结果进行业务分析，然后进行系统分析。如有必要，还可以为用户设计方案和产品原型。再开发过程中要对需求变更进行管控，以便能够按时交付。开发完成后，需要对系统进行需求验证，合格的产品才交付给用户。 |
|
| 下面逐一介绍需求分析工作流程中的各个工作的下级工作流程。 |
| 接收原始请求 |
 |
| 目标 |
登记来自客户的原始请求，识别核心需求。 |
| 输入 |
原始请求 |
| 输出 |
原始的愿景 |
| 工具 |
需求建模与管理工具iSpace |
|
| 用户调查 |
 |
| 目标 |
面向用户调查工作背景、当前的现状、存在的问题，以及对未来的期望。 |
| 输入 |
《原始请求》 |
| 输出 |
《需求调研报告》 |
| 工具 |
录音设备，拍照设备，office，电子邮件，即时通信，界面截图工具，需求建模工具iSpace |
|
| 业务分析 |
 |
| 目标 |
对用户方的业务情况进行调查、分析，形成业务理解，在此基础上定义需要系统支持的业务需求。 |
| 输入 |
《需求调研报告》 |
| 输出 |
《业务模型》《业务需求说明书》 |
| 工具 |
需求建模工具iSpace |
|
| 系统分析 |
 |
| 目标 |
分析系统需要什么功能以及非功能需求。 |
| 输入 |
《业务模型》《业务需求说明书》 |
| 输出 |
《系统需求模型》《系统需求说明书》 |
| 工具 |
需求建模与管理工具iSpace |
|
| 方案设计 |
 |
| 目标 |
为客户设计解决方案，以便让客户从整体上对提供什么样的系统、系统如何支持业务、系统如何实施和维护有一个整体的了解。 |
| 输入 |
《业务模型》《业务需求说明书》
《系统需求模型》《系统需求说明书 》 |
| 输出 |
《 XXX 解决方案 》 |
| 工具 |
建模工具 iSpace |
|
| 原型设计 |
 |
| 目标 |
基于系统需求分析的结果，面向最终交付的系统，制作一个用户易于理解的原型，以便让用户知道将来的系统的样子，确认需求。 |
| 输入 |
《系统需求模型》《系统需求说明书》 |
| 输出 |
草稿原型，静态原型，仿真原型 |
| 工具 |
用户交互建模工具 iSpace ，界面原型工具 Axure |
|
| 变更管理 |
 |
| 目标 |
对确认后的需求，如果发生了变更，则要经过评审，才能够接受变更。 |
| 输入 |
《变更请求》《需求基线》 |
| 输出 |
《变更处理单》，《系统版本》 《被变更的组件》 |
| 工具 |
需求管理工具 iSpace |
|
| 需求验证 |
 |
| 目标 |
对需求的实现进行验证，是否满足了先前确认的需求。 |
| 输入 |
待验证的《实现的系统》
《原始请求》《业务模型》 《系统模型》 《 系统原型 》《 需求清单 》 |
| 输出 |
已验证的《实现的系统》
《需求验收记录》 |
| 工具 |
需求建模与管理工具 iSpace |
|
| 需求的技能目录 |
| 编号 |
技能目录 |
概述 |
| 1 |
登记原始请求 |
登记来自客户的原始请求，识别核心需求。 |
| 2 |
需求调研 |
面向用户调查工作背景、当前的现状、存在的问题，以及对未来的期望。 |
| 3 |
业务分析与建模 |
对用户方的业务情况进行调查、分析，形成业务理解，在此基础上定义需要系统支持的业务需求。 |
| 4 |
方案设计与建模 |
为客户设计解决方案，以便让客户从整体上对提供什么样的系统、系统如何支持业务、系统如何实施和维护有一个整体的了解。 |
| 5 |
系统分析与建模 |
分析系统需要什么功能以及非功能需求。 |
| 6 |
原型设计 |
基于系统需求分析的结果，面向最终交付的系统，制作一个用户易于理解的原型，以便让用户知道将来的系统的样子，确认需求。 |
| 7 |
需求确认 |
跟用户方和开发团队确认需求。 |
| 8 |
变更管理 |
对确认后的需求，如果发生了变更，则要经过评审，才能够接受变更。 |
| 9 |
需求验证 |
对需求的实现进行验证，是否满足了先前确认的需求。 |
|
| 需求的工件 |
 |
| 类型 |
工件名称 |
用途 |
| 模型 |
用户模型
|
对用户进行角色划分，描述用户的目标、特征和行为习惯。用户模型是需求人员对用户的画像，是了解用户的重要依据。
|
| 业务模型
|
建模业务流程、业务对象，描述业务现状和业务需求。对于如下情况尤其需要业务建模：复杂的业务或者虽然短期不复杂、但是不断积累的业务。因为业务是系统的价值目标，所以强烈建议建立业务模型，以便全面的了解业务。
|
| 系统模型 |
对系统的功能、接口和非功能需求（性能需求、可靠性需求、可支持需求、设计约束、实施需求）进行建模。因为系统需求各种类型多、细节更多，所以强烈建议通过系统模型对系统形成一个多维度的清晰描述，避免需求疏漏和误解。减少后期不必要的返工。
|
| 方案模型 |
建模业务方案、系统方案、技术方案以及制定实施计划。因为方案涉及的内容多，而且要给客户领导确认，所以方案应该多采用清晰简洁的图示，让客户一目了然，也在客户眼里建立专业的工作风格。
|
| 文档 |
需求调研文档 |
包括需求调研的记录、规章制度、工作图表的整理以及参考资料。需求调研文档各种素材比较多，应该有一个统一的目录，对于各种参考资料作为附录管理起来。并采用需求条目登记对应。 |
| 业务需求文档 |
建模业务流程、业务对象，描述业务现状和业务需求。 |
| 系统需求文档 |
包括系统的功能需求、接口需求、数据需求、性能需求、可靠性需求、可支持需求、设计约束、实施需求等的全面描述。
|
| 解决方案文档 |
包括现状和问题分析、业务方案、系统方案、技术方案以及制定实施计划。
|
| 需求验证报告 |
包括业务需求验证、系统需求验证、用户体验验证。 |
| 条目 |
原始请求 |
记录用户提出的原始的请求，并对原始请求划分优先级，标识核心需求。可以跟踪到需求调研文档。 |
| 需求清单 |
对各种需求的列表，可以跟踪到各种需求模型和文档，建立关系和版本，方便跟踪管理。
|
| 变更记录 |
记录提出的各种变更，并标记变更的来源、影响范围，进而确定变更的优先级，通过变更状态进行跟踪管理。 |
| 原型 |
草稿原型
|
对系统的形态的概念性描述，对于软件来讲一般是指界面草图，表达出界面的基本结构和功能，以便对功能需求进行细化。 |
| 静态原型
|
体现系统的结构和关系的原型，一般用来确认功能结构和系统形态，以便让用户对系统的功能、交互和视觉有全面的了解。
|
| 仿真原型 |
无论是结构、外观还是交互都和真实及系统基本一致，具有可操作性，可以对用户的交互给出和系统一致的反应，一般用于确认人机交互动态效果、系统和系统之间的实时交互反应。 |
|
| 工具目录 |
| 工具类型 |
用途 |
推荐工具 |
| 1.建模工具 |
建立用户需求模型、业务模型、系统模型 |
iSpace,EA |
| 2.需求管理工具 |
登记需求条目，包括：原始请求、产品特性、变更记录。 |
iSpace
iWork |
| 3.文档工具 |
编辑需求类文档，包括：业务需求文档、系统需求文档、解决方案、需求调研报告、需求验证报告等 |
Word
Excek |
| 4.界面原型工具 |
描述界面结构、关系、界面的各种控件，并修饰以视觉效果。也能遍历执行各种界面的交互过程。 |
Axure,MockPlus
powerPoint |
|
|
欢迎购买： |
|
| 具体的价格请联系 teacher@uml.net.cn ，010-62670969 |
| |
659 次浏览  1 次
|
