软件需求分析

引言

需求分析之前的准备活动有哪些？
为何要进行软件的需求分析？
软件的需求分析处于软件生命周期的哪个阶段？起到什么作用？
怎样才能做好软件需求分析？
软件需求分析的过程和步骤是什么？
软件需求分析的最终结果是什么？

需求分析之前的活动

软件的系统分析

• 预研（Pre-study）:主要探索软件项目的目标、市场预期、主要的技术指标等，用于帮助决策者做出是否进行软件项目立项的决定。
• 可行性分析（Feasibility-study）:针对项目的目标和范围进行概要的分析和研究，探索问题域中的核心问题及其相应的解决方案，进一步为决策者提供经济、技术甚至是法律上可行性的分析报告。

需求的定义

• 需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，详细地说明产品“必须或应当”做什么 。
• Boehm 的需求定义：研究一种无二义性的表达工具，它能为用户和软件人员双方都接受，并能够把“需求”严格地、形式地表达出来。
• “需求、设计、编程、测试四者究竟哪个环节最重要？”
  • 首先，每个环节都是很重要，任何一个环节出现问题，都会导致软件的质量问题。
  • 但是，从管理的角度来看，需求是软件产品的起源，也是检验软件是否合格的标准，因此。。

需求理解过程

需求分析的必要性

需求分析是一项必须的软件工程活动。它在系统需求分析和软件设计之间起到桥梁的作用：

• 它使得软件开发人员在系统分析的基础上深入描述软件的功能和性能、指明软件和其他系统元素的接口，建立软件必须满足的约束条件。
• 它允许软件开发人员对关键问题进行细化，并构建相应的分析模型：数据、功能和行为模型。
• 分析模型成为设计模型的基础，需求规格说明书也为软件测试人员和用户提供了软件质量评估的依据。
• 它能准确表达用户对系统的各项要求。

需求分析的对象、任务和目标

• 软件需求分析的对象：用户要求。
• 软件需求分析的任务是：准确地定义新系统的目标，回答系统必须“做什么”的问题并编制需求规格说明书。
• 需求分析的目标：借助于当前（业务）系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。

需求分析的原则

需求分析一组操作性原则是：

• 问题的信息域必须被表示和理解。
• 软件将完成的功能必须被定义。
• 软件的行为（作为外部事件的结果，或者理解为功能存在的理由）必须被表示。

需求分析的工程化原则：

• 首先要正确地理解问题，再建立分析模型。
• 记录每个需求的起源及原因，保证需求的可回溯性。
• 开发一个人机交互过程的原型。
• 给需求赋予优先级：紧张的开发时间要求尽量避免一次性实现每个软件需求，应采用迭代增量的开发模型。
• 努力删除歧义性：因为大多数需求以自然语言描述，存在歧义性的可能性，正式的技术评审是发现并删除歧义性的一种有效方法。

数据、功能及行为建模

数据模型：

• 信息内容和关系；信息流；信息结构。

功能模型：对进入软件的信息和数据进行变换和处理的模块，它必须至少完成三个常见功能：

• 输入、处理和输出。

行为模型：大多数软件对来自外界的事件做出反应，这种刺激／反应特征形成了行为模型的基础。行为模型创建了软件状态的表示，以及导致软件状态变化的事件的表示。

需求工程

软件的需求分析是一系列复杂的软件工程活动，为了便于对需求进行更好的管理，人们把所有与需求直接相关的活动通称为需求工程。

需求获取

• 需求获取的目的是清楚地理解所要解决的问题，完整地获得用户的需求。并提出这些需求实现条件，以及需求应达到的标准。
• 需求获取的对象
  用户：使用软件的人员
  客户：购买软件的人员
• 需求获取的难点
  用户无法清楚地表达需求
  需求的理解问题
  用户经常变更需求

需求获取流程

目的	获取用户（客户与最终用户）的需求信息，经过分析后产生《用户需求说明书》。
角色与职责	需求分析员调查、分析用户的需求，客户与最终用户提供必要的需求信息。
启动准则	需求分析员已经确定
输入	任何与用户需求相关的材料
主要步骤	第一步：准备调查 第二步：调查与记录 第三步：分析需求信息 第四步：撰写《用户需求说明书》 第五步：需求确认
输出	《用户需求说明书》
结束准则	需求分析员已经撰写完成《用户需求说明书》，确保无拼写、排版等错误。并确保《用户需求说明书》的内容无二义性，且涵盖了所有的用户需求。
度量	需求分析员统计工作量和上述文档的规模，汇报给项目经理。

需求获取的准备

• 需求获取的准备工作围绕三项展开：

  • 调查什么？明确访谈主题。
    通过什么方式去调查？面谈、会议交流、电话或邮件。
    “何人”在“何时”调查？ 访谈对象及时间。

• 首先，应起草需求调查问题表，将重点锁定在该问题表内，否则调查工作将变得漫无边际。

• 其次，应当确定需求调查的方式，比如：

  • 与用户交谈，向用户提问题。
  • 参观用户的工作流程，观察用户的操作。
  • 向用户群体发调查问卷。
  • 与同行、专家交谈，听取他们的意见。

需求获取的记录

准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息，建议采用表格的形式，如下图：

