第二章 需求工过程.pptVIP

第二讲 需求工程过程 需求工程: 对问题域及需求做调查研究和描述,设计将满足那些需求的解系统的特性并用文档说明. 需求获取 需求分析 规格说明 人机接口 需求验证 需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复。 迭代模型与瀑布模型的差别 需求开发过程 需求开发是一个迭代的过程 需求工程的推荐方法 列出了近50种方法，分别属于7个类型，它们可以帮助大部分项目开发团队更好地完成他们的需求工作。 知 识 技 能 开发者也应该了解产品应用领域中的基本概念和术语。 培训需求分析员 所有将要成为分析员的团队成员都应该接受需求工程方面的基本培训。 熟练的需求分析员应具备以下特点： 耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工程技术。 对用户代表和管理者进行软件需求培训 参与软件开发的用户应该接受一到两天的需求工程方面的培训。 对开发人员进行应用领域的相关培训 为了帮助开发人员对应用领域有一个基本的理解，可以安排一个研讨课程，内容是客户的业务活动、术语和产品的目标。 创建项目术语表 定义应用领域专业名称的术语表可以减少误解。 需求获取 需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。 需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。 需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。 需求获取 第1章讨论了需求的三个层次：业务，用户和功能。在项目中它们在不同的时间来自不同的来源，也有着不同的目标和对象，并需以不同的方式编写成文档。业务需求（或产品视图和范围）不应包括用户需求（或使用实例），而所有的功能需求都应该源于用户需求。同时你也需要获取非功能需求，如质量属性。 1) 确定需求开发过程 确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集需求活动的安排和进度计划更容易进行。 2) 编写项目视图和范围文档 项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。 3) 将用户群分类并归纳各自特点 为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客户分成不同组别。他们可能在使用频率、使用特性、优先等级或熟练程度等方面都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。 4) 选择每类用户的产品代表 5) 建立起典型用户的核心队伍 6) 让用户代表确定使用实例 从用户代表处收集他们使用软件完成所需任务的描述—使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版，在使用实例基础上可得到功能需求。 7) 召开应用程序开发联系（ J A D）会议 应用程序开发联系（ J A D）会议是范围广的、简便的专题讨论会（ w o r k s h o p），也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践 8) 分析用户工作流程观察用户执行业务任务的过程 9) 确定质量属性和其它非功能需求 10) 通过检查当前系统的问题报告来进一步完善需求 11) 跨项目重用需求。 调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。想像你自己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发和利用。还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映，用户是如何想的？询问问题时，以“还有什么能??” ,”当??时，将会发生什么”“你有没有曾经想过??” ,“有没有人曾经??”为开头。记下每一个需求的来源，这样向下跟踪直到发现特定的客户。 需求分析 分析:通过对问题域的研究,获得对该领域特性及存在于其中(需要解决)的问题特性的透彻理解并用文档说明. 需求分析（ requirement analysis）包括提炼、分析和仔细审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析员通过评价来确定是否所有的需求和软件需求规格说明都达到了优秀需求说明的要求。分析的目的在