3章 需求分析与系统设计---软件需求.pptVIP

第三章 软件需求 本章学习内容 重视需求的作用 理解软件需求 需求的质量 3.1 重视需求的作用 “还真不能马虎这个胶囊” 3.1.1 需求驱动软件开发过程 通过对各种通用过程模型的了解，可以看出“需求定义与分析”是软件开发过程的“源头”，所有其他活动都必须服务于通过“软件需求”所定义的总体目标。 软件需求代表了项目开始阶段对目标产品的概念认识，作为其他开发活动的“信息输入源”，也是所有项目参与人员开展工作的“基础”。 3.1.2 需求用来干什么 项目经理根据需求制定计划，估算工作量、进度、成本并安排资源。 设计人员根据需求理解“问题”并给出解决方案。 测试人员根据需求制定测试计划并设计测试用例和测试过程。 发布和维护人员根据需求编写使用手册、在线帮助等用户文档。制定培训计划和培训材料。 …… 3.1.3需求的质量决定项目成败 软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”（Leffingwell 1997） 3.2 理解软件需求 3.2.1需求的定义是…… IEEE软件工程标准词汇表（1997）中定义需求为： 用户解决问题或达到目标所需的条件或权能（Capability） 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映前两项所描述的条件或权能的文档 需求的定义还是…… 需求是“用户所需要的并能触发一个系统开发工作的说明” ——Jones 1994 需求是“从系统外部能发现系统所应具有的可以满足于用户的特点、功能及属性等”。 ——需求分析专家Alan Davis 1993 需求关于必须实现什么的规格说明。它描述了系统的行为、特性或属性，也可以是在开发过程中对系统的约束。 ——Sommerville 1997 3.2.2 需求是“想获得的东西” 尽管前面从作用、产品、系统等多个角度对软件需求作出了不一致的定义，但简单的说，“需求”就是对“想获得的东西”的说明。 要完整的理解软件需求，必须回答两个问题？ “谁”想获得？ 想获得什么？ （1）“谁想获得”—需求提供者 软件在它的应用领域内扮演了“业务活动”的“电子化执行者”。因而应用领域中的原有“成员”都会从“利己”的角度对软件提出要求和限制 项目投资者——客户（老板） 真正使用软件的人——用户（直属领导） 限制软件工作方式的其他因素—环境（同志） 运行平台的软、硬件环境 行业规则、政策、法律法规等 …… （2）获得什么——需求内容 不同的需求提供者对于 “要获得什么”有不同的答案 “客户”想获得的是软件对整个应用领域所产生的效益和积极作用 “用户”想获得的是软件在具体工作岗位上提供的服务和服务结果 “环境”想获得的是和一个能和自己“和平共处，肝胆相照”的“新同志”。 所以软件需求是…… 客户对需要解决的业务问题及希望达到的目标的描述。 用户对所要获得的服务、功能和行为的描述 应用环境对软件在开发和使用过程中的特性的约束。 3.2.3 软件需求的层次 例1 总经理甲：“当前俺们企业面临的问题主要是原料采购、库存管理和生产使用的这三个环节的协作不顺利，经常出现采购原料的过度积压或者停工待料的情况，所以希望通过计算机软件建立有关部门的有效协作机制，确保“以销定产、以产定采”，并在一定程度上简化原料管理工作，避免上述情况的发生…… 例2 仓库管理员乙：仓库管理员的职责是管理库存的各种生产原料，因此新系统必须帮助我维护库存信息；并对原料的入库或出库进行登记；再有就是每个月要进行一次盘点，必须得打印一张盘点报表……俺们学问不高，最好软件使用能简单点，打字方便点，俺就会用汉语拼音打字…… 例3——库存管理子系统的需求描述 1、出库登记 使用场景： （1）仓库管理员录入“领料单”中的原料编号，数量，领料人。 （2）系统验证原料编号有效则显示原料名称、存放位置及库存数量，否则提示重新填写并返回（1） （3）若库存数量充足则保存录入信息和领料时间（系统时间），更新该原料的库存数量。否则，不保存任何信息，提示“库存不足”。 （4）出库登记功能执行结束。 要求：全键盘输入，录入领料人时自动切换为ABC输入法 前面三个例子都是不可忽略的软件需求，但是需求信息的概括程度和作用却存在很大的差异 例1：强调了整个软件系统必须达到的战略目标、应用范围和整体约束。是高度概括的，不能被开发人员直接理解和实现。 例2：表达了实际用户出于实际工作对系统的要求，比较具体，可以被理解，但往往“不单纯”，在实现过程中可以分解为“粒度更小”的具体需求 例3：以相对“专业”的方式描述了一个系统必须提供的功能及必须服从的约束，可以直接作为系统中的一个独立部分被实现 三个层次的需求 业务需求 对软件整体的战略