系统分析

软件需求

• 软件需求：是指用户 对系统在功能、行为、性能、设计约束等方面的期望。是指 用户解决问题或达到目标所需的条件或能力，是 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件和能力，以及反映这些条件或能力的文档说明。

• 分为 需求开发和需求管理两大过程

需求获取：从用户那里获取需求

需求分析：从用户那里得到的需求有的是没用的，有的是有用的，有的需求是超过范围的，有的需求是和本项目无关的。并且用户的需求不一定能转换为我们的需求。

需求定义：把分析之后得到的需求转换成程序员能理解的需求，并制定出需求规格说明书，后续所有的操作都围绕需求规格说明书来进行。

需求验证：与客户一起评审 需求规格说明书。

需求分类

将整个软件需求分为三大类，抽象层次依次从高到低：

• 业务需求：反映企业或客户对系统高层次的目标要求，通常来自项目投资人、客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。
• 用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采用用户访谈和问卷调查的方式，对用户使用的场景进行整理，从而建立用户需求。
• 系统需求：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束。
  • 功能需求：也称为行为需求，规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。
  • 非功能需求：指系统必须具备的属性和品质，又可以细分为软件质量属性（如可维护性、可靠性、效率等）和其他非功能需求。
  • 设计约束：也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在 UNIX 操作系统之下等。

质量功能部署

这是另一个角度的分类，从用户的角度划分需求，质量功能部署 （QFD）是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标 QFD 将软件需求分为三类，分别是常规需求、期望需求和意外需求。

1. 常规需求（直接写在需求规格说明书里面的）。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
2. 期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
3. 意外需求：意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性，一般是不需要实现的），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

需求获取

• 需求获取：是一个确定和理解不同的项目干系人的需求和约束的过程。
• 常见的需求获取法包括：
  • 用户访谈：1对 1-3 ，有代表性的用户。其形式包括结构化（结构化：有剧本）和非结构化两种。（提问的人要有较高的水平，且没有办法针对所有的用户，获取的需求可能不全面，但非常有价值、非常精准）
  • 问卷调查：用户多，无法一一访谈。（需求比较杂，不精准）
  • 采样：从种群中系统地选出有代表性的样本集的过程。样本数量 = 0.25*(可信度因子/错误率)^2
  • 情节串联板：一系列图片，通过这些图片来讲故事。
  • 联合需求计划（JRP）：通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。
  • 需求记录技术：任务卡片、场景说明、用户故事、Volere 白卡

需求获取方法可以混合使用。

需求分析

一个好的分析应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

需求分析的任务

1. 绘制系统上下文范围关系图(数据流图)
2. 创建用户界面原型
3. 分析需求的可行性
4. 确定需求的优先级
5. 为需求建立模型
6. 创建数据字典
7. 使用 QFD （质量功能部署）

结构化的需求分析

提示

除了结构化的需求分析，还有面向对象的需求分析。

结构化的特点：自顶向下、逐步分解、面向数据。

三大模型：功能模型（数据流图）、行为模型（状体转换图）、数据模型（E-R 图）以及数据字典。

状态转换图 STD 如下图所示 ， 类似 UML 中的状态图：

• 数据流图描述 数据在系统中如何被传送或变换，以及如何对数据流进行变换的功能或子功能，用于对功能建模，数据流图相关概念如图：

• 数据流图是可以分层的，从顶层（即上下文无关数据流）到 0 层、1 层等。顶层数据流图只含有一个加工处理表示整个管理信息系统，描述了系统的输入和输出，以及和外部实体的数据交互。数据流图示例如下：

  元素	说明	图元
  数据流	由一组固定成分的数据组成，表示数据的流向。每个数据流通常有一个合适的名词，反映数据流的含义。	→
  加工	加工描述了输入数据流到输出数据流之间的变换，也就是输入数据流做了什么处理后变成了输出数据流。（加工就是真正的功能）
  数据存储（文件）	用来表示暂时存储的数据，每个文件都有名字。流向文件的数据流表示写文件，流出的表示读文件。
  外部实体	指存在于软件系统外的人员或组织

提示

E-R 图中的实体是系统内部的实体，这里的实体是系统外部的实体。

需求定义

需求定义（软件需求规格说明书 SRS）：是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS 是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。

需求定义方法

1. 严格定义也称为预先定义，需求的严格定义建立在以下的基本假设之上：所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形（或文字）可以充分体现最终系统。
2. 原型方法，迭代的循环型开发方式，需要注意的问题：并非所有的需求都能在系统开发之前被准确地说明。项目干系人之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。特点：需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应该遵从严格的方法。

需求验证

需求验证：也称为需求确认，目的是与用户一起确认需求无误，对需求规格说明书 SRS 进行评审和测试，包括两个步骤：

1. 需求评审：正式评审和非正式评审。
2. 需求测试：设计概念测试用例（不用写代码，设计一些场景测试需求无误）。

需求验证通过后，要请用户签字确认（一般也不会），作为验收标准之一，此时，这个需求规格说书就是需求基线（已经经过评审确认的需求规格说明书），不可以再随意更新，如果需要更新必须走需求变更流程。

到此为止，需求开发的过程已经完成了。

需求管理

定义需求基线：通过了评审的需求规格说明书就是需求基线，下次如果要变更需求，就需要按照流程一步步进行，需求的流程及状态如下图所示。

需求变更

• 需求变更与风险：主要关心需求变更过程中的需求风险管理，带有风险的做法有：无足够的用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的 SRS、不准确的估算。
• 变更产生的原因：外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。
• 变更控制委员会 CCB：也称为配置控制委员会，其任务是对建议的配置项变更做出评价、审批、以及监督已经批准变更的实施。

需求跟踪

分为双向跟踪，两个层次，如下图所示：

正向跟踪表示用户需求是否都实现了，反向跟踪表示软件实现的是否都是用户要求的，不多不少，可以用原始需求和用例表格（需求跟踪矩阵）来表示：

若原始需求和用户有对应，则在对应栏打对号，若某行都没有对号，表示原始需求未实现，正向跟踪发现问题；若某列都没有对号，表明有多余功能用例，软件实现了多余功能，反向跟踪发现问题。