需求开发与管理.docVIP

需求开发与管理 9.1 目的 通过调查分析、定义、评审、确认、跟踪、沟通等需求活动，使开发方和客户对需求有共同清晰的理解，并依据双方确认的需求开展后续开发工作（如设计、编程、测试等）。 9.2 关键活动与流程 需求分析与管理的流程如图9-1所示，关键活动是“需求调查与收集”、“需求分析与定义”、“需求评审与确认”、“需求跟踪”和“客户沟通”。 开发人员和客户 迭代 图9-1 需求分析与管理的流程 该流程的主要工作成果见表9-1。 表9-1 需求分析与管理流程的主要工作成果 关键活动 主要工作成果 责任人 需求调查与收集 用户需求信息 需求开发人员 需求分析与定义 《需求规格说明书》 需求开发人员 需求评审与确认 《需求评审报告》 项目经理和客户代表 需求跟踪 《需求跟踪矩阵》 项目经理 客户沟通 项目经理和客户代表 9.2.1 需求调查与收集 需求分析人员起草需求问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。问题表可以有多份，随着调查的深入，问题表将不断地被细化。 需求分析人员确定需求调查与收集的方式，例如： 与用户交谈，向用户提问题 参观用户的工作流程，观察用户的操作 向用户群体发调查问卷 与同行、专家交谈，听取他们的意见 分析已经存在的同类软件产品，提取需求 从行业标准、规则中提取需求 从Internet上搜查相关资料 需求分析人员与被调查者建立联系，确定调查的时间、地点、人员等，要特别留意的是不要漏掉典型的用户。在调查过程中随时记录需求信息，格式参见表9-2。 表9-2 需求信息记录 需求标题 调查收集人 方式、时间、地点 用户信息 需求信息记录 说明“是什么”、“为什么”等 9.2.2 需求分析与定义 1）需求分析 （1）需求分析的目的：对各种需求信息进行分析、消除错误、刻画细节等。 （2）需求分析的方法：常见的有“问答分析法”和“建模分析法”两类。 问答分析法 问答分析最重要的问题是：“是什么”和“为什么” 每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。 B．建模分析法 需求建模：指用图形符号表示、刻画需求。 对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。 2）需求定义 需求定义的目的：根据需求调查和需求分析的结果，进一步定义准确无误的软件需求，产生《需求规格说明书》。后续开发工作将依据《需求规格说明书》开展。 需求分析员按照指定的文档模板撰写《需求规格说明书》。如果待开发的产品分为软件和硬件两部分的话，则应当分别撰写《软件需求规格说明书》和《硬件需求规格说明书》。 《软件需求规格说明书》的格式参加表9-3。 表9-3 软件需求规格说明书 软件需求规格说明书 产品介绍 （1）说明产品是什么，有什么用途。（2）介绍产品的开发背景。 产品面向的用户群体 （1）描述本产品面向的用户的特征（2）说明本产品将给他们带来什么好处及他们选择本产品的可能性有多大。 产品应当遵循的标准或规范 阐述本产品应当遵循什么标准、规范或业务规则（Business Rules）。违反标准、规范或业务规则的产品通常不大可能被接受。 4．产品范围 阐述本产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。 5．产品中的角色 阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。 角色名称 职责描述 6．产品的功能性需求 6．0 需求分类 功能类别 功能名称、标识符 描述 Feature A Function A.1 … Feature B Function B.1 … 6.m.n Function M.N 名称、标识符 优先级 功能描述 数据及解释 输入、输出 操作序列等 其它说明 参考示例 7．产品的非功能性需求 8．其它需求 9.2.3 需求评审与确认 （1）需求评审 项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。需求分析人员根据内部评审意见，完善《需求规格说明书》。在内部评审期间不能解决的问题，留到正式评审时处理。 项目经理邀请客户代表和最终用户代表一起评审《软件需求规格说明书》