如何做需求分析.ppt

《如何做需求分析.ppt》由会员分享，可在线阅读，更多相关《如何做需求分析.ppt（38页珍藏版）》请在三一文库上搜索。

1、第四章 需求分析,目 录,一 软件需求的误区 二 软件需求的定义 三 需求的层次 四 需求风险 五 什么是优秀的需求 六 如何做需求分析 1获取用户需求 2分析用户需求 3编写需求文档 4评审需求文档 5管理需求 七 需求建模的方法,一 软件需求的误区,对大多数人来说，若要建一幢数百万元的房子，会关注什么? 而软件开发，会关注什么? 人们却变得“大大咧咧”起来。 软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” 。 可许多组织采用一些不合规范的方法，导致的后果是一条鸿沟(期望差异)开发者开发的与用户所想得到的软件存在着巨大期望差异。,二 软件需求的定义,IEEE软件工程标

2、准词汇表(1997年)中定义需求为： (1)用户解决问题或达到目标所需的条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 (3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。,三需求的层次,三个不同的层次业务需求、用户需求和功能需求,也包括非功能需求。 业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，在项目视图与范围文档中予以说明。 用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，在使用实例(use case)文档或方案

3、脚本(scenario)说明中予以说明。,需求的层次,功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 非功能需求，描述了系统展现给用户的行为和执行的操作等。包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。,最为困难的部分,开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。 如果你的用户告诉你需求就是这些了，不要相信他，继续刨根问底，直到你们都筋疲力尽了。,四 需求风

4、险,1 用户参与度不够 客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。 原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。(与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求) 。,需求风险,2. 用户需求的不断增加 在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围。这使得问题更难解决。 问题根源在于用户需求的改变和开发者对新需求所作的修改。不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。 要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目

5、标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。,需求风险,3. 模棱两可的需求 模棱两可是需求中最为可怕的问题。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。 模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。,需求风险,3. 模棱两可的需求(续) 处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。如果不同的评审者从不同的角度对需求说明给予解释，让每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被

6、发现，付出的代价太大。,需求风险,4. 不必要的特性 “画蛇添足”是指开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能。,需求风险,5. 过于精简的规格说明 仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果可能会出现开发人员先建立产品的结构之后再完成需求说明。 这种方法可能适合于尖端研究性的产品或需求十分灵活的情况，不过商业应用情况下，这会给开发人员带来挫折(使他们产生不正确的假设前提和极其有限的指导下工作)，也会给客户带来烦恼(他们无法得到他们所设想的产品)。,需求风险,6. 忽略了用户分类 系统是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教

7、育程度和经验水平也不尽相同。 如果不能在项目早期对这些主要用户进行分类，必然导致有的用户对产品感到失望。,需求风险,7. 不准确的计划 对需求分析缺乏理解会导致过分乐观的估计，而当发生超支、超时时，会带来颇多麻烦。成本估计极不准确的原因主要有五点：频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析。,风险承担者,风险承担者包括客户、用户、业务或需求分析员、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。,五. 什么是优秀的需求,软件需求过程的标准是：清楚(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable

8、)，此外还有其他的概念，如可跟踪的、可修改的等等。,什么是优秀的需求,1.清楚： 需求分析采用的是自然语言。 自然语言对需求分析最大的弊病是什么? 二义性。所以不得不对需求分析中采用的语言做某些限制. 例如:尽量采用主语动作的简单表达方式。 需求分析中的描述让人看上去像是刚学习写作的小孩子，不要采用疑问句、修饰这些华丽的表达方式。,什么是优秀的需求,除了语言的二义性之外，不要使用行话，就是计算机术语。 需求分析最重要的是和用户沟通，用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。,什么是优秀的需求,需求描述的例子： 如果要做一个银行的信用卡系统，如何描述需求

9、？ 这样描述需求： 银行卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。,什么是优秀的需求,2. 完整： 需求的完整性是非常重要的，若遗漏需求而不得不返工(是恶梦)。而需求的遗漏是经常发生的，不仅仅是你的问题，更多的问题发生在用户那里，他们不知道该做些什么。 要做到需求的完整性是很艰难的一件事情，涉及到需求分析过程的各各方面，贯穿了整个过程，从最初的计划制定到最后的需求评审。,什么是优秀的需求,3.一致： 需求是有层次的，一致性就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统

10、不会偏离最初的实现目标。,什么是优秀的需求,4.可测试： 一个项目的测试从什么时候开始？ 有人说从编码完成后开始。 更清楚一点的说是编码的时候同时进行单元测试，编码完成后进行系统测试。 实际上测试是从需求分析过程就开始了： 需求分析是测试计划的输入和参照。只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。,六 怎样做需求分析,形成软件需求 步骤： 1获取用户需求 2分析用户需求 3编写需求文档 4评审需求文档 5管理需求。,图1 获取用户需求的活动,怎样做需求分析,1 获取用户需求 该阶段是最重要的，任务： 先了解客户方的所有用户类型以及潜在的类型。然

11、后，根据他们的要求来确定系统的整体目标和系统的工作范围。 对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。,怎样做需求分析,2 用户需求的分析和整理： 几条常见的准则： 对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由； 。 将以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”； 分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求，这一点往往容易被忽略，经常会因为对

12、隐含需求考虑得不充分而引起需求变更。,怎样做需求分析,2 用户需求的分析和整理（续）： 根据大家共同确认需求，分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行的活动： 明确标识出待确定的需求项（在需求分析初期往往有很多这样的待定项）； 使需求符合系统的整体目标； 保证需求项之间的一致性，解决需求项之间可能存在的冲突。,分析用户需求,2 用户需求的分析和整理（续）： 分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。 用户需求

13、的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。,分析用户需求,分析用户需求执行的活动： 以图形表示的方式描述系统的整体结构，包括系统的边界与接口； 通过原型、网页或其它方式向用户提供可视化的界面，用户可以对需求做出自己的评价； 系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等； 以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。,需求建模的方法,需求建模的常用方法： 数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。 DFD作为结构化系统分析与设计的主要

14、方法；DFD适用于MIS系统的表述。DFD使用四种基本元素来描述系统的行为（过程、实体、数据流和数据存储）。DFD方法直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型，但是从DFD图中无法判断活动的时序关系。,用于需求建模的方法,ERD方法用于描述系统实体间的对应关系，需求分析阶段使用ERD描述系统中实体的逻辑关系，在设计阶段则使用ERD描述物理表之间的关系。需求分析阶段使用ERD来描述现实世界中的对象。ERD只关注系统中数据间的关系，而缺乏对系统功能的描述。如果将ERD与DFD两种方法相结合，则可以更准确地描述系统的需求。,用于需求建模的方法,Use Case面向对象分析的方法：使用U

15、se Case来获取软件的需求。Use Case通过描述“系统”和“活动者”之间的交互来描述系统的行为。通过分解系统目标，Use Case描述活动者为了实现这些目标而执行的所有步骤。 Use Case方法最主要的优点，在于它是用户导向的，用户可以根据自己所对应的Use Case来不断细化自己的需求。此外，使用Use Case还可以方便地得到系统功能的测试用例。,3、编写需求文档,需求文档描述方式:可以使用自然语言或形式化语言来描述，还可以添加图形的表述方式和模型表征的方式。 需求文档包括:用户的所有需求（功能性需求和非功能性需求）。 编写需求文档的工具：软件开发工具，其中的信息库作用较大。,4

16、、 评审需求文档,需求文档完成后，需要经过正式评审。一般的评审分为用户评审和同行评审两类。 用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的； 用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档时用户的意见是第一位的。 而同行评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。,5、管理需求,需求的变更如何以可控的方式管理软件的需求，有利于项目的顺利。 需求管理要保证需求分析各个活动都得到了充分的执行。 需求变更的管理，则主要使用需求变更流程和需求跟踪矩阵的管理方式。需求变更流程和需求跟踪矩阵分别如图2和图3所示。,5、管理需求,图2 需求变更流程。,5、管理需求,图3 需求跟踪矩阵,七 采用哪种方式做需求分析最好？,不同的需求分析有不同的特点。还没有哪一种方法可以完全替代别的方法. 做需求分析的目的是为了建立需求的模型，不同的子系统有可能使用不同的建模方法 一般来说，可以使用DFDERD来描述那些功能层次比较清晰的需求；而USE CASE则适于描述功能结构复杂的需求。,