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