软件需求工程 课堂笔记2

本文截取了上课的一部分内容

需求的定义

IEEE的需求定义[IEEE1990]：
（1）用户为了解决问题或达到某些目标所需要的条件或能力；
（2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；
（3）对（1）或（2）中的一个条件或一种能力的一种文档化表述。

基本概念的区分

此处只讲少部分的内容，或者只说一些片段。这些部分是我比较容易理解或接受的。

• 规格说明 == 规约

由于翻译人员的不同，因此有两种表述，在我院的课程中，规格说明使用较多，但是“规约”一词使用更为广泛。

• 软件工程没有客观规律，只有经验总结

• 软件不能凭空产生利润，必须作用于现实社会。

需求的层次性

[IEEE1998]将需求分成下列类别：

• 功能需求（Functional Requirement）：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。

• 性能需求（Performance Requirement）：系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。

• 质量属性（Quality Attribute）：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。

• 对外接口（External Interface）：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。

• 约束（Constraint）：进行系统构造时需要遵守的约束，例如编程语言、硬件设施等。

  除了上述5种明确的软件需求类别之外，[IEEE1998]还指出项目中也可能会出现数据需求（Logical database requirements）等其他特殊类型的需求。

  除功能需求之外的其他四种类别需求又被统称为非功能需求（Non-Functional Requirement）。在非功能需求当中，质量属性对系统成败的影响极大，因此在某些情况下，非功能需求又被用来特指质量属性。

---

其他

下面的内容可能会有一点乱：

问题解决的方法——直接与间接

​ 模拟并操纵共享现象是软件系统满足需求最直接的方法，但有些情况下软件系统也会使用间接的方法解决问题：软件系统操纵共享现象影响问题域的一部分，然后利用问题域内在的规律性自动影响另一部分。例如，图书管理员希望能够督促那些超期的借书者尽快归还图书，直接的解决方式是软件系统将借书者的联系方式建模为表Contact，并自动使用Contact的数据完成督促告知（比如发送邮件）。但是如果软件系统中没有存储借书者的联系方式Contact，也就是说软件系统的共享知识中没有解决问题需要的信息，就只能通过间接的方式来满足需求了，这时软件系统可以将超期者的名单告知图书管理员，然后由图书管理员逐一电话进行督促归还。
​ 考虑问题解决和需求满足的方法时，成本是重要的因素，如果成本能够接受，就尽量使用直接的方式进行解决，如果成本太高，就可以折中使用间接方式进行解决。

用户需求的特殊性

​ 在三个层次中，只有用户需求在表述时在不可验证性上要求较为宽松。因为用户需求具有下面几个特点：①模糊、不清晰。用户需求允许适度使用形容词和副词，使得描述常常带有模糊和不清晰的特性；②多特性混杂。在用户进行需求描述时，常常将功能需求和非功能需求混杂在一起；③多逻辑混杂。用户需求是对用户任务的描述，而任务本身往往含有前后相继的多个逻辑处理过程，即一个任务需要进行多次的系统交互才能够完成。

需求开发的层次性