软件需求复习资料

1.需求开发可进一步细分为：获取、分析、规格说明和确认。

2.需求问题导致的主要后果是返工—重复做您认为早已做好的事情。 3.造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确，以及对需求的分析不透彻 4.实现有效的需求工程过程。减少开发后期以及整个维护过程中不必要的返工并可带来极大的回报。 第2章

1.客户泛指直接或间接得益于产品的个人或组织。

2.很多组织把在需求文档上签字作为客户认可需求的标志，签字不仅仅是仪式，更重要的是建立需求协议的基线 。 第3章

1.需求分析包括对需求进行推敲和润色以保证所有的涉众人都能够理解需求，以及仔细检查找其中的错误、疏漏和其他缺陷。

2.分析包括将高层的需求分解成具体细节、创建开发原型，以及评估可行性和协商需求优先级。

3.需求验证可确保需求声明是正确的、具备了所需的质量属性，而且能够满足客户的需要。 第4章

1.需求分析员是对项目涉众的需求进行收集 、 分析、记录和验证等职责的主要承担者。 第5章

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

2.项目范围确定当前的项目要解决产品长远规划中哪一部分。 3.广度(breadth)指应用能完成哪些业务工作(即用例)。 而深度(depth)则说明将各项用例实现到何种程度。

4.前景与范围文档用于将业务需求收集整理到一个文档中，为后续的开发工作打好基础。

5.涉众是积极参与项目、受项目结果影响，或者能够影响项目结果的个人、团体或组织。 第6章

1.开发人员开发的产品与客户期望获得的产品之间常常存在较大差距，即所谓的期望鸿沟。 第七章

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

2.使用增量开发方法，把需求分解成低风险的更小的部分进行研究 3.使用活动挂图(flipchart)来捕获以后再考虑的一些条目

4.将客户的意见归类：业务需求 用例或场景 业务规则 功能性需求 质量属性 外部接口需求 数据定义 解决思路

5.用例是对用户目标或用户需要执行的业务工作的一般性描述；使用场景则是某个用例的一条特定路径。

6.一种查找被遗漏的需求的精确方法是CRUD矩阵。CRUD代表创建、读取、修改和删除。 第八章

1.用例描述了系统与外部角色之间的一系列交互。

2.角色指与系统交互以实现某种目的的人、软件系统或硬件设备。角色的另外一个名称是用户角色。

3.用例是角色为达到某种重要目标而执行的一种离散、的活动。 4.功能性需求是让用户得以执行用例并达成目标的系统行为。 第九章

1.业务规则是对业务的某个方面进行定义或约束的语句。

2.事实(fact)就是对业务的真实陈述，常常描述重要业务术语间的关联。 事实也称为不变量是关于数据实体及其属性的不可改变的真实情况。 3.在特定条件下触发某个动作的规则被称为动作触发规则。 4.推论是根据某个条件的真实性得出某些新事实的规则，有时也称为推导出的知识。 第10 11 12

1.可以采用以下几种方式来表示软件需求：文档 图形化模型 形式化规格说明

2.几种不同的需求标识方法:序列号 层次型编号 层次型文本标签 3.使用“待确定”(TBD)符号来标记这些尚未确定的需求 4.数据字典是一个共享存储库，用于定义应用程序中使用的所有数据元素或属性的含义、数据类型、长度、格式、需要的精度以及数据允许的取值范围或数据值的列表。

5.可以使用简单的符号法来表示数据字典中的数据项 6.一个数据流图可以标识系统的转换过程、系统所操纵的数据或物质集合(存储)，以及过程、存储和外部世界之间的数据流或物质流。 7.实体是物理项(包括人)或者是数据项的聚合

8.所有软件系统都包括功能行为、数据操作和状态改变。 9.性能需求包括：速度 呑吐量 处理能力 定时 第 13 章

2.“水平”原型主要只是描绘了用户界面的一部分，它并不能深入到体系结构的所有层次，或者深入到系统的细节。通过这种原型，可以完善需求，有助于用户判断基于该原型的系统是否能完成任务。 3.垂直原型也称为“结构化原型”或“概念的证明”，它在整个技术服务层上实现应用程序用户界面的一部分功能。

4.废弃型原型重点强调在健壮性、可靠性、性能和长期维护性等方面的快速实现和修改。

5.演化型原型是螺旋式软件开发生命周期模型和某些面向对象软件开发过程的一个组成部分。必须具有健壮性，代码质量从一开始就要达到产品的要求

6.书面原型有时也称为“低保真原型”，是一种成本低、速度快且不涉及高深技术的方法。 第14 章

1.设定优先级是一种行之有效的方法，可以处理在资源有限的情况下，应该优先满足哪些需求。设定优先级的一种常见方法是把需求分成3类。在这种方法中，总可以将优先级归结为高、中、低3个优先级 第 15 章

