下载文档原格式
2015级北大软微软件需求工程期考试资料
考试时间：12月7号上午9:00-11:00考试地点：3303
题型：简答4道论述题5道
Lecture_1：软件需求工程介绍
一．需求概念和软件需求的概念，为什么需求要分层（考试考到了），怎么分的
需求定义是（P5）
(1)用户解决问题或达到目标所需条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所述条件或权能的文档说明。
需求是“任何促成设计决策的因素”
需求的分层问题：（P6-7）
我们的软件产品或者项目，其需求都有三个层级和三个方面。软件需求包括3个不同的层次-----业务需求、用户需求和功能需求。
业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求文档。
用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能够完成的任务。用例，场景描述和事件-响应表都是表达用户需求的有效途径。也就是说，用户需求描述了用户能使用系统来做些什么。
功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
业务规则包括企业方针、政府条例、工业标准、会记标准和计算方法等。业务规则本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特地用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
除了功能需求外，SRS中还应该包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。
二.软件需求工程的概念，需求开发和管理，什么是需求的基线，开发和管理怎么区分的
需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。软件需求工程是一门分析并记录软
件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等。需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。（以上是百度百科参考的）
软件需求工程划分为需求开发和需求管理
●需求开发（P9）可进一步分为问题获取、分析、编写规格说明和确认四个阶
段,需求开发活动包括以下几个方面：
(1)确定产品将要面对的各种用户
(2)获取每个用户类的需求
(3)了解实际用户任务和目标以及这些任务要实现的业务目标
(4)分析从用户处得到的信息，将用户的任务目标与功能需求、非功能需求、
业务规则、解决方案建议以及其他无关信息区分开来。
(5)将顶层的需求分配到系统架构内定义好的软件组件中。
(6)了解各质量属性的相对重要性
(7)协商需求的实现优先级
(8)将收集的用户需求表述为书面的需求规格说明和模型
(9)审阅需求文档，以确保在认识上与用户声明的需求相一致。应在开发小组接受需求之前解决所有分歧。
●需求管理（P10）的任务是“与客户就软件项目的需求达成并保持一致”，
这种一致性应该体现在书面的需求规格说明和模型中。取得用户认可，并且必须让开发人员接受需求规格说明书并同意在产品中加以实现，需求管理包含如下活动：
(1)定义需求基线(某一时刻，对特定版本中已达成一致的需求内容的描述)
(2)审查需求变更请求，评估其可能产生的影响以决定是否批准。
(3)以一种可控制的方式将准的需求变更融入到项目中
(4)保持项目计划与需求的同步
(5)估计需求变更的影响，并在此基础上协商新的需求约定。
(6)跟踪每项需求，找到与其对应的设计、源代码和测试用例
(7)在项目开发过程中，始终跟踪需求的状态和变更。
●需求基线（P222）是团队成员已经承诺将在某一特定产品版本中实现的功能
性和非功能性需求的一组集合。定义了一个需求基线之后，项目的涉众各方就可以对发布的产品中希望具有的功能和属性有一个一致的理解。确定需求基线时--一般是在通过正式的评审和批准之后，就应该对它们进行配置管理。后续的变更也必须遵守项目预先定义好的变更控制过程。在确定需求基线之前，仍然可以对需求进行变更，因此，把一些不必要的过程开销强加于这些变更就没有什么意义。但是一旦建立了初步的文档草稿，就应该开始实施版本控制--唯一地标识每一个需求文档的不同版本。
●需求开发和管理的区分图：
