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