愿景分析

愿景分析都应阐明业务需求、描述需求产生的背景和理由等。

上下文图是一种“辅助说明”需求范围（Scope）的方式，它清晰地描述了待开发系统与周围所有事物之间的界限与联系

待研发系统位于上下文图的中心，所有和待研发系统有关联关系的系统、环境和活动围绕在它的周围。但是，上下文图不提供系统内部结构的任何信息。上下文图的目的是通过明确系统相关的外部因素和事件，促进更完整地识别系统需求和约束。

愿景分析，换个角度讲就是我们常说的需求调研（愿景分析的说法重目标，需求调研的说法重活动）

需求分析

IEEE的软件工程标准术语表将需求定义为：

1.用户所需的解决某个问题或达到某个目标所要具备的条件或能力。

2.系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。

3.上述第一项或第二项中定义的条件和能力的文档表述。

RUP是这样定义需求的：需求描述了系统必须满足的情况或提供的能力，它就可以是直接来自客户需要，也可以来自合同、标准、规范或其他有正规约束力的文档（Arequirement describes a condition or either derived directly from userneeds, or stated in a contract, standard, specification, or other formallyimposed document.）。

需求捕获vs.需求分析vs.系统分析

从软件过程全局看，需求分析是一个承上启下的阶段——“上承”愿景，“下接”设计。上游，进行愿景分析、研究可行性、输出《愿景与范围文档》，需求分析要进一步完善和细化软件需求。后续，要进行的设计活动，以需求分析活动定义的功能需求、质量属性需求以及约束性需求等为基本参考。

1. 需求捕获

需求捕获是获取知识的过程，知识从无到有、从少到多。需求采集者必须理解用户所从事的工作，并且了解用户和客户希望软件系统在哪些方面帮助他们。

典型的需求捕获的工作成果是一摞“需求采集卡”（如表5-1所示），其中记录了需求类型、需求描述、需求背景、需求提出者和需求记录者等对进一步的需求分析非常有用的信息。

2. 需求分析

需求分析是挖掘和整理知识的过程，它在已掌握知识的基础上进行。毕竟，初步捕获到的需求信息往往处于不同层次，也有一些主观甚至不正确的信息。而经过必要的需求分析工作之后，需求会更加系统、更加有条理、更加全面。

需求分析则对采集到的原始需求进行分析、整理、辨别和归纳，最终形成系统的、明确的软件需求。

需求分析应交付一份明确的、规范的需求定义——《软件需求规格说明书》（Software Requirements Specification，SRS）。《SRS》精确地阐述了一个软件系统必须提供的功能、必须达到的质量属性指标，以及它必须遵守的约束。

3. 系统分析

系统分析是针对系统所要面临的问题，搜集相关的资料，以了解产生问题的原因所在，进而提出解决问题的方法与可行的逻辑方案，以满足系统的需求，实现预定的目标。

对于不同的系统分析方法，其工作成果差异很大。通过结构化分析方法得到的最重要的工作成果是数据流图，而面向对象的系统分析方法得到的工作成果主要是分析类图、鲁棒图、序列图等——其中分析类图描述设计的静态方面，而鲁棒图和序列图描述设计的动态方面。

【问题1】将需求捕获和需求分析视为两个阶段，这是错误的

将需求捕获和需求分析视为两个阶段，这是错误的。世界不是“问题—解决方案”这么简单的模型，是“问题—解决方案—衍生问题—解决方案—……”才现实——上一级的解决方案对下一级就意味着“待解决的问题”。于是，需求分析连带出更多系统分析的工作非常正常。这种“捕获得到全部需求，之后再集中进行分析”的做法不务实、效果差、容易引起大量需求变更。

【问题2】需求分析与系统分析混淆

需求分析，是搞清楚系统“做什么”。需求分析是软件工程学中的经典的术语之一，名副其实的含义应是对用户需求进行分析，旨在产生一份明确、规范的需求定义。从这个意义上讲，“分析是解决做什么而不是解决怎么做的问题”是无可挑剔的。

系统分析，关注系统“怎么做”。更直白地说，系统分析 ≈ 初步的高层设计。

在“做什么”和“怎么做”的问题上为什么会出现上述矛盾？究其根源，在于人们对软件工程中“分析”这个术语的含义有着不同的理解——有时把它作为需求分析（Requirements Analysis）的简称，有时是指系统分析（SystemsAnalysis），有时则作为需求分析和系统分析的总称。

但迄今为止人们所提出的各种分析方法（包括结构化分析和面向对象分析）中，真正属于需求分析的内容所占的分量并不太大；更多的内容是给出一种系统建模方法（包括一种表示法和相应的建模过程指导），告诉分析员如何建立一个能够满足（由需求定义所描述的）用户需求的系统模型。分析员大量的工作是对系统的应用领域进行调查和研究并抽象地表示这个系统。确切地讲，这些工作应该叫做系统分析，而不是需求分析。它既是对“做什么”问题的进一步明确，也在相当程度上涉及“怎么做”的问题。

需求的全面性

观念是行为的“向导”，有怎样的观念存在，就有怎样的行为方式产生

二维需求观与ADMEMS矩阵（需求层次-需求方面矩阵）

需求层次

1. 组织级需求。包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。·

2. 用户级需求。用户使用系统来辅助完成哪些工作，对质量有何要求，用户群及所处的使用环境方面有何特殊要求 

3. 开发级需求。开发人员需要实现什么，开发期间、维护期间有何质量考虑，开发团队的哪些情况会反过来影响架构

从不同方面考虑需求

功能需求：更多体现各级直接目标要求。

质量属性：运行期质量 + 开发期质量。·

约束需求：业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素。

需求层次-需求方面矩阵

功能

功能需求是我们最熟悉的一类需求，它描述系统“应该做什么”。

质量

鲁棒性（Robustness）。鲁棒性也称健壮性、容错性。鲁棒性是指软件系统在以下情况下仍能够正常运行的能力：用户进行了非法操作；相连的软硬件系统发生了故障，以及其他非正常情况

约束

约束需求 = 业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素。

从需求向设计转化