1.需求确认是需求开发过程的第4个阶段，前3个阶段分别为需求获取、需求分析和编写需求规格说明

2.审查是一个定义明确的分多个阶段完成的过程，由一小组受过培训的参与者完成，他们仔细检查工作产品的缺陷和是否可能对其进行改进。 第 16 17 章

1.维护是指对当前运行的项目进行修改，有时也称为继续工程或后续开发 2.程序维护的任务主要是纠正缺陷、为现有系统添加新功能或新报表，以及对功能进行修改以便遵循修订后的业务规则。 3.开发团队的目标是，将可用的功能和对质量的改进有规律地交到用户手中

4.主要的规划失误包括，忽略了普通的任务，低估了所需的工作量和时间，没有考虑项目风险，没有考虑返工所需的时间，以及对自己的盲目乐观等 5.基于规格说明的测试可以运用若干测试设计策略：动作驱动、数据驱动(包括边界值分析和等价类划分)、逻辑驱动、事件驱动和状态驱动 第18 19 20 章

1、需求开发包括对一个软件项目需求的获取、分析、规格说明及确认。 2、一般的需求开发的成果应包括前景和范围文档、用例文档、软件需求规格说明、数据字典和相关的分析模型。

3、需求管理包括在项目开发过程中维护需求约定的完整性、准确性以及保持需求约定是最新约定的所有活动。

4、需求基线是团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合。

5.变更控制委员会，有时也称为配置控制委员会(CCB)，已被证实是软件开发领域公认的最佳实践。

6、通过跟踪链，我们可以了解各个需求之间的父子关系、相互连接和依赖关系，这些信息揭示出删除或修改某一特定的需求会波及到的范围。 7、需求跟踪动机:维护、项目跟踪、再工程、重用、降低风险、测试 8、需求跟踪矩阵：表示需求和其他系统元素之间联系链的最普遍的方式

是需求跟踪能力矩阵，也称为需求跟踪矩阵或可跟踪性表 第21章 需求管理工具

1.项目应该定义需求基线，基线就是某一版本的产品要实现的需求的集合。

2.定义新的数据域或需求属性时，要使用业务术语，而不要使用IT术语。 3.我们明白工具不能克服过程的缺陷，就很可能会发现，商用需求管理工具可以提高我们对软件需求的控制能力。 第22章 改进需求过程

1.软件过程改进的最终目标是降低软件的创建和维护费用 2.需求是每个软件项目成功的核心所在，它支持其他技术活动和管理活动 3.用户需求和功能性需求是系统测试必不可少的参考依据。 4.产品需求是用户文档编写过程的依据。

5.过程改进周期的最后一步是评估完成的活动和取得的成果，这种评估有助于团队在未来的改进活动中做得更好。

6.需求工程的各个阶段(需求获取、需求分析、编写需求规格说明、需求确认和需求管理)

7.变更控制委员会(CCB)是由项目涉众组成的一个团体，它负责决定批准或否决哪些提议的需求变更，以及每个批准的变更在哪个产品版本中实现。

第23章 软件需求与风险管理

1.风险就是可能给项目的成功带来某些损失或威胁的情况 2.风险管理的要素：评估、避免，控制

3.将通过逆向工程发现的需求编写成文档，让客户评审这些需求，以确保其正确性和相关性。

1.需求分析员职责与工作：需求分析员是对项目涉众的需求进行收集、分析、记录和验证等。主要负责以下工作：定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、编写需求规格说明、为需求建模、主持对需求的验证、引导对需求的优先级划分、管理需求。

2.软件需求层次：软件需求包括3个不同的层次——业务需求、用户需求和功能需求；除此之外，每个系统还有各种非功能需求。业务需求表示组织或客户高层次的目标。 用户需求描述的是用户的目标，或用户要求系统必须能完成的任务。功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。术语系统需求用于描述包含多个子系统的产品(即系统)的顶级需求。

3.原型定义：软件原型是所提议的新产品的部分实现或可能的实现。原型的意义：使用原型有3个主要目的：1）明确并完善需求：原型作为一种需求工具，它是对部分系统的初步实现，因为我们尚没有很好地了解该系统。2）研究设计选择方案：原型作为一种设计工具，涉众可以用它研究不同的用户交互技术，优化系统的易用性，并评估可能的技术方案。3）发展为最终产品：原型作为一种构造工具，是产品一个最初子集的完整功能实现。

