需求分析的流程和规范

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