需求分析

需求过程

什么是需求过程？

• 需求过程是用来导出、确认和维护系统需求文档的一组结构化活动。
• 通常，一个良好的需求过程应包括下列活动：
  • 需求提取
  • 需求分析和协商
  • 需求确认

需求提取 

• 需求提取是通过与客户、系统用户和其他与系统开发相关的人员交流来发现需求的过程；
• 必须从项目干系人的角度考虑问题，花时间找到他们的真正需求；
• 为提出系统需求，必须理解待解决问题、组织的业务过程、系统可能使用方式、系统的应用领域，以及文档中与系统相关的内容，并与项目相关人员讨论他们需要的系统服务和系统约束。

系统需求的资料来源

• 主要来源是新系统的各种系统相关者，即项目干系人
• 系统的用户。从两个方向来收集资料：
  • 水平方向：物流、人力流、资金流、信息流、单据流、报表流、数据流
  • 垂直方向：业务操作用户、管理用户、主管（决策）用户
• 客户
• 技术人员技术、维护方面的需求
• 从各类系统相关者中识别出关键的人做领域专家
• 其他来源

与客户沟通获取需求的方法： 

• 访谈
• 面向数据流自顶向下求精
• 简易的应用规格说明技术
• 场景分析
• 快速建立软件原型

访谈：

准备问题的原则

• 问题应该是循序渐进的，先一般后细节；
• 所提问题不应该限制用户在回答过程中进行自由发挥。组织问题尽量客观公正；
• 逐步提出的问题在汇总后应能反映应用问题或子问题的全貌，并覆盖用户对目标软件系统或其子系统在功能、行为、性能诸方面的要求。

准备问题：

• 第一组问题（语境无关的问题）
  • 谁是这项工作的最初请求者？
  • 谁将使用该解决方案？
  • 成功的解决方案的经济收益是什么？
  • 存在另一个你需要的解决方案源吗？
• 第二组问题（使分析员能获得对问题更好的理解，并使客户能够表达对解决方案的感觉）
  • 你将如何刻画将由某成功的解决方案产生的“好的”输出？
  • 该解决方案强调了什么问题？
  • 你能向我展示（或描述）解决方案将被使用的环境吗？
  • 存在将影响解决方案的特殊性能问题或约束吗？
• 第三组问题（关注会谈的效率）
  • 你是回答这些问题的合适的人员吗？
  • 我的提问和你想解决的问题相关吗？
  • 我是否问了太多的问题？
  • 还有其他人员可以提供附加信息吗？
  • 还有其他我应该问你的任何问题吗？

面向数据流自顶向下求精：

面向数据流自顶向下求精过程

简易的应用规格说明技术：

FAST: facilitated application specification technique 一种面向团队的需求收集法。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。

• 初步访谈，通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案
• 开发者和用户分别写出“产品需求”，组织会议
• 会议前准备，要求每位与会者在会议前列出对象、服务、约束条件（成本、规模、完成日期）和性能标准（速度、容量）列表
• 是否需要这个新产品？每位与会者把他们在会前准备好的列表展示出来讨论
• 由协调人主持讨论这些列表，目标是，针对每个议题(对象、服务、约束和性能)都创建出一张意见一致的列表
• 一旦得出了意见一致的列表，就把与会者分成更小的小组，每个小组的工作目标是为每张列表中的项目制定小型规格说明，并讨论
• 每个与会者都制定出产品的一整套确认标准，并把自己制定的标准提交会议讨论，以创建出意见一致的确认标准
• 由一名或多名与会者根据会议成果起草完整的软件需求规格说明书

         优点：

使用户与开发者不分彼此，齐心协力

即时讨论并求精

有能导出规格说明的具体步骤

场景分析（use case） ：

一个use case是一个描述软件如何被用于给定情形的场景。

首先标识参与者——角色

然后定义use case

use case回答的问题：

• 该参与者完成的主要任务或功能是什么？
• 该参与者将获取、生产或改变什么系统信息？
• 该参与者是否必须通知系统关于外界环境的变化？
• 该参与者希望从系统获得什么信息？
• 该参与者是否希望被通知未预期的变化？

原型化方法：

原型：向相关人员演示系统提供的功能

需求过程中两个阶段都可能使用原型技术

需求提取阶段的原型：针对难以理解、不好把握的需求

• 原型化使需求的真正含义易于理解；
• 原型化是开发用户接口的唯一有效方式；
• 原型化有助于在投入高开发成本前确定系统的总体可行性和可用性；
• 最终系统有时可以通过向原型添加和修改功能来开发。

三种原型化方法：

• 三种原型化方法：
  • 纸上原型法：定义场景、画出界面
  • Wizard of Oz：由人模拟系统
  • 可执行原型：选择适合开发原型的语言
• 需求提取阶段的原型系统通常不能反映系统性能、效率等方面指标，仅用于发现功能需求。 需求确认阶段的原型：能用于试验的系统原型
  • 确认原型必须比提取原型更完整
  • 检查是否满足客户、用户的实际需要
  • 可用于开发测试用例 
• 废弃型（快速原型）：起解释作用
• 进化型：最终演变为产品
• 原型可能要求投入较高成本，并可能导致延迟交付；
• 不提倡把原型做成最终系统：原型趋向于非结构化，会导致系统灵活性降低、长期成本增加、以至于系统生存期缩短。

需求提取中注意的事项：

• 确定系统的边界
• 从多个角度考察待解决的问题
  • 对确定需求优先级很有帮助：多个角度下都被建议的需求应该具有高优先级。
• 把需求按必要程度分三类：
  • 必须要满足的需求
  • 很想要但对系统目标不是必要的需求
  • 可能满足但也可能取消的需求

