软件需求考试总复习网络资料.docx
《软件需求考试总复习网络资料.docx》由会员分享，可在线阅读，更多相关《软件需求考试总复习网络资料.docx（18页珍藏版）》请在冰豆网上搜索。
软件需求考试总复习网络资料
1、为什么软件需求这么难？
客户说不清楚需求
需求自身经常变动
分析人员或客户理解有误
2、软件需求的定义
软件需求＝业务知识＋问题列表＋其他因素。
业务知识包括业务事件、业务实体和业务规则；问题列表是用户在工作中遇到的困难与障碍，这也是软件开发中需要解决的问题；其他因素包括了一些设计约束和非功能方面需求。
3、需求的层次
业务需求、用户需求、软件需求
需求层次的产物：
业务需求是需求定义的产物，用户需求是需求捕获的产物，软件需求是需求分析与建模的产物。
4、软件需求的三种类型
功能需求：
开发人员要实现什么
非功能需求：
对产品功能描述的补充
设计约束：
限制了开发人员设计和构建系统时的选择范围
5、软件开发的各个阶段，为什么只有需求阶段称为工程？
需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。
后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。
随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。
人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。
需求分析是介于系统分析和软件设计阶段之间的桥梁。
一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。
良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。
所以才只有需求成了工程！
6、需求工程划分为哪两个部分
需求开发、需求管理
7、需求开发包括哪些内容
需求获取、需求分析、需求规约（编写需求规格说明书）和需求验证（确认）。
8、需求管理包括哪些内容
基线管理、变更管理和需求跟踪。
9、如何评价需求的好与坏（优秀需求的特点）
完整性、正确性、可行性、有优先次序、无歧义、可验证性、确定性
10、客户的含义
广义来讲，客户泛指直接或间接得益于产品的个人或组织。
软件的客户包括那些提出软件需求，购买、定义、使用软件产品或选择接受软件功能的项目涉众
11、“签字”的含义
签字是项目的一个里程碑，是建立需求协议的基线。
12、需求定义阶段的任务
确定项目的宏观需求。
换句话说，就是定义项目的业务需求，也就是明确项目的目标和范围。
13、需求定义的理念
目标、问题、可选方案、建议方案
14、问题分析5步法
在问题定义上达成共识、理解根本原因（也就是分析问题背后的问题）、确定相关人员和用户、定义解决方案的界限、确定加在解决方案上的约束
15、需求定义的产物
根据项目类型的不同，需求定义的产物大致可以分为POS（ProjectOverviewSpecify,项目综述）和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中，用构造型<>表示（箭头方向是从基用例到被包含用例），它是指基用例在它内部说明的某一个位置上显式地合并了另一个用例的行为
扩展关系：
在UML中，扩展关系用构造型<>表示（箭头从扩展用例到基用例），它表示基用例在由扩展用例间接说明的一个位置上，隐式地合并了另一个用例的行为
泛化关系：
用例间的泛化则表示子用例继承了父用例的行为和含义；子用例还可以增加或覆盖父用例的行为；子用例可出现在父用例出现的任何位置
关系名称
事件流类型
含义
面向用户
包含
子事件流
表示两个以上用例共用的子事件流
开发团队
扩展
扩展事件流
抽取出优先级较低的扩展事件流
客户
泛化
公共事件流
抽取多个用例之中的共性
开发团队
参与者之间的关系：
只有一种，即泛化。
应用举例：
系统功能：
以Internet的形式向客户提供座位预订的服务，并且如果暂时无法获取座位信息时，允许客户进入“等侯队列”，当有人退订之后将及时通知客户。
另外，该系统还将为总台服务员提供座位的安排，以及结账的功能，要求能够支持现金和银行卡两种结账方式。
40、业务流程为主线的分解结构
业务流程为主线的分解结构：
这种结构是以业务流程为主线索的，也就是按“事”的角度进行分解。
它对于联机事务处理系统、管理信息系统而言是非常适用的方法。
程序结构为主线索的分解结构：
适用于问题域不复杂，或者系统与问题域关联性不强的情况下，例如工具软件、面向设备的嵌入式系统等
基于场景的分解结构
对于决策支持系统、面向用户的嵌入式系统而言，决策场景、使用场景就是主要的线索。
向上可以总结成一类相似的集合，再总结成一系列的关注点或功能域；而向下可以分成具体的决策步骤或操作任务。
基于数据的分解结构
适用于数据仓库之类的数据类项目。
对于诸如数据仓库之类的数据类项目，“事”这条线索并不明显，或者并不重要，这时就需要采用以数据为主线的分解结构。
41、流程的层次
填充需求细节
需求分析的主线索，流程分析的主要输出
对部门级流程的抽象概括
42、部署图
部署图：
表示该软件系统如何部署到硬件环境中。
它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。
也就是说部署图描述系统硬件的物理拓扑结构以及在此结构上执行的软件。
它可以显示计算机节点的拓扑结构和通信路径、节点上运行的软件构件等。
关键组成部分：
节点、连接、构件、接口
节点：
代表一类运行时的计算资源（例如：
一类服务器、一类工作站、一个PC终端、一个打印机、一个传感器等）。
连接：
表示两个节点之间的物理连接，用一根实现表示（关联关系）
43、非功能需求
对产品功能描述的补充。
是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。
44、软件需求规格说明书编写
常见的描述风格：
自然语言：
优点：
易于编写、易于阅读，不用掌握特定的技能，
缺点：
不够严谨，歧义性强，表述力差
图形化模型
优点：
可视性、聚集性
缺点：
要求编写和阅读人都能够正确地理解模型
形式化规格描述
优点：
严谨、精确
缺点：
编写和阅读人都会感觉很困难，易产生理解歧义
根据不同项目、软件开发团队的特点，选择不同的风格组合。
模板类型（3种）：
国标/ISO版本：
该标准由1988年制定，于2006年发布了新的版本
RUP版本：
其主要采用模型为主的思路，文字部分的模板显得有点过于简单，无法涵盖所有需要的内容
咨询商版本：
比较追求通用性，有时难免出现“大而全”的弊端。
典型代表：
Volere
写作策略与技巧：
软件需求规格说明书是应用文，不强调优美的辞藻、工整的句子，而是强调信息的有效传递！
需求描述的两大原则：
简洁、段落文字少列表、图表相结合的表示法
45、需求评审
同级桌查/轮查：
是个人级的评审方法，是需求人员之间私下进行的交叉审查。
桌查：
两位需求人员之间交换文档产物，互相提出意见
轮查：
多位需求人员之间交叉交换文档产物，互相提出意见
临时评审：
通常是个人的工作习惯。
最常见、最简单的临时评审是在沟通过程中，由信息的接收者向信息的传达者做简要的、概括性的回顾，以期达成共识。
审查过程概述：
评审活动的直接目的：
是找出软件需求规格说明书中的问题，但更有价值、更有意义的是解决问题，并且避免它。
解决问题：
我们必须对提出的问题是否解决进行跟踪、督促
避免问题出现：
对所有问题都应该进行分类、因果分析、找到出现这些问题的深层次原因
升级会员 