第2章需求工程过程.pptVIP

第二讲 需求工程过程;迭代模型与瀑布模型的差别 ;需求开发过程;需求工程的推荐方法;;知 识 技 能;需求获取;需求获取;4) 选择每类用户的产品代表 5) 建立起典型用户的核心队伍 6) 让用户代表确定使用实例 从用户代表处收集他们使用软件完成所需任务的描述—使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版，在使用实例基础上可得到功能需求。 7) 召开应用程序开发联系（ J A D）会议 应用程序开发联系（ J A D）会议是范围广的、简便的专题讨论会（ w o r k s h o p），也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践 ;8) 分析用户工作流程观察用户执行业务任务的过程 9) 确定质量属性和其它非功能需求 10) 通过检查当前系统的问题报告来进一步完善需求 11) 跨项目重用需求。 调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。想像你自己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发和利用。还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况的反映，用户是如何想的？询问问题时，以“还有什么能??” ,”当??时，将会发生什么”“你有没有曾经想过??” ,“有没有人曾经??”为开头。记下每一个需求的来源，这样向下跟踪直到发现特定的客户。;需求分析;1)绘制系统关联图 这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。 2) 创建用户接口原型 当开发人员或用户不能确定需求时，开发一个用户接口原型—一个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。 3) 分析需求可行性 在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风???，包括与其它需求的冲突，对外界因素的依赖和技术障碍。 4) 确定需求的优先级别 应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。;5) 为需求建立模型 需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。 6) 创建数据字典 数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。 7) 使用质量功能调配 质量功能调配( Q F D）是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。 期望需求；普通需求；兴奋需求. ;规格说明;1)采用S R S模板 在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。 2) 指明需求的来源 为了让所有项目风险承担者明白S R S中为何提供这些功能需求，要都能追溯每项需求的来源，这可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。 3) 为每项需求注上标号 制定一种惯例来为S R S中的每项需求提供一个独立的可识别的标号或记号。这种惯例应当很健全，允许增加、删除和修改。作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。 4) 记录业务规范 业务规范是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。将这些编写成S R S中的一个独立部分，或一独立的业务规范文档。某些业务规范将引出相应的功能需求；当然这些需求也应能追溯相应业务规范。 5) 创建需求跟踪能力矩阵 建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。在开发过程中建立这个矩阵，而不要等到最后才去补建。;人机接口设计;需求验证;