最新软件需求-期末复习

软件需求考试总复习1、为什么软件需求这么难？客户说不清楚需求需求自身经常变动分析人员或客户理解有误2、软件需求的定义软件需求＝业务知识＋问题列表＋其他因素。

业务知识包括业务事件、业务实体和业务规则；问题列表是用户在工作中遇到的困难与障碍，这也是软件开发中需要解决的问题；其他因素包括了一些设计约束和非功能方面需求。

3、需求的层次业务需求、用户需求、软件需求需求层次的产物：业务需求是需求定义的产物，用户需求是需求捕获的产物，软件需求是需求分析与建模的产物。

4、软件需求的三种类型功能需求：开发人员要实现什么非功能需求：对产品功能描述的补充设计约束：限制了开发人员设计和构建系统时的选择范围5、软件开发的各个阶段，为什么只有需求阶段称为工程？需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。

后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。

随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。

人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。

需求分析是介于系统分析和软件设计阶段之间的桥梁。

一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。

良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。

所以才只有需求成了工程！6、需求工程划分为哪两个部分需求开发、需求管理7、需求开发包括哪些内容需求获取、需求分析、需求规约（编写需求规格说明书）和需求验证（确认）。

8、需求管理包括哪些内容基线管理、变更管理和需求跟踪。

9、如何评价需求的好与坏（优秀需求的特点）完整性、正确性、可行性、有优先次序、无歧义、可验证性、确定性10、客户的含义广义来讲，客户泛指直接或间接得益于产品的个人或组织。

软件的客户包括那些提出软件需求，购买、定义、使用软件产品或选择接受软件功能的项目涉众11、“签字”的含义签字是项目的一个里程碑，是建立需求协议的基线。

12、需求定义阶段的任务确定项目的宏观需求。

换句话说，就是定义项目的业务需求，也就是明确项目的目标和范围。

13、需求定义的理念目标、问题、可选方案、建议方案14、问题分析5步法在问题定义上达成共识、理解根本原因（也就是分析问题背后的问题）、确定相关人员和用户、定义解决方案的界限、确定加在解决方案上的约束15、需求定义的产物根据项目类型的不同，需求定义的产物大致可以分为POS（Project Overview Specify,项目综述）和Vision(愿景)两大类。

16、需求定义的要素目标、范围、相关人员与用户、相关事实与假设17、一个好的目标应满足的原则（SMART）必须是具体（Specific）的：目标必须能够指导具体的工作必须是可以度量（Measurable）的：这样才能进行成本/效益分析必须是可以达到（Attainable）的：否则是没有意义的目标必须和其他目标具有相关性（Relevant）必须具有明确的截止期限（Time-based）18、需求开发过程需求开发过程是一个迭代的过程，不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。

19、划分主题域(构件图，也即UML中的组件图)业务事件类型：外部事件（来自系统外部的事件，也就是系统参与者发起的）内部事件（系统内部触发的）20、确定主题域（上下文关系图）上下文关系图：针对每个主题域来绘制上下文关系图，确定出每个主题域的范围。

上下文关系图绘制要点：首先用一个矩形表示系统，写上系统的名称，将整个系统看作一个黑盒子。

然后找到该系统的所有客户（处于主题域的外部），考虑他们会发起什么事件，这些事件会引发内部工作人员的什么动作，将这些序列逐一表示出来。

最后再看看系统的每个内部工作人员还有没有一些主动发起的事件。

当上下文关系图绘制出来之后，整个主题域的范围也就框定出来了，但是它还不足以为后续的需求捕获、分析与建模活动提供良好的基础。

我们需要将主题域的内容以业务事件列表和报表列表表示出来。

21、需求分析人员的工作需求分析人员是对项目相关人员的需求进行收集、分析、记录和验证职责的承担者，是用户群体和软件开发团队间进行需求沟通的主要渠道。

定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求等。

22、需求分析人员必备的技巧和知识需求分析员必须掌握的技能：包括倾听、交谈和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和创造能力。

而这些能力可以概括为业务知识、技术知识和沟通能力三个方面。

需求分析人员必备的知识：具备从实践经验中积累的广博知识需要将需求开发与管理活动贯穿于整个产品生命期中掌握应用领域的知识23、如何成为一名需求分析人员优秀的需求分析员是培养出来的，而不是训练出来的。

这项工作包括很多面向人而不是技术的“软性技能”。

对于需求分析员的工作并没有标准的描述，因而也没有标准的培训课程。

24、需求捕获的主要方法用户访谈、用户调查、文档分析、现场访问客户25、获取客户需求的主要步骤确定产品的不同用户类型。

确定用户需求的来源。

挑选出每一类用户和其他涉众的代表并与他们一起工作。

商定谁是项目需求的决策者。

26、需求捕获应该是主动的和聚集的√27、需求的来源与潜在用户进行交谈和讨论描述现有产品或竞争产品的文档系统需求规格说明现有系统的问题报告和改进要求市场调查和用户问卷调查观察用户如何工作用户工作的情景分析事件和响应28、用户代表用户代表应当自始至终参与项目的整个开发过程，而不是仅参与最初的需求阶段。

29、需求捕获要具有计划性和科学性计划应针对下面这些内容来制定：需求获取的目的需求获取的策略和过程需求获取工作取得的成果进度和资源评估需求获取的风险科学性则体现在捕获方法的选取上30、需求获取中各种心理如何应对言过其实心理差异展现法：也就是将不同用户代表的访谈结果进行整理，在系统开发之前把这些差异展示给中高层管理人员，就如何解决达成共识。

