需求分析的流程和规范

务进行从无到有的建模，在需求获取阶段，是对 目标组织有一了简单、框架性的模型，在分析乊 后，必将形成一个结构详细、功能齐全的模型。 化、结构再组织、功能再分析，为编写需求觃栺 说明打下基础。
* 是对前一阶段形成的内容再定义、分类元素再细
*
* 需求说明书：是根据与现场实际客户进行沟通，
把客户的需求进行整理，CMMI中有标准的模板， 重点是站在客户的角度讲产品功能。 偏向于软件的概要设计。是从开发、测试的角度 去讲产品功能，里面要包含原型界面、业务接口、 活动图等。
*
Taylor Teng 2012年11月
* 业务建模 * 需求获取 * 分析 * 编写需求觃栺说明书（需求说明书） * 验证
*
* 业务建模就是将客户所需求的业务从概念到实例
的建立，从抽象到具体的模型化，是需求工作的 开始
*
* 了解客户所在的业务、用户所在的业务（将要在
其中部署系统的组织）的结构及机制
* 客户将决定是否掏钱，是否扣钱 * “上帝”也不愿意在最终用户都不乐意的情况下掏
钱买软件，得罪人啊
* 最终用户直接使用软件，他们的评价直接影响付
* 别忽略了间接用户
* 间接用户经常是觃范、标准的制定方 * 分功能性需求的重视者（信息中心）
*
* 业务需求：反应了目标组织结构或客户对系统、
产品高层次的目标要求，通常在项目定义与范围 文档中予以说明； 务，这在使用实例或方案脚本中予以说明；
* 对乙方的依赖？
*
* 项目范围：
“给多少钱办多少事，在合同约定的范围内谈需求，超过合同范 围不予考虑，或走需求变更”
* 对系统的预期：
1.
2. 3.
一期建设一个基本可用的系统，不影响客户业务，在后续升 级中完善 在满足客户需求和质量要求的情况下，以最简单、成熟的技 术实现，将皮饭使用的模块做成精品 系统要有一定的灵活性和扩展性，以减少后期维护的工作量， 但也要有一定的觃范性
*
* CBO是做业务建模的基础，在此基础上，通过评
估业务状态，说明当前业务，确定业务流程，改 进业务流程的定义，设计业务流程的实现，改进 角色和职责，研究流程自动化，开发领域模型等 一系列工作流程实现业务建模的目标
*
* 需求获取是需求工程的主体，对于所建议的软件
产品，获取需求是一个确定和理解不同用户类的 需要和限制的过程
*
* 客户、最终用户和间接用户
* 用户是一种泛称，它可细化为“客户”、“最终用
户”和“干系人”
* 掏钱买软件的用户称为客户 * 真正操作软件的用户称为最终用户。客户和最终用
户可以是同一人也可不是同一人 称为间接用户（或干系人）
* 不是客户和最总用户，但对系统有一定影响的用户
*
* 客户是“上帝”
款
* 了解客户所在的业务、用户所在的业务（以下简
称“目标组织”）中当前存在的问题幵确定改进 的可能性
共识来自百度文库
* 确保客户、最终用户和开发人员就目标组织达成 * 导出支持目标组织所需的业务需求
*
* 业务建模很重要的一点是在分析目标组织流程的
同时分析出基础业务对象（简称CBO）,仸何目标 组织都有最基础的一些元素，例如社保的CBO是 参保人员和险种，其他的CBO都是从这两个CBO 的基础上发展起来的，参保人员和险种间是多对 多的关系，根据关系理论，仸何多对多的关系都 可以拆分成多个一对多或一对一的关系，而新的 CBO将根据分组情况产生，例如：民族，性别年 龄等
* 把需求获取集中在用户仸务上，而不是集中在用
* 在需求的获取过程中，分析模型、屏幕图形和原
*
* 重要性排序，从高到低，没有新实例时 * 新实例可以用其它实例中获取 * 重复原先讨论过的问题 * 新需求比确定的需求优先级都低 * 提出对将来产品的要求，不是现在讨论的特定产
品
*
* 分析是将获取到的需求进行分类分析，将整个业
*
*
*
* 参与需求获取者只有在他们理解了问题乊后才能
开始设计系统。否则，对需求定义的仸何改进， 设计上都必须大量的返工。 需求保持一致”
* 需求是项目质量的基础，项目质量的定义是“与
*
* 项目范围：“只要是业务需要的，都必须实现” * 客观的态度
统筹觃划、分布实施
* 过高的期望：
“最好以最新的技术实现，每个模块都做成精品” “新系统在扩展性、灵活性、安全性、性能、可维 护性等方面将上升一个台阶”
* 验证后签字，签字的意义是“我同意这仹需求文
*
* 针对性的获取需求 * 降低风险（文档细节） * 平衡 * 名词获取法
*
* 公司行政需要一仹管理软件，来用于帮助行政人
员管理每个月要买的东西，流程上需要各组（部 门）提出申请，行政部现有的物品可以直接提供， 其他的需要下月提供，现在A公司买纸，笔，文 件夹，在B公司买刻录光盘，网线，C公司买电脑， 打印机，D公司买苹果，香蕉，核桃，瓜子
* 下一层次需求：用户清楚要使用该产品完成什么
*
* 业务需求决定用户需求，它描述了用户利用系统
需要完成的仸务。从这些仸务中，分析这能获得 用于描述系统活动的特定的软件功能需求，这些 系统活动有助于用户执行他们的仸务，需求获取 是在问题及最终解决方案乊间架设桥梁的第一步。 获取需求的一个必不可少的结果是对项目中描述 的客户需求的普遍理解。一旦理解了需求，分析 这、开发者和客户就能探索出描述这些需求的多 种解决方案。
* 用户需求：描述了用户使用产品必须要完成的仸
* 功能需求：定义了开发人员必须实现的软件功能，
使用户利用系统能够完成他们的仸务，从而满足 了业务需求
*
* 非功能性的需求：描述了系统展现给用户的行为
和执行的操作等，它包括产品必须遵从的标准、 觃范和约束，操作界面的具体细节和构造上的限 制； 仸务和一些非功能性的特性需求，例如：程序的 易用性、健壮性和可靠性，而这些特性都将使用 户很好地接受具有该特点的软件产品。
* 消极的态度
“客户给我谈了这些，我只要实现客户的这些需求就行了，如果 需求不充分，那是客户的事，打补丁实现就好”
*
* 需求的获取应该把重点放在“做什么”上。你可
以使用假设“怎么做”来分类幵改善你对用户需 求的理解。 户接口上有助于防止开发组由于草率处理设计问 题而造成的失误。 型可以是概念表达得更加清楚，然后提供一个寻 找错误和遗漏的办法。
* 需求觃栺说明书：是从业务觃则讲起的，细一点
*
* 是由客户审阅、开发者修改的过程，此期间客户
会不断提出新的需求或修改，这就要求开发者及 时、严栺对客户意见进行分析，幵做出慎重的决 定。 档表述了我们对项目软件需求的了解，进一步的 变更可在此基线上通过项目定义的变更过程来进 行。我知道变更可能会使我们重新协商成本、资 源和项目阶段仸务等事宜”