第4章-需求获取-new-new分析.ppt

系统需求概述 需求获取是在问题及其最终解决方案之间架设桥梁的第一步，其实质是理解项目中描述的客户需求。 需求获取是确定和理解不同用户类需要和限制的过程，它描述了用户利用系统需要完成的任务。 需求获取主要涉及到系统分析员，他们同系统用户和所有者一起工作，在系统开发的早期阶段确定对信息系统的业务需求的详细理解。 只有在全面确定了需求之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须进行大量的返工。 如果仅仅将需求分析阶段的工作归结为编写需求规格说明书，这往往导致项目后期层出不穷的问题。 需求获取是一个需要高度合作的活动，只有通过有效的客户—开发者的合作才能成功。作为系统分析员，必须透过客户所提出的表面需求理解他们的真正需求，而不是对客户所说需求的简单誊写。 需求获取影响因素： 客户方 客户不明白他自己需要什么 客户会不断更新所提出的需求 客户与分析员之间缺乏有效沟通 客户缺乏技术上的知识 客户缺乏对软件开发的知识 信息系统开发方 他们习惯使用技术术语，而且在问题理解上与客户有偏差，有时他们以为互相之间完全达成协议，但是在展示最终结果时却发现并非如此 此外，系统开发者往往喜欢将客户的需要改变，以使它们符合一个已存在的系统或模式，而不愿按照客户的需要来开发一个新的系统。 有些情况下，需求分析往往是由程序员而不是系统分析员完成的。由于程序员往往缺乏对实际事物的运行过程和商业过程的理解，从而会导致需求获取存在问题。 ?问题的复杂性 ?交流障碍（讲究技巧和原则） ?不完备性和不一致性 ?需求易变性（动态性） 需求包含三个层次：业务需求、用户需求、功能需求（及非功能需求）。 业务需求反映了组织机构或客户对系统、产品的高层次目标要求，可以在项目视图和范围文档中进行说明。 用户需求文档描述了用户使用产品必须完成的任务，在用例文档或者应用场景中予以说明。 功能需求需求定义了系统必须实现的软件功能，使得用户可以完成他们的任务，从而满足业务需求。 以图书管理系统为例，系统需要提供的基本功能包括：检验用户合法身份；用户注册和登记功能；图书借阅、归还功能；书库管理；读者管理等功能。 非功能需求是指是衡量系统能否良好运行的定性指标。 例如，可靠性、可扩充性、安全性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性 需求获取主要包括以下活动： 发现和分析问题. 了解用户需求。即通过与客户访谈或调研确定一些基本需求信息。 分析用户需求。将客户需求与可能的系统功能或非功能需求相关联。 编写需求文档。使客户需求信息结构化，编写成文档或者示意图。 评审需求文档。选择客户代表评审文档并纠正存在的误解或者错误。 需求管理。主要指需求变更以及需求跟踪。 需求获取过程 发现和分析问题 鱼骨图 了解用户需求。 （1）识别系统用户。了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和工作范围。 （2）用户调研与访谈。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。 （3）访谈结果整理。对于用户提出的每个需求都要知道“为什么”，并判断用户对提出的需求是否有充足的理由；分析由用户需求衍生出的隐含需求，用户没有明确提出来的隐含需求，或者有可能是实现用户需求的前提条件。 （4）访谈结果呈现。需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。 分析用户需求。将客户需求与可能的系统功能或非功能需求相关联。 需求分析包括提炼、分析和仔细审查已经收集到的需求，以确保所有相关方都明白其中含义并找出其中错误、遗漏或不足之处。 并对需求进行修改达成一致意见，使各类关联人员都能够对系统达成共识。 这个过程主要排查以下方面的问题： 是否遗漏了重要的需求； 是否存在矛盾的需求； 是否存在不可行的需求； 是否存在重复的需求； 是否存在模棱两可的需求； 编写需求文档。 需求规格说明的主体由需求陈述构成，主要包含如下内容： 系统应该提供的功能和服务 系统的非功能需求，包括系统的特征、性能、属性等 系统开发或者运行必须遵守的约束条件 系统与其他系统之间的接口 评审需求文档 需求文档完成后，需要经过正式评审才能作为下一阶段工作的基础。 一般的，评审分为用户评审和同行评审两类。 用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的；用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档须重点考虑用户的意见。 同行评审的目的是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。 通过评审的需求文档称为需求基线（