4.软件质量属性对用户重要的属性：1）可用性：可用性用于衡量预定的可用时间，在这期间系统是真正可用并且是完全可操作的。2）有效性：有效性用来衡量系统在利用处理器的处理能力、磁盘空间、内存或通信带宽等方面的表现如何。3）灵活性：灵活性也称为可扩充性、可扩张性、可延伸性和可扩展性。4）完整性：完整性是防护性的组成部分，主要处理防止非法访问系统功能、防止数据丢失、保护软件免受病毒入侵以及保护输入到系统的数据的保密性和安全性等问题。5）互操作性：互操作性表明了系统与其他系统交换数据和服务的难易程度。6）可靠性：可靠性是软件无故障执行指定时间的概率。7）健壮性：健壮性指的是当系统遇到非法的输入数据、相连接的软件组件或硬件组件的缺陷，以及预料不到的操作情况时，能继续正确运行功能的可能性。8）易用性：易用性衡量准备输入、操作和理解产品输出所需要的工作量。

5.对软件开发人员和维护人员重要的质量属性：1）可维护性：可维护性表明了纠正缺陷或修改软件的简单程度，它取决于理解软件、更改软件和测试软件的简单程度。2）可移植性：可移植性用来度量把一个软件从一种运行环境移植到另一种运行环境所需的工作量。3）可重用性：确定新系统中哪些元素需要用方便于代码重用的方法设计，或者规定应该创建作为项目副产品的可重用组件库。4）可测试性：可测试性也称为可验证性，它指的是测试软件组件或集成产品以查找缺陷的简单程度。

6.需求获取的定义和怎样判断需求获取已经完成：需求获取即确定软件系统涉众的需要及条件的过程。判断需求完成的一个方法，即为项目开列一个清单，列出需要考虑得标准功能需求，然后定期对照这张清单比较腻已经定义的功能，如果没有发现差异，你的工作也许已经完成了。 7.为什么要使用需求管理工具和使用其的好处：因为随着时间的推移，团队成员对需求细节的记忆会逐渐变得模糊，这时使用需求管理工具的好处就得到了最大程度的体现：①管理版本和变更②存储需求属性③进行影像分析④跟踪需求状态④访问控制⑤与涉众沟通⑥重用需求 8.用户类的划分方法：①使用产品的频率②用户在应用领域的经验和使用计算机系统的技能③所用到的产品功能④为支持业务过程所进行的工作⑤访问权限和安全级别。用户代言人的选择：①必须善于沟通并且受同事的尊重②需要对应用领域和系统的运行环境具有全面而深入的理解③必须准备好充分的理由来说服人们相信他们对项目的成功有多么重要。

填空题：

1.需求基线是团队成员已经承诺将在某一特定产品版本中实现功能性和非功能性需求的一组集合。

2.基线是将正在开发的软件需求规格说明过渡到已通过评审的软件需求规格说明的一个过程。

3.软件需求工程划分为需求开发和需求管理；需求开发进一步细分为获取、分析、规格说明。

4.客户泛指直接或间接得益于产品的个人或组织。

5.客户和开发人员之间合作伙伴关系的核心是就产品的需求达成一致。 6.业务需求决定了应用个广度与深度。广度指应用能完成哪些业务工作(即用例);而深度则说明将各项用例实现到何种程度。

7.前景与范围文档用于将业务需求收集整理到一个文档中，为后续的开发工作打好基础。

8.涉众是积极参与项目、受项目结果影响，或者能够影响项目结果的个人、团体或组织。

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

10.用例是对用户目标或用户需要执行的业务工作的一般性描述；使用场景则是某个用例的一条特定路径。

11.业务需求描述客户和开发组织希望从产品中获得的商业利益。

12.功能性需求描述了系统在特定条件下表现的可观察的行为，以及系统允许用户执行的操作。

13.质量属性是对系统实施某种行为时，或者让用户执行某种操作时，系统表现如何的陈述。

14.数据定义:当客户描述某个数据项的格式、数据类型、允许值和缺省值，或者描述某个复杂业务数据结构的构成时，这种描述就是数据定义。 15.角色指与系统交互以实现某种目的的人、软件系统和硬件设备。

16.事件是在用户环境中发生的某种变化或活动，它能够激发软件系统做出响应。

17.业务规则是对业务的某个方面进行定义或约束的语句。用于声明业务结构，或者控制、影响业务的行为。

18.事实就是对业务的真实陈述，常常描述重要业务术语间的关联。 19.约束了系统或它的用户可以执行哪些操作。

20推论是根据某个条件的真实性得出某些新事实的规则。

化学品跟踪系统的用例图（部分）

化学品跟踪系统的第0层数据流图

化学品跟踪系统的部分实体-关系图

化学品跟踪系统状态转换图

化学跟踪系统对话图

化学品跟踪系统判断树：

化学品跟踪系统判断表：

根据用例的功能编写测试用例

变更请求的状态转换图：