软件需求开始复习资料总结.docxVIP

填空题:?软件需求包括3个不同的层次一一业务需求、用户需求和功能需求

?把软件需求工程划分为需求开发和需求管理。需求开发可进一步细分为获取(Elicitation)、分析(analysis)、规格说明(specification)和确认(Validation)。

?需求管理的任务是“与客户就软件项目的需求达成并保持一致”

?在开始开发软件之前，往往无法确定所有的需求。这种情况下，可以采用迭代和增量方法，每次实现一部分需求，得到用户反馈后再进入下一循环。

?需求陈述的特点：完整性，正确性，可行性，必要性，有优先次序性，无歧义，可验证性。

?需求规格说明的特点：完整性，一致性，可修改性，可跟踪性。

?对于信息系统、签约开发或自己开发的项目，业务需求应来自投资项目人，而用户需求则应来自产品的实际使用者。

?需求开发是一个迭代的过程。

?业务需求位于需求链中的最顶层，这种需求定义了软件系统的前景与范围。

?用户需求和软件功能需求都必须符合业务需求设定的前景和目标。

?产品前景(productvision)将所有涉众统一到一个方向上。前景描述了产品用来干什么，它最终会是什么样子。

?范围则只与一个特定的项目，或实现产品功能下一增量的某次迭代相关。

?不同的目标、约束和成本因素构成了这三方的制衡关系，导致了不一致的业务需求。

?业务需求决定了应用的广度与深度。

?软件需求的来源取决于软件产品的性质和开发环境。

?用户代表应当自始至终参与项目的整个开发过程，而不是仅参与最初的需求阶段。

?设置用户代言人为构造客户和开发人员之间的伙伴关系提供了有效途径。

?每位用户代言人都是他所属用户类的成员与项目的需求分析员之间的主要联系人。

?需求工程的核心任务是需求获取，即确定软件系统涉众的需要及限制条件的过程。

?一种查找被遗漏的需求的精确方法是CRUD矩阵。CRUD代表创建(Create)、读取(Read)、修改(Update)和删除(Delete)。

?事件一响应表(也称为事件表或事件列表)列出了所有这类事件和系统应对每个事件做出的反应。

?使用“待确定”(tobedetermined，TBD)符号来标记这些尚未确定的需求。

?数据字典：数据字典是一个共享存储库，用于定义应用程序中使用的所有数据元素或属性的含义、数据类型、长度、格式、需要的精度以及数据允许的取值范围或数据值的列表。

?需求标识方法：序列号，层次型编号，层次型文本标签

?直观的需求模型包括数据流图(DFD)、实体一关系图(ERD)、状态转换图(STD)或状态图、对话图、用例图、类图和活动图等

?模型用于分析还是用于设计，取决于建模的时间和目的。

?建模时只需关注系统最复杂和风险最大的部分，以及最容易产生歧义和不确定性的部分。防护性、安全性和任务关键的系统元素也是建模时应该考虑的。

?当逻辑和判定过程很复杂时，我们可以选用判定表和判定树这两种技术来表示系统应该做什么

?主要对用户重要的属性：可用性，有效性，灵活性，完整性，互操作性，可靠性，健壮性，易用性

?主要对开发人员重要的属性：可维护性，可移植性，可重用性，可测试性

?性能需求包括：速度，吞吐量，处理能力，定时

?对于发现并解决需求中的二义性和不完整性，原型也是一种很好的方法。

?每一个受资源限制的软件项目都必须对要求的产品功能定义相对优先级。

?程序维护的任务主要是纠正缺陷、为现有系统添加新功能或新报表，以及对功能进行修改以便遵循修订后的业务规则。

?基于规格说明的测试可以运用若干测试设计策略：动作驱动、数据驱动(包括边界值分析和等价类划分)、逻辑驱动、事件驱动和状态驱动

?项目测试人员应该确定他们如何验证每一条需求，下面列出了一些可能的方法：测试，审查，演示，分析

?原型是控制范围蔓延的又一种有效技术(Jones1994)，通过原型可以预先了解产品可能的实现，这有助于开发人员和用户对用户需要和预期的解决方案有一个一致的理解。

?CCB规章描述了CCB的目的、权力范围、成员构成、运作规程和决策的制定过程等。

?需求跟踪机制将单个需求和其他系统元素之间的依赖关系和逻辑联系编写成文档，这些元素包括各种类型的其他需求、业务规则、系统体系结构和其他设计组件、源代码模块、测试用例以及帮助文件等。

简答题：

副IEEE的软件工程标准术语表则将需求定义为:1用户为解决某个问题或达到某个目标而需具备的条件或能力。2系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。3上述第一项或第二项中定义的条件和能力的文档表达。

副需求管理包括下列活动：1定义需求基线(某一时刻，对特定版本中已达成一致的需求内容的描述)。2审查需求变更请求，评估其可能产生的影响以决定是否批准。3以可控的方式将