软件工程2需求工程.ppt

软件工程-2-需求工程情景互动v如果要明确用户提出的任务，需要和用户进展沟通，我们应该获得哪些方面的信息？应该如何去做？v产品介绍 产品的用途及意义 产品应用背景v面向用户v功能性需求v非功能性需求需要获得的信息步骤v从用户那里获得信息v整理并分析信息v确认信息一、需求概述v 什么是需求？v 用户解决问题或到达目标所需要的条件或权能；v 系统或系统部件要满足合同、标准、标准或其他正式规定文档所要具有的条件或权能；v 反映上面两条的文档说明。v 需求工程v 指系统分析人员通过细致的调研分析，准确地理解用户的需求，确定客户“需要什么样的软件。将不标准的需求陈述转化为完整的需求定义，再将需求定义写成需求规约的过程。需求工程包含需求开发和需求管理两局部。1. 需求的类型v功能需求和非功能需求v功能需求v描述系统所应提供的功能和效劳，包括系统应该提供的效劳、对输入如何响应及特定条件下系统行为的描述。 v非功能需求v作为功能需求的补充，非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性、响应时间、存储空间等 。非功能性需求的类型v针对不同需求来源的需求分类v领域需求v领域需求的来源不是系统的用户，而是系统应用的领域，反映了该领域的特点。它们主要反映了应用领域的根本问题，如果这些需求得不到满足，系统的正常运转就不可能。领域需求可能是功能需求，也可能是非功能需求，其确定所需的领域知识。它经常采用一种应用领域中的专门语言来描述。v业务需求v反映组织机构或客户对软件高层次的目标要求，这项需求是用户高层领导机构决定的，它确定了系统的目标规模和范围。 用户需求 用户使用该软件要完成的任务 系统需求 容易被无视的要求通常是为了保证整个系统能够正常运行的辅助功能,用户一般不会意识到。v软件需求各组成局部之间的关系需求的演变过程需求的“沙漏2. 需求的演变v 需求演变的三个过程v 第一阶段：“访谈式Visitationv 这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，从宏观上把握用户的具体需求方向和趋势。v 第二阶段：“诱导式Inducementv 这一阶段是在承建方已经了解了具体用户方的具体实际、客观的信息根底上，结合以往的工程经历对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。v 第三阶段：“确认式Afirmv 这一阶段是在上述两个阶段成果的根底上，进展具体的流程细化、数据项确实认阶段。承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。3. 需求工程的主要活动和文档v需求开发活动 需求获取 需求分析 编写需求规格说明书 需求评审用户需求说明书用户需求说明书产品产品( (系统系统) )需求规格说明书需求规格说明书需求评审报告需求评审报告v需求管理活动 需求变更控制 版本控制 需求跟踪 需求状态跟踪需求跟踪报告需求跟踪报告需求变更控制报告需求变更控制报告实行严格的产品控制v 需求开发文档的区别 读者对象客户管理者最终用户系统体系构造工程师承包商管理者客户工程师?用户需求说明书?v需求开发文档的区别 读者对象软件开发人员系统体系构造工程师?需求规格说明书?客户工程师最终用户v需求开发文档的区别v内容v用户需求v是用自然语言加图表的形式给出的关于系统需要提供哪些效劳，以及系统操作受到哪些约束的声明。v软件需求规约(需求规格说明书)v详细地给出系统将要提供的效劳以及系统所受到的约束。软件需求规约文档有时也称为功能描述，应该非常准确，它可能成为系统买方和软件开发者之间合同的主要内容二、需求获取 需求获取requirements elicitation也称为需求收集requirements capture，它是与发现目标系统应该提供的需求相关的活动的统称。1. 需求获取的过程v需求获取的步骤 2.需求调查的主要内容v 环境调查v 包括与开发工程相关的企业的组织构造、规章制度、工艺流程、产品和效劳等。 v 新系统目标的调查v 将系统目标具体化，例如节约本钱的手段，提高业务处理速度的方法等。 v 管理功能和决策方式v 调查了解各级组织的职能和有关人员的工作内容，发现各种现存问题和薄弱环节，及对新系统的功能要求。v业务流程 详细了解各职能部门人员的业务分工情况和各单位人员之间业务关系、作业顺序和管理信息流动等。调查结果用业务流程图表示。 v数据流程 收集各业务及管理岗位使用的账目、报表、单据、文件等数据，弄清这些数据的来龙去脉。 v 需求的其他来源v 编写调研报告-?用户需求说明书?3. 需求获取的方法v会谈 建立联合分析小组 由用户、系统分析员和领域专家构成的需求收集方法 座谈会 由开发组组织用户和相关部门的经理、IT技术人员以及高层管理人员参 加，目的是集中精力、缩短时间、提高搜集信息的效率和准确度；v搜集资料v搜集现有文档、报表等：这是最常用的方法，但必须依靠企业负责人和系统最终用户的帮助，才能获得所需文件； v调查问卷：涉及调查表，对一些共性的问题进展较大范围的调查，但效果不一定好；v场景 系统分析师为每个用户设计一个场景，以提问的方式提取需求。v学徒法 实地观察工作环境，参加业务实践，对理解一些复杂细致的业务流程较为有效； v原型法 由于用户对系统需求的含义不甚了解，因此由系统开发人员为用户提供可以借鉴的模型系统，引导用户提出更加合理的需求。 4. 分析人员与用户的合作关系v了解用户，分清用户的重要性 客户 掏钱买软件的用户 最终用户 最终操作软件的用户 间接用户 既不掏钱买软件，也不使用软件，但它可能对软件产品产生很大影响。 5. 权利和义务v客户合法要求权利v要求分析人员使用符合客户语言习惯的表达；v要求分析人员了解客户的业务及目标；v要求分析人员编写软件需求规约；v要求得到需求工作结果的解释说明；v要求开发人员尊重客户的意见；v要求开发人员对需求及产品实施提供建议，拿出主意；v描述产品易使用的特性；v调整需求，允许重用已有的软件构件；v获得满足客户功能和质量要求的系统。v软件需求获取过程中客户的义务v给分析人员讲解自己的业务；v抽出时间清楚地说明宽完善需求；v准确而详细地说明需求；v及时地做出决定；v尊重开发人员的需求可行性及本钱评估；v划分需求优先级别；v评审需求文档和原型；v需求出现变更要马上联系；v应遵照开发组织处理需求变更的过程；v尊重开发人员采用的需求工程过程。