如何做需求分析(论文资料).ppt

第四章 需求分析 目 录 一 软件需求的误区 二 软件需求的定义 三 需求的层次 四 需求风险 五 什么是优秀的需求 六 如何做需求分析 1获取用户需求 2分析用户需求 3编写需求文档 4评审需求文档 5管理需求 七 需求建模的方法 一 软件需求的误区 对大多数人来说，若要建一幢数百万元的房子，会关注什么? 而软件开发，会关注什么? 人们却变得“大大咧咧”起来。 软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” 。 可许多组织采用一些不合规范的方法，导致的后果是一条鸿沟(期望差异)—开发者开发的与用户所想得到的软件存在着巨大期望差异。 二 软件需求的定义 ?IEEE软件工程标准词汇表(1997年)中定义需求为： ????(1)用户解决问题或达到目标所需的条件或权能(Capability)。 ????(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 ????(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。 三需求的层次 ? 三个不同的层次—业务需求、用户需求和功能需求,也包括非功能需求。 业务需求(?business?requirement)反映了组织机构或客户对系统、产品高层次的目标要求，在项目视图与范围文档中予以说明。 用户需求(user?requirement)?文档描述了用户使用产品必须要完成的任务，在使用实例(use?case)文档或方案脚本(scenario)说明中予以说明。 需求的层次 ?功能需求(functional?requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 非功能需求，描述了系统展现给用户的行为和执行的操作等。包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。 最为困难的部分 ?开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。 如果你的用户告诉你需求就是这些了，不要相信他，继续刨根问底，直到你们都筋疲力尽了。 四 需求风险 ??1 用户参与度不够 客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。 原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。(与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求) 。 需求风险 ??2.?用户需求的不断增加 在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围。这使得问题更难解决。 问题根源在于用户需求的改变和开发者对新需求所作的修改。不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。 要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。 需求风险 ?3.?模棱两可的需求 ????模棱两可是需求中最为可怕的问题。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。 模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。 需求风险 ?3.?模棱两可的需求(续) ??? 处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。如果不同的评审者从不同的角度对需求说明给予解释，让每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现，付出的代价太大。 需求风险 ?4.?不必要的特性 ????“画蛇添足”是指开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能。 需求风险 ?5.?过于精简的规格说明 仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果可能会出现开发人员先建立产品的结构之后再完成需求说明。 这种方法可能适合于尖端研究性的产品或需求十分灵活的情况，不过商业应用情况下，这会给开发人员带来挫折(使他们产生不正确的假设前提和极其有限的指导下工作)，也会给客户带来烦恼(他们无法得到他们所设想的产品)。 需求风险 ??6.?忽略了用户分类 系统是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。 如果不能在项目早期对这些主要用户进行分类，必然导致有的用户对产品感到失望。 需求风险 ???7.?不准确的计划 ????对需求分析缺乏理解会导致过分乐观的估计，而