需求分析(zhhf09).pptVIP

第三章（第四至六讲） 软件需求分析 本章的主要内容 一、需求的相关概念 系统责任与系统边界 系统责任指所开发的系统应该具备的职能。 目标系统与外部实体（与系统打交道的人或物）之间应具有明确的边界。 软件需求（Requirements) 需求是指用户或者客户对要开发的软件系统的要求。需求的内容在“问题定义”中得到最抽象的描述（可能是招标文件）。 需求是关于系统将要完成什么(what)工作的描述,必须经过所有涉众(stakeholder)的认可,其目的是彻底解决客户所期望解决的问题。 IEEE的需求定义 用户为解决某个问题或达到某个目标而需具备的条件或能力。 系统或系统组件为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力。 上述第一项或第二项中定义的条件和能力的文档表达。 —— IEEE的软件工程标准术语表（1990） Sommerville的需求定义 对应该实现什么功能的说明； 可以是系统运行方式或系统特征与属性的描述； 可能是对系统开发过程的约束。 —— Sommerville，Sawyer（1997） 软件需求的类型 功能需求 系统可以完成的所有事情 涉及与本系统有接口的其他系统的所有事情 非功能需求 软件开发过程中必须遵守的约束（Constraint)。是对可以使用的资源和软件质量的各个方面的限制，往往会影响软件工程师做决策的自由度。 非功能需求应是可验证的（Verifiable)。 需求分析(Requirements Analysis) 指开发人员为了准确地理解和表达用户要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的形式功能规约的过程。 Requirements analysis results in the specification of software’s operational characteristics；indicates software’s interface with other system elements; and establishes constraints that software must meet. 需求分析越来越难 问题域的复杂性越来越高。 交流障碍。(涉众的文化背景不同；自然语言的多义性，一语双关等）。 完整性问题。（用户对问题的陈述往往是不完备的；用户意见不统一，需求之间可能存在着矛盾；涉及许多细节） 需求易变性。（需求永远不会稳定，往往存在错误的需求） 应该足够重视需求分析 有关软件错误和需求分析的一组事实 在软件生命周期中，一个错误发现得越晚，修复的费用也越高。 许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来。 在需求过程中会产生很多错误和误解，人与人之间的“通信”障碍无法避免。 需求阶段代表性的错误：疏忽、不一致、二义性。 需求错误是可以被检查和审查出来的。 对项目需求状况作出快速评估（1） 项目前景（vision)和范围(scope)未曾明确定义 客户太忙，没时间与需求分析和开发人员一起讨论需求 用户代理（如开发经理、用户负责人、营销人员等）自诩可以代表用户，其实不能准确说出用户的要求 需求只存在于那些所谓专家的脑子里，没有被记录下来 对项目需求状况作出快速评估（2） 客户坚持所有需求都很重要，不愿排出它们的优先次序 开发人员在编码过程中发现需求有歧义，缺少足够的信息，只能去猜测 开发人员与客户沟通时只关心用户界面，忽略了用户需要用软件做什么 客户签字确认了需求却又一直提出修改要求 对项目需求状况作出快速评估（3） 项目范围因接受需求变更而扩大，却没有相应地增加投入或剪裁功能，进度因而被延误 需求变更的请求被弄丢，开发人员和客户都不了解所有变更请求的状态 开发人员按照客户要求实现的功能无人问津 需求规格说明中的要求都实现了客户却不满意 领域分析（Domain Analysis) 整个软件项目的涉众（stake holder） 客户（Customer） 用户（User） 需求分析员 开发人员 测试人员 项目经理：负责制定项目计划保证和项目顺利进行 法律人员：确保产品符合所有相关法规 市场营销、技术支持人员 与产品和客户打交道的其他人员 需求分析的涉众 合同监督人员，提出里程碑（Milestones）和约束系统开发进度的计划 需求者：客户(Customer)和使用者(User)。 开发者 项目管理者，必须理解建立和使用目标系统所可能产生的后果。 系统分析员，分析阶段活动的主体。 设计员，依据需求提出可接受的解决方案。 测试员，确保软件系统满足每一需求。 系统分析员应具有的素质 综合能力 总体规划，抽象和分解，本质确认的能力 过程能力 保证整个过程的善始善终的能力 交流能力