软件需求实践(一).pptVIP

需求分析师培训第一课

需求与需求工程

需求是什么?

业务需求就是系统目标业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。现状：功能分解盛行的今天，常常会犯“盲人摸象”的错误，这使得需求太过脆弱，难以经受考验。目标的定义不能够流于形式，应该具有以下特征：业务导向、可度量、合理、可行。要

注意目标太夸大会浪费资源，目标

太缩小会影响士气。〔教堂与小屋〕目标通常就是业务需求！

用户需求用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的根底上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户有不同类型：

管理型、事务型信息系统、人

决策层、使用层常用者、偶用者例子：对快到期的客户，系统将通过短信

将续保信息发给该客户的代理人

软件需求从系统实现的角度描述的需求。开发人员〔设计及分析人员〕在业务需求、用户需求的根底上生成的。有时还需要考虑相关联的硬件、环境方面的需求?业务需求?用户需求?软件需求需求定义需求捕获需求分析

功能需求功能需求是需求的主体，是需求的本质功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作功能需求也称为行为需求零散〔需求项〕?整理〔特性、用例、用户故事〕功能需求的要点在于组织!

质量属性产品必须具备的属性或品质McCall体系：运行(正确性、可靠性、效率、

完整性、使用性)、修正(维护性、测试性、

灵活性)、转移(移植性、复用性、共运行性)非功能需求重在有效传递!1)定性?场景?定量2)全局?局部+全局3)零散?可追踪

设计约束也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。例如：必须采用国有自主知识版权的数据库系统…再如：必须运行在UNIX操作系统之下三如：用户将在户外完成作业1)非技术因素决定的技术选型2)预期的软硬件环境3)预期的使用环境

需求的“冰山模型”与应对

需求与需求工程

需求开发与管理

需求开发活动

需求定义的工作内容出发点：问题/时机?工程目标(业务需求)如何破解混沌不清的工程目标?

产物：

?工程型：POS文档?产品型：Vision文档明确工程的范围：

?传统模式：列出功能模块

?合理模式：可行性研究：技术、经济、社会、……?内部溯源?外部寻因列出涉及的人和事

需求定义的时机正常模式：工程立项时

?负责人：由业主/产品经理完成

?问题：现在通常做得不好

?原因：立项结果较空(目标空/范围空)补救模式：工程开工前

?困难：大多数人感到多此一举

?必要性：〔“六拍”工程经理〕

需求获取的误区应收集什么信息：

问题域的描述--业务模型

要求解决的问题列表〔需求〕

用户对解系统的行为或结构施加的任何约束缺乏方案性：随意、走过场，预先没方案缺乏科学性：未从本质入手捕获对象不明确，甚至造成岐义过于迷信现有文档过于迷信“听”到的东西

需求获取技术阅读背景资料头脑风暴讨论分析文档考古面谈〔用户访谈〕联合开发用户调查需求剥离现场观摩情节串联板用例和场景

编写规约“正规”的开发组织都重视，但常“重视过度”

?束之高阁?事后补文档规格说明书的格式与所采用的开发过程、分析方法相关的，不同的方法格式不同

需求验证这个工作大多数组织都不够重视，导致这个工作直到交付系统时才真正被履行，这也就是为什么客户拿到系统后才提出许多这样那样的需求变更，甚至认为整个系统都不是他所需要的提高需求质量的重要手段：

需求评审

需求确认

通过原型来验证需求Review是手段，暴露尽可能

多的错误是目标

需求开发与需求管理的分界

需求管理vs.工程管理需求管理的主题是“需求项”，关乎优先级、尽力满足；工程管理的主题是“工程”，关乎本钱、进度需求管理是工程管理的支撑

?WBS

?优先级

?基线需求管理管理的是工程中的价值维需求管理是工程管理的子集

现代需求理论的关键思想WorkDown?ValueAdd基于系统结构的纵向视角

?基于使用场景的横向视角瀑布模型?迭代、增量RUP的核心思想：用例驱动，架构为中心，迭代、增量的开发过程XP、FDD：迭代、增量的开发过程，用户故事/Feature驱动

需求管理的主要活动基线：救火队?严谨团队变更：不是防止，而是控制。通过统一渠道、统一平台〔并分类〕做到防止错误产生的变更、减少变化产生的变更跟踪：高阶活动，包括用户需求?