1、2023-2-7第二章需求工程过程第二章需求工程过程第二章需求工程过程第二章需求工程过程优秀的团队遇到糟糕 的需求需求问题导致的主要后果是返工重复做您认为早已做好的事情。返工的成本占了总开发成本的30%50，而对于返工的情况，70%80%是因需求错误引起的。从图可以看出，在项目末期才发现缺陷，对其进行改正的成本要比在缺陷刚产生不久时修改的成本高得多。第二章需求工程过程镀金问题开发人员为产品添加了一项需求说明中没有提到的功能，他认为“用户肯定会喜欢的”。这就是所谓的“镀金问题(gold plating)”。开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定。要避免
2、镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。第二章需求工程过程过于抽象的需求 营销人员或经理经常喜欢只给出一个粗略的说明，他们希望开发人员在开发过程中充实它。这种方式对研究性项目或需求特别灵活的项目或许管用，但是需要紧密合作的团队，而且仅限于开发小型系统。大多数情况下，这种做法的结果是使开发人员受挫，让客户失望。第二章需求工程过程忽略了某类用户 用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。因此，多数产品都拥有不同的用户群。如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。确定所有用户群后，还要保证获得各类用户的需求。第二章需求工程过程
3、第二部分 需求工程过程需求工程:对问题域及需求做调查研究和描述,设计将满足那些需求的解系统的特性并用文档说明.需求获取 需求分析 规格说明 人机接口 需求验证需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复。第二章需求工程过程需求开发过程需求开发是一个迭代的过程第二章需求工程过程需求工程的推荐方法列出了近50种方法，分别属于7个类型，它们可以帮助大部分项目开发团队更好地完成他们的需求工作。第二章需求工程过程知 识需求管理项目管理 培训需求分析员 对用户代表和管理者进行需求培训 对开发者进行应用领域相关的培训 创建术语表 定义需求变更控制进程 成立变更控制
4、委员会 分析需求变更的影响 控制需求版本并为其建立基线 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求稳定性 使用需求管理工具 创建需求跟踪矩阵 选择合适的开发周期 根据需求制订项目计划 重新协商权利或义务 管理需求风险 跟踪需求耗费的人力物力 回顾以往的教训需求获取需求分析编写规格说明需求验证 定义需求开发过程 定义项目前景和范围 确定用户群 选择用户代言人 建立核心队伍 确定用例 确定系统事件和响应 举行进一步需求获取的讨论 观察用户如何工作 检查问题报告 重用需求 绘制关联图 创建原型 分析可行性 确定需求优先级 为需求建模 创建数据字典 将需求分配至各子系统 应用质量功能调度 采
5、用SRS模板 确定需求来源 惟一标识每项需求 记录业务规范 定义质量属性 审查需求文档 测试需求 确定合格标准第二章需求工程过程知 识 技 能 开发者也应该了解产品应用领域中的基本概念和术语。培训需求分析员 所有将要成为分析员的团队成员都应该接受需求工程方面的基本培训。熟练的需求分析员应具备以下特点：耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工程技术。对用户代表和管理者进行软件需求培训 参与软件开发的用户应该接受一到两天的需求工程方面的培训。对开发人员进行应用领域的相关培训 为了帮助开发人员对应用领域有一个基本的理解，可以安排一个研讨课程，内容是客户的业务
6、活动、术语和产品的目标。创建项目术语表 定义应用领域专业名称的术语表可以减少误解。第二章需求工程过程需求获取需求获取需求获取(requirement elicitation)是需求工程的主体。是需求工程的主体。对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户开发者的合作才能成功。需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。第二章需求工程过程需求获取第1章讨论了需求的三个层次：业务，用户和功能。在项目中
7、它们在不同的时间来自不同的来源，也有着不同的目标和对象，并需以不同的方式编写成文档。业务需求（或产品视图和范围）不应包括用户需求（或使用实例），而所有的功能需求都应该源于用户需求。同时你也需要获取非功能需求，如质量属性。1)确定需求开发过程 确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集需求活动的安排和进度计划更容易进行。2)编写项目视图和范围文档 项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作
8、为评估需求或潜在特性的参考。3)将用户群分类并归纳各自特点 为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客户分成不同组别。他们可能在使用频率、使用特性、优先等级或熟练程度等方面都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。第二章需求工程过程4)选择每类用户的产品代表 5)建立起典型用户的核心队伍 6)让用户代表确定使用实例 从用户代表处收集他们使用软件完成所需任务的描述使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版，在使用实例基础上可得到功能需求。7)召开应用程序开发联系（J A D）会议 应用程序开发联系（J A D）会议是
9、范围广的、简便的专题讨论会（w o r k s h o p），也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践第二章需求工程过程8)分析用户工作流程观察用户执行业务任务的过程9)确定质量属性和其它非功能需求 10)通过检查当前系统的问题报告来进一步完善需求11)跨项目重用需求。调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。想像你自己在学习用户的工作，你需要完成什么任务？你有什么问题？从这一角度来指导需求的开发和利用。还有，探讨例外的情况：什么会妨碍用户顺利完成任务？对系统错误情况
10、的反映，用户是如何想的？询问问题时，以“还有什么能 ”,”当 时，将会发生什么”“你有没有曾经想过 ”,“有没有人曾经 ”为开头。记下每一个需求的来源，这样向下跟踪直到发现特定的客户。第二章需求工程过程需求分析分析:通过对问题域的研究,获得对该领域特性及存在于其中(需要解决)的问题特性的透彻理解并用文档说明.需求分析（requirement analysis）包括提炼、分析和仔细审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析员通过评价来确定是否所有的需求和软件需求规格说明都达到了优秀需求说明的要求。分析的目的在于开发出高质量和具体的需求，这样
11、你就能作出实用的项目估算并可以进行设计、构造和测试.通常，把需求中的一部分用多种形式来描述，如同时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题，这是单一视图无法提供的。分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要。其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。第二章需求工程过程1)绘制系统关联图 这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。2)创建用户接口原型 当开发人员或用户不能确定需求时，开发一个用户接口原型一个可能的局部实现这样使得许多概念和可能发生的事
12、更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。3)分析需求可行性 在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。4)确定需求的优先级别 应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。第二章需求工程过程5)为需求建立模型 需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的
13、信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。6)创建数据字典 数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。7)使用质量功能调配 质量功能调配(Q F D）是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。期望需求；普通需求；兴奋需求.第二章需求工程过程规格说明无论你的需求从何而
14、来，也不管你是怎样得到的，你都必须用一种统一的方式来将它们编写成可视文档。业务需求要写成项目视图和范围文档。用户需求要用一种标准使用实例模板编写成文档。而软件需求规格说明（requirement specification）则包含了软件的功能需求和非功能需求。你必须为每项需求明确建立标准的惯例，并确定在S R S中采用任何惯例，以确保S R S的统一风格，同时读者也会明白怎样解释它。第二章需求工程过程1)采用S R S模板 在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。2)指明需求的来源 为了让所有项目风险承担者明白S R
15、 S中为何提供这些功能需求，要都能追溯每项需求的来源，这可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。3)为每项需求注上标号 制定一种惯例来为S R S中的每项需求提供一个独立的可识别的标号或记号。这种惯例应当很健全，允许增加、删除和修改。作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。4)记录业务规范 业务规范是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。将这些编写成S R S中的一个独立部分，或一独立的业务规范文档。某些业务规范将引出相应的功能需求；当然这些需求也应能追溯相应业务规范。5)创建需
16、求跟踪能力矩阵 建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。在开发过程中建立这个矩阵，而不要等到最后才去补建。第二章需求工程过程人机接口设计人机接口HMI面向人的或其他的系统第二章需求工程过程需求验证验证是为了确保需求说明准确、完整地表达必要的质量特点。而且能够满足客户的需要。审查需求文档 对需求文档进行正式审查是保证软件质量的有效手段之一。测试需求 根据用户需求推导出功能测试用例，以便记录产品在特定条件下应有的行为。定义合格标准 让用户描述决定产品是否满足他们的需求并适合使用的标准。第二章需求工程过
17、程1)审查需求文档2)以需求为依据编写测试用例3)编写用户手册4)确定合格的标准第二章需求工程过程需 求 管 理 有了项目的初步需求，就必须处理好开发过程中不可避免的来自客户、管理层、营销部门、开发团队以及其他群体的变更请求。定义需求变更控制过程 建立一个用于提议、分析和解决需求变更的过程。成立变更控制委员会 可授权由涉众组成的小组作为变更控制委员会(CCB)来接收需求变更的请求。分析需求变更的影响 对影响进行分析有助于CCB做出明智的业务决策。建立基线和控制需求文档的版本 基线是由已经被提交到一个指定版本中的实现(implementation)的需求组成的。第二章需求工程过程需 求 管 理
18、维护需求变更的历史记录 记录需求规格说明变更的日期、变更的内容、变更的实施者和原因。跟踪每项需求的状态 建立一个数据库，为每一项功能需求保存一条记录。衡量需求的稳定性 记录已设为基线的需求数，以及每周提议和批准的需求的变更(增加，修改，删除)数。使用需求管理工具 商业需求管理工具可用于在数据库中存储各种类型的需求。创建需求跟踪矩阵 建立一个表，把每项功能需求和实现它的设计和代码部分、验证它的测试部分联系起来。第二章需求工程过程项 目 管 理 软件项目管理方法和项目的需求过程密切相关。应根据需要实现的需求来规划项目资源、进度和承诺。选择合适的软件开发生命周期 组织应该定义多种开发生命周期，以适应
19、不同的项目类型和不同程度的需求不确定性(McConnell 1996)。根据需求制订项目计划 当范围和详细的需求变得清楚时，应反复斟酌项目的计划和进度表。第二章需求工程过程项 目 管 理 需求变更时重新讨论项目承诺 将新的需求合并到项目中时，应估计一下你是否仍然可以利用可用资源兑现当前的进度和质量承诺。管理与需求相关的风险以及编写风险文档 确定与需求相关的风险并将它们编写成文档是项目风险管理活动的一部分。跟踪需求工程的投入 记录下你的团队在需求开发和管理活动上投入的工作量。从其他项目的需求工程中积累经验 组建一个学术研究组织专门管理项目回顾(也称为项目的审阅)以收集有价值的信息。第二章需求工程过程开始新实践将本章中描述的需求工程方法，按照对大多数项目的相对影响以及实现的相对难度进行分组。2023-2-7第二章需求工程过程