需求标题
调查方式
调查人
调查对象
时间、地点
需求信息记录	基本要素如“是什么”、“为什么”等

撰写用户需求说明书

• 最后对收集到的所有需求信息进行分析，消除错误，归纳与总结共性的用户需求。
• 然后按照规定的文档模板（可自行定义）撰写《用户需求说明书》，调查过程中获取的需求信息可以作为《用户需求说明书》的附件。
• 之后应当邀请同行专家和用户一起评审《用户需求说明书》，尽最大努力使《用户需求说明书》能够正确无误地反映用户的真实意愿。
• 思考：什么角色负责撰写？

用户需求说明书与软件需求规格说明书的区别

• 前者主要采用自然语言来表达用户需求，其内容相对于后者而言比较粗略，不够详细。
• 后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，软件需求是软件系统设计的直接依据。
• 两者之间可能并不存在一一影射关系
  • 因为软件开发商会根据产品发展战略、企业当前状况适当地调整软件需求，例如用户需求可能被分配到软件的数个版本中；
  • 也存在由于技术条件的限制，删减一些无法实现的、成本太高的需求；
  • 也存在提供更先进的技术来丰富软件需求；
  • 最后，软件开发人员应当依据《软件需求规格说明书》来开发当前产品。

需求类别

• 功能需求：列举出所开发软件在功能上应做什么，这是最主要的需求。
• 性能需求：给出所开发软件的技术性能指标，尤其是系统的实时性和其他时间要求，如响应时间、处理时间、消息传送时间等；资源配置要求，精确度，数据处理量等要求。
• 环境需求：是对软件系统运行时所处环境的要求。
  • 在硬件方面，采用什么机型、有什么外部设备、数据通信接口等等。
  • 在软件方面，采用什么支持系统运行的系统软件（指操作系统、数据库管理系统等）。
  • 在使用方面，需要使用部门在制度上、操作人员的技术水平上应具备什么样的条件等等。

其他需求类别

• 可靠性需求：指软件的有效性和数据完整性。各种软件在运行时失效的影响各不相同。在需求分桥时，应对所开发软件在投入运行后不发生故障的概率，按实际的运行环境提出要求。
• 安全保密要求：工作在不同环境的软件对其安全、保密的要求显然是不同的，应当把这方面的需求恰当地做出规定。
• 用户界面需求：软件与用户界面的友好性是用户能够方便有效愉快地使用该软件的关键之一。
• 资源使用需求：指所开发软件运行时所需的数据、软件、内存空间等各项资源，以及软件开发时所需的人力、支撑软件、开发设备等。
• 软件成本消耗与开发进度需求：在软件项目立项后，要根据合同规定，对软件开发的进度和各步骤的费用提出要求，作为开发管理的依据。
• 预先估计以后系统可能达到的目标：在开发过程中，可对系统将来可能的扩充与修改做准备。一旦需要时，就比较容易进行补充和修改。

需求的分析与综合

• 需求获取之后就需要对比较复杂的需求进行建模分析，进而逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，分析它们是否满足功能要求，是否合理。
• 依据功能需求，性能需求，运行环境需求等，剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。
• 分析和综合工作需要反复地进行，其过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的需求规格说明为止。

需求的定义

目的	定义准确无误的软件产品需求，产生《软件需求规格说明书》。
角色与职责	需求分析员定义软件需求。客户与最终用户确认软件需求。
启动准则	《用户需求说明书》已经撰写完成。
输入	《用户需求说明书》
主要步骤	第一步：细化并分析用户需求 第二步：撰写软件需求规格说明书 第三步：软件需求确认
输出	《软件需求规格说明书》
结束准则	《软件需求规格说明书》已经撰写完成。开发方和客户方已经对产品需求进行了确认。
度量	需求分析员统计工作量和上述文档的规模，汇报给项目经理。

需求建模

• 软件开发人员还需要构造系统的分析模型，着重于描述系统必须做什么、而不是如何去做系统。
• 给出系统的逻辑视图，以及系统的物理视图。
  • 逻辑模型给出软件要达到的功能和处理数据之间的关系，而不是实现的细节。
  • 物理模型给出处理功能和数据结构的实际表示形式，这往往是由设备决定的。
• 常用的建模分析方法有：
  • 面向数据流的结构化分析方法（简称SA）
  • 面向数据结构的Jackson方法（简称JSD）
  • 面向对象的分析方法（简称OOA）等
  • 以及用于建立动态模型的状态迁移图或Petri网等

编制需求分析文档

• 通常把描述需求的文档叫做软件需求规格说明书。
• 同时，为了确切表达用户对软件的输入输出要求，还需要制定数据词典及编写初步的用户手册，着重反映被开发软件的用户界面和用户使用的具体要求。

需求确认和评审

• 需求规格说明书须提交给项目组及相应的管理机构，进行内部评审
  • 检查使用的符号是否标准和规范；
  • 检查所描述的需求是否完整或者有疏漏；
• 内部评审后还需与客户进行确认，当客户表示满意后再进行后续的软件开发活动
  • 一次性满意；
  • 部分或阶段满意；
• 将确定的部分留存并固定版本。

总结

需求是复杂的；
需求分析是必须的；
需求必须从三个方面描述；
需求分析后必须以规范的方式进行描述，形成需求规格说明书；
需求最终必须被客户认可；