瓶颈分析法：对流程执行过程中的瓶颈进行分析，例如时间瓶颈、人员瓶颈（比如所有的申请都要由处长审批）等方面，以避免流程瓶颈导致系统无法顺利运转起来越俎代庖心理要解决这个问题，关键在于需求捕获人员能够识别出正确的被访谈者，也就是回答你要问的问题最佳的人选是谁。

这里有两层意思：问题的层次是否正确：高层管理人员解决宏观问题，中层管理人员解决脉络问题，操作者解决细节问题。

根据业务背景判断：也就是有效地识别该问题所针对的业务环节是由谁负责处理的？执行者往往是回答的最佳人选。

非正事心理客观原因：办公室本身就是一个容易被干扰的环境。

应对之道：访谈应该尽可可能的避开办公室。

主观原因：非计划的事情通常会被看做是低优先级的事情。

应对之道：做好一周的访谈计划，列出访谈人，访谈要点，让对方统一安排。

抗拒心理我们需要先“化敌为友”。

这是主导的策略，实际的方法有很多推卸责任心理突破推卸责任心理的简单手段是让被访谈者介绍工作场景。

31、需求获取中的注意事项如果没有一个有条理的组织方案（例如用例），要将来自众多用户的需求意见合并起来相当困难。

只向很少的用户代表收集意见，或者只听取声音最大、最固执已见的客户的意见，也是需求获取过程中存在的问题。

这将导致遗漏对某些用户类很重要的需求，或者引入一些大多数用户并不需要的需求。

解决这一问题的最佳平衡方式是让用户代言人参与需求获取，这些代言人必须具备为所属的用户类代言的权力，同时每个代言人都有数名来自同一用户类的用户代表作为后援。

需求获取过程中，你也许会发现项目范围定义不正确，或者太大，或者太小。

32、需求分析主要用来做什么需求分析实际上是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作。

更具体地描述需求分析工作的任务：分解、提炼、消除矛盾。

连成一句话就是：需求分析就是先分解、再提炼，在这个过程中消除矛盾。

33、建模的要点与原则建模的要点设计要考虑到计划之外的变化设计要文档化用可视化的模型表达架构切忌“为了建模而建模”建模的原则选择创建什么模型对如何动手解决问题和如何形成解决方案有着深远的影响每一种模型可以在不同的精度级别上表示最好的模型是与现实相联系的单个模型是不充分的，对每个重要的系统最好用一组几乎独立的模型去处理34、建模工具的选择建模的要点是根据要完成的任务选择合适的建模工具。

35、UML的优点首先UML是一种统一的、标准化的建模语言，它能为许许多多参与软件设计和开发的人提供一种公共“语言”，使他们能够基于共同的“模型”来理解业务、需求，理解软件和架构如何构造其次UML是一种应用面很广泛的建模语言，它不仅可以用于软件系统建模，还可以用于业务流程、业务知识、数据库、嵌入式等多个领域；而且对于不同的领域，其所采用的本质元素是相同的。

这样：不同的人就可以基于相同的语言沟通；不同的领域模型就可以通过相同的机制进行互换与迁移。

这就是统一的趋势36、流程分析（跨职责流程图、活动图）跨职责流程图适合于将流程分析的产物在企业管理中复用时，或者参与的人员有更强的业务背景。

要素：流程名称、职责带区、流程阶段、流程元素、并行、流程引用活动图活动图是一种表述过程机理、业务过程以及工作流的技术。

它主要的应用包括两个方面：一是在业务建模阶段，对工作流进行建模；二是在系统分析和设计阶段，对操作进行建模它的作用和传统的“流程图”是有着很深的渊源，也十分的相似。

不过它与流程图最主要的区别在于，活动图能够支持并行的行为。

37、领域类图标识类：发现类的方法很多，此处介绍最广泛使用的“名词动词法”主要规则：名词与名词短语中提取对象与属性；动词与动词短语中提取操作与关联；所有格短语通常表明名词应该是属性而不是对象38、用例模型参与者：参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。

参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。

用例：用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。

用例的特征：用例是相对独立的：用例的执行结果对参与者来说是可观测的和有意义的：这件事必须由一个参与者发起。

不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例：用例必然是以动宾短语形式出现的：一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元两个用例之间可能存在的关系：包含、扩展、泛化，而通常不应该有通信关系包含关系：在UML中，用构造型<<include>>表示（箭头方向是从基用例到被包含用例），它是指基用例在它内部说明的某一个位置上显式地合并了另一个用例的行为扩展关系：在UML中，扩展关系用构造型<<extend>>表示（箭头从扩展用例到基用例），它表示基用例在由扩展用例间接说明的一个位置上，隐式地合并了另一个用例的行为泛化关系：用例间的泛化则表示子用例继承了父用例的行为和含义；子用例还可以增加或覆盖父用例的行为；子用例可出现在父用例出现的任何位置关系名称事件流类型含义面向用户开发团队包含子事件流表示两个以上用例共用的子事件流客户扩展扩展事件流抽取出优先级较低的扩展事件流泛化公共事件流抽取多个用例之中的共性开发团队参与者之间的关系：只有一种，即泛化。