需求分析与协商（Analysis & Negotiation）：

发现一系列原始需求之后，应分析它们之间的冲突、重叠、遗漏和不一致。在具备了有效的分析信息之后，项目相关人员就可以协商得到一套认可的系统需求；

需求分析、协商与需求提取是不可分割、互相交错的两个过程；

经常，需求分析中会细化需求定义文档或开发系统模型，通过模型来揭示需求中更深层次的矛盾或不足。

 

项目干系人与需求协商：

• 协商主要是讨论需求冲突，找出每个人都满意的折衷方案；
• 除了逻辑与技术上的问题，组织与行政上的一些考虑也可能左右项目需求，所以必须与各方面项目干系人协商以做出需求决策：  
  • 例如：新系统涉及到权力的丧失或转移 

需求分析原则：

• 操作性原则
  • 必须理解并描述问题的信息域，建立数据模型；
  • 必须定义软件应完成的功能，建立功能模型；
  • 必须描述作为外部事件结果的软件行为，建立行为模型；
  • 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。
• 指导性原则
  • 在你开始建立分析模型前先理解问题
  • 开发使用户能够了解人机交互将如何发生的原型
  • 记录每个需求的起源及原因
  • 使用多个需求视图
  • 给需求赋予优先级
  • 努力删除歧义性

在需求分析中使用需求分类：

• 需求分类是发现需求之间的共性和例外关系的依据。冲突和重叠的需求最有可能发生在同一类需求中。有时某些类似需求可以合并。
• 需求分类可以提高文档跟踪能力。当某类需求变更时，应考虑同一类中其他需求是否受到影响。
• 需求分类可以帮助找到遗漏的需求。在正常分类下某一类里没有需求时，往往意味着遗漏了某些重要需求。

在需求分析中使用问题：

• 每个需求是否和系统/产品的整体目标一致？
• 所有需求是否在合适的抽象层次上被规约？
• 需求是否真的必要或是它表示了一个对系统目标而言可能并不重要的附加特征？
• 是否每个需求被界定并且无歧义？
• 是否每个需求均有归属？
• 任意需求是否和其他需求冲突？
• 是否每个需求均在系统或产品驻留的技术环境中可达？
• 每个需求在实现后是否可测试？

使用交互矩阵发现冲突与重叠：

交互矩阵的各行和各列都对应一项需求，而每一个矩阵元素都用来表示对应的两个需求是否冲突、重叠或者独立； 可使用电子表格来做。行首和列首都标上需求编号或标识符，把每一项需求跟其他所有需求比较，对于需求冲突，填入1，对需求重叠填入1000，对需求独立填入0。最后对行或列求和，每项需求的总和除以1000的余数就是冲突数目，商数就是重叠数目； 大量的冲突和重叠表明，此项需求的任何更改都可能大大影响系统其他部分。

需求分析与协商中注意的事项：

保证需求是可测试的 摒除需求中不确定、不完整、不正确的部分 例如：“要能立刻访问水质的信息”这样表述是不可测试的； 应准确地描述：“要在请求后2秒内找到水质的记录”。 确定每个副词和形容词的定量描述 用特定实体的名称代替代词 要确保在需求文档中定义了每个名词

各种非功能需求规格说明可能使用的度量： 可靠性：出错时间、错误发生率 有效性：交互请求后出错的可能性 性能：每秒处理事务数、用户输入的响应时间 可用性：学习75％的用户功能所需要时间、在给定时间内，由用户引起的错误平均值 健壮性：系统故障后重新启动的时间 完整性：系统出错后，允许的数据丢失的最大限度

需求确认（Requirement Validation）：

需求确认：目标是检查被定义的需求集合，并发现需求中可能存在的问题。最终要确保开发方与客户间没有误解、需求定义与规约间保持一致。 要检查的问题可能包括： 缺乏与质量标准的一致性 由匮乏的词语描述的需求具有不确定性 在分析过程中没有发现的需求冲突

必须明确需求分析和需求确认是不同阶段的任务，尽管它们有共同点： 共同点：它们都要检查系统需求的完整性和一致性； 需求分析所针对的是从有关方面提取的、未被转换过的需求，可能既不完全又不是结构化表达的； 需求确认所针对的是包含全部系统需求的需求文档的最终草案。需求确认是需求文档业已完成，请求获得批准之前的一个检查步骤。

需求过程是从问题空间向求解空间转化的第一步，所以需求确认没有任何东西可依靠，它只能增加双方的信心，但这也是在离开问题空间前确保需求能被相关人员接受的最后机会了； 发现并修复需求问题能节省后期返工的成本； 需求确认要花费一段时间：阅读文档、开评审会、原型试验……请做好思想准备：若不解决需求问题就开始系统开发，准备迎接某种程度的返工。

需求评审：

组织正式的需求评审： 由一组人系统地检查需求、讨论问题的解决方案； 评审组包括双方的人员代表，应由未参与需求过程的人主持； 评审组成员最好具有各自不同方面的技能、知识、经验，以利于问题的发现； 评审是为了发现并解决问题，而不是为了责备任何人。需求中的冲突应在评审中得到解决。

评审的内容：针对前面介绍的需求特性，检查每项需求 审核项目目标； 审核需求与目标相符与否； 系统环境、系统功能、系统的限制等； 对开发过程中或系统运行过程中存在的风险进行评估和记录。讨论和比较各种可选方案，并和客户就使用哪种方案达成一致意见； 随着开发的进行（以及需求改变和增加时），怎样继续检验并确认需求？测试小组怎样测试已经正确实现了所有的需求？谁提供测试数据？

需求过程的总结：