一、需求的作用

需求是解决问题的前提。

其中标注为软件系统工程的一些活动，是作为系统工程工作的一部分被实施的。

Q：什么样的陈述可以被称为需求?
1.这个需求是否有必要？–>必要的（Necessary）
2.会不会产生歧义？–>无歧义（Unambiguous）
3.能不能测试？–>可测试（Testable）
4.能不能跟踪？–>可跟踪（Trackable）
5.能不能测量？–>可测量（Measurable）

二、需求分类

需求分为功能性需求；性能需求；外部接口需求；设计约束需求；质量属性需求。

功能需求是整个需求的主体，即没有功能需求，就没有非功能需求，即性能需求、外部接口需求、设计约束和质量属性。

非功能需求对功能需求而言，可以是一对多的，例如：

三、需求发现——怎么提需求？

常用的发现初始需求的技术，包括：

3.1自悟（Introspection）

需求人员把自己作为系统的最终用户，审视该系统并提出问题：“如果是我使用这一系统，则我需要……”

3.2 交谈

为了确定系统应该提供的功能，需求人员通过提出问题，用户回答，直接询问用户想要的是一个什么样的系统。
成功条件：交谈通常是一种比自悟更好的技术。
这种途径成功与否依赖于：
需求人员是否具有“正确提出问题”的能力，回答人员是否具有“揭示需求本意”的能力。

存在的风险：在交谈期间需求可能不断增长，或是以前没有认识到的合理需求的一种表现，说是“完美蠕行”（Creeping elegance）病症的体现，以至于很难予以控制，可能导致超出项目成本和进度的限制。
应对措施：项目管理人员和客户管理人员应该定期地对交谈过程的结果进行复审。

3.3 观察

通过观察用户执行其现行的任务和过程，或通过观察他们如何操作与所期望的新系统有关的现有系统，了解系统运行的环境，特别是了解要建的新系统与现存系统、过程以及工作方法之间必须进行的交互。尽管了解的这些信息可以通过交谈获取，但“第一手材料”一般总是能够比较好的“符合现实”的。

存在的风险：
一一客户可能抵触这一观察。其原因是他们认为开发者打扰了他们的正常业务。
一一客户还可能认为开发者在签约之前，就已经熟悉了他们的业务。

3.4 小组会（Group session）

举行客户和开发人员的联席会议，与客户组织的一些代表共同开发需求。其中：

通常是由开发组织的一个代表作为首席需求工程师或软件工程项目经理，主持这一会议。但还可以采用其它形式，这依赖于其应用领域和主持人的能力。主持人的作用主要是掌握会议的进程。

必须仔细地选择该小组的成员，不仅要考虑他们对现存的和未来运行环境的理解程度，还要考虑他们的人品。

3.5提炼（Extraction）

复审技术文档（例如，有关需要的陈述，功能和性能目标的陈述，系统规约接口标准，硬件设计文档以及ConOps文档），并提出相关的信息。

适用条件：提炼方法是针对已经有了部分需求文档的情况。依据产品的本来情况，可能有很多文档需要复审，以确定其中是否包含相关联的信息。在有的情况，也可能只有少数文档需更钉审

以上方法需要综合运用到一个项目中。

四、需求规约

一个需求规约是一个软件项/产品/系统所有需求陈述的正式文档，是一个软件产品/系统的概念模型。
一般来说，SRS应必须具有以下4个性质：
①重要性和稳定性程度（Ranked for importance and stability）.例如：基本需求、可选的需求和期望的需求。
②可修改的（Modifiable）：在不过多地影响其它需求的前提下，可以容易地修改一个单一需求.
③完整的（Complete）：没有被遗漏的需求.
④一致的（Consistent）：不存在互斥的需求.

其中，就功能的需求规约来说，还应考虑以下问题：
（1）功能源。
（2）功能共享的数据。
（3）功能与外部界面的交互。
（4）功能所使用的计算资源。

在获取以上初始需求的基础上，可采用ICEE标准830-1998所给出的格式，完成一个完整的需求文档草案的编制工作。

学习笔记来源于中国大学Mooc上北京大学的《软件工程》选修课。