第二章 需求基础
1、名词解释
名词解释基本不考，重要的是理解！
- 需求的定义（IEEE那三句话，考研背烂了）
- 用户为了解决问题或达到某些目标所需要具备的条件或能力
- 系统或系统部件为了满足合同标准规范所其他正式文档所规定的要求而需要具备的条件或能力
- 对前两条中一个条件或一种能力的文档化表述
- 问题的产生
- 现实与人们期望的差距 = 问题
- 问题域
- 人们想要改变现实中某些实体的状态，或改变这些实体状态变化的顺序，达到人们期望的效果，这就解决了问题，这些实体和状态就是问题域，即解决问题的基本范围。
- 解系统
- 软件系统通过影响问题域，来帮助人们解决问题，这就是解系统
- 。。。。其他概念感觉不会考
这章最重要的就是需求的层次与分类，让你根据案例来写需求，看案例
需求的三个层次
1、业务需求
- 是系统建立的出发点，是高层次的目标，表示为什么要开发这个系统
- 格式：系统要怎么怎么样…
2、用户需求
- 是用户对系统所能完成任务的期望，描述了系统能帮用户做什么。
- 格式：用户使用系统可以怎样怎样…
3、系统级需求
- 用户对系统行为的期望，必然有行为交互，一系列的交互行为帮用户完成任务
- 格式：用户怎么怎么样…系统怎么怎么样…
- 项目需求
- 项目成本、项目完成时间
- 过程需求
- 针对的对象是软件开发过程，包括开发人员、开发工具、方法（关键字眼）
- 比如使用持续集成方法开发
- 比如开发者要提交需求规格说明
- 系统需求
- 软件需求分为功能性需求和非功能性需求
- 下面详细写
- 硬件需求
- 买服务器
- 其他需求
- 人力需求，对xx培训
- 不切实际的期望
软件需求，这边非常重要
- 功能需求
- 和系统主要工作相关的需求，用户希望系统执行的活动，这些活动能帮用户完成任务。
- 性能需求（速度、容量、吞吐量、负载、实时性）
- 质量属性（系统的安全性、可维护性、可移植性、稳定性、可用性、易用性）
- 考试时候随便选一点吹，比如可维护性，要排除故障、改进质量以及适应环境变化，包括可修改、可扩展
- 对外接口（系统和其他环境的接口，如硬件接口，软件接口，数据库接口）
- 约束（编程语言约束、硬件设施约束）
- 开发技术手段（如编程语言约束、系统开发环境）
- 企业盈利的商业逻辑约束（一些潜在规则）
- 相应法律政策约束
- 会性因素（文化、信仰）
- 数据需求
- 需要在数据库中、文件中存储的数据描述。
第五章 确定项目的前景与范围
1、前景与范围
项目前景： 描述了该软件产品是用来干什么的，以及最终会是什么样的。前景将涉众的意见都统一到了一个方向上来，其中包括了问题与以及需求。
项目范围： 指出当前项目主要是解决产品长远规划中的哪一部分。范围的声明为项目化定了需求的界线。
定义范围的必要性：
- 加强用户和开发人员的理解，降低风险
- 通过定义项目范围，帮助涉众建立现实的期望
- 为项目化定义了需求的界线，范围内的事物是描述的目标
2、问题分析过程
- 获取问题
- 通过收集资料、背景调查、和涉众沟通来实现
- 明确问题
- 要和涉众达成共识（问题要易于理解和指明解决方向）
- 分析不明确的问题，发现问题背后的问题
- 发现业务需求
- 对于我们获取的每个明确的问题，都对应着涉众的期望目标，这就是业务需求
- 业务需求要得到涉众的一致认同
- 定义解决方案
- 寻找解决方案、和涉众沟通，比较各种方案
- 确定系统的特性、边界
- 寻找约束，进一步限定解决方案
3、目标分析过程
高层目标的获取
- 对于系统的现状、背景、问题分析，发现高层目标，这些目标可被定义为业务需求。
目标精化
对高层目标的相关信息进行分析，得到子目标，主要有如下几个方面
- 收集对高层目标的描述信息，如企业规章、政策、任务是什么、业务场景
- 从高层目标发现AND精化关系
- AND精化就是子目标共同促成大目标
- 从高层目标发现OR精化关系（发现候选办法）
- 子目标之间可以相互替换
- 考虑阻碍目标实现的情况
- 哪些事件会使得子目标失效这个阻碍目标
- 发现目标冲突
- 注意不同视角之间的冲突
目标实现
- 收集与目标相关的需求信息、讨论可能的解决方案、确定最终的解决方案
- 将底层目标分配给主体
- 设计实现最底层目标的操作
第六章 涉众分析与硬数据采样
1、什么是涉众
涉众是对软件开发和应用具有发言权和决定权的人，可以理解为所有能够影响软件系统的实现，或是软件系统被实现后能影响的人。
2、涉众分析过程
对于不同类型的项目，要执行不同类型的涉众分析，以下是较为复杂的涉众分析过程
考试几乎年年考涉众的评估（重点是优先级评估及风险评估，要求画图）
涉众识别
- 发现所有的涉众类别（不同涉众执行不同任务，不同人群目标、需求不一样）
- 过滤非关键的涉众类别
- 常见涉众：用户、客户、开发者、管理者、领域专家、政府、市场等
涉众描述
- 识别出关键的涉众后，需要描述涉众的特征（个人特征、工作特征、地理位置、 会背景等）
涉众评估
- 涉众的优先级评估，尤其要考虑任务特征，主要有以下优先级
- 参与者（系统的实际使用者）
- 系统环境的设定者（不直接使用系统，但由于某些因素对系统影响较大，如政治、权利）
- 被影响者（可能是系统的直接使用者）
- 观众（受系统影响较小，没能力影响系统的决策）
- 风险评估
- 有些涉众的表现与开发者预期不一致，可能会为项目开发带来风险，要分析涉众的态度（强弱支持者/反对者），对于涉众的不同态度，采取不同措施，控制和化解风险。
前景与范围阶段
- 准备：背景资料获取与分析
- 第一轮：问题分析（深入）
- 第二轮：高层解决方案制定（确认）
用户需求获取阶段
准备：明确主题与内容，准备材料
第一轮：明确任务与任务中主要问题（深入）
第二轮：明确任务细节，澄清困难内容（技巧、困难）
第三轮：明确解决方案（确认）
需求获取的三个方法/手段（重点！每个手段都要会写！）
面谈：常规方法
集体面谈：快速方法
头脑风暴：“发明”需求
不确定性：原型
情景性：观察
第八章 面谈
1、准备面谈
准备工作
- 阅读被会见者的信息，别把时间浪费在一般性背景问题上
- 确定面谈主题和目标是什么
- 选择正确的被会见者，最好是关键人物
- 提前通知被会见者做准备
- 确定面谈的问题和类型，考虑每种问题产生的效果
问题类型（重点！给出案例背景，让你提问，提问的类型要多样）
- 基本类型
1、开放式问题（让被会见着感到自在，但会产生太多不相干细节）
- 你们部门最重要的目标是什么li>
2、封闭式问题（回答限的很死，节省时间、切中要点，但让人厌烦）
- 电话中心一个月平均收到多少次电话li>
- 程序性提示
1、能避免面谈过程中的一些认知性问题，比如总结性语句、重复语句、建立场景的语句等
- 能否再说一下系统中哪些功能比较重要复）
- 能否总结一下你希望得到系统哪些反馈结）
- 其他类型
1、探究式问题（很有必要，使被会见者说出实情和要点）
- 为什么li>
- 你能举个例子吗li>
- 你能详细描述一下吗li>
2、诱导性问题（为他设置圈套）
3、元问题（元问题是关于面谈本身的问题）
- 我的问题看起来相关吗li>
- 我问的问题是不是太多了li>
- 我应该还见什么人li>
问题准备
- 面谈时间很短，要高效利用时间
- 问题要主导面谈过程，而不是被主导，事先准备好面谈主题与线索
- 事先的准备减少面谈时记录的负担，更好的主导面谈过程
2、主持面谈
开始阶段
见面，互相介绍
就坐、准备 笔记本、录音笔，提醒他记录方式和要点
开始使用开放式问题建立面谈局面，试探被会见者态度。
主体阶段
有礼貌的倾听
控制面谈过程，控制时间，必要情况下指定回答长度
维持面谈主题
对于不清晰的回答，使用探究式的问题
观察被会见者的肢体语言
记录面谈
记录内容
- 被会见者的观点是什么有夸大事实
- 被会见者是什么感受态度
记录方式
用笔还是录音取决于和谁面谈，各有优缺点
- 笔录
- 表明会见者是有准备的（优点）
- 使会见者专心和集中精力（优点）
- 帮助回忆重要的问题（优点）
- 让被会见者说话犹豫（缺点）
- 造成对事实注意过多，?对感觉及观点注意过少 （缺点）
- 录音笔
- 可以完整的重现面谈过程（优点）
- 被会?者可能会紧张，回答不?在 （缺点）
- 事后进行信息寻找时难以定位（缺点）
3、面谈类别
- 结构化面谈
- 会见者完全按照事先准备的问题和结构控制面谈，获取一些比较确定的或是选择空间有限的信息
- 易于控制、节省时间，但让人厌烦，无法获取丰富内容
- 半结构化面谈
- 事先根据需要准备面谈的问题和结构，在面谈过程中根据情况采取一些灵活的策略
- 半开放式，内容丰富，但不易控制，可能浪费时间
- 非结构化面谈
- 没有事先准备，面谈主题很广泛，也可能就某个主题进行深入讨论。
第九章 需求获取方法之原型
这章要理解不确定性与原型类别
1、预备知识
不确定性
- 对未来知识了解有限而无法确定某些行为的后果。
- 解决不确定性
- 增加对未来知识的了解程度（使用算法计算、预测）
- 进行风险管理
原型（用于解决不确定性）
- 对于不确定知识，涉众自己本身不了解，需求工程师只能自己想办法解决，主要手段是通过原型。
- 原型是一种工具，通常是系统的一个部分或一个模型，重要的是人们利用它进行改进、迭代。
2、根据用途分类原型
演示原型
- 主要用于项目启动阶段，展示开发者的技术能力和解决特定问题的可能性，比如以一个Demo演示技术上的可行性。
严格意义上的原型
- 主要用于需求分析阶段，用于探索和解决需求的不确定内容。
试验原型
- 主要用于系统构建阶段，用于解决技术方面的不确定性
引示系统原型
- 这个原型不是用于探索某个想法的，而是被用作最终系统的构建核心。
3、使用原型进行需求获取的基本过程
重点！！原型开发的过程！！步骤！！
1、确定原型需求
- 为什么要开发原型开始望的结果是什么li>
- 发现需求有不确定性，就可以考虑使用原型法，比如需求可能变更、可能存在冲突、需求信息不足。一些创新的需求，以前没有过，有很大的不确定性，或是涉众无法明确产品细节，产品功能不确定，等等不确定都可以用原型
2、原型开发
- 注意，开发的原型要易于修改，因为你构建的原型本身有缺陷，原型本身就是探索不确定性，在评价中必然会修改。
- 要控制开发成本
3、原型评估
- 将原型提交给评估者进行评估，评估者通常是用户去感受系统功能，涉及技术层面就是开发者。
- 原型评估要无偏见，要引导评估者从合适的角度评估
- 最好是亲自观察评估者使用原型的过程，能获得更多信息，观察他们的自然倾向是什么
- 收集评估者的反应（观察得到）、建议、创新思想
4、原型修正
- 根据评估者的建议去调整原型
4、抛弃需求原型
重点！！这几种原型适用情况与区别！！
1、探索式
- 一开始开发者了解需求，但是了解程度很浅、很模糊，开发者根据需求内容开发一些初始原型，然后获取用户对这些原型的反馈，不断调整原型，最后得到清晰的明确的需求，发现未知的需求。探索式原型帮助开发者更好的了解用户的问题和期望。
2、实验式
- 在一开始就有清晰的用户需求，但是开发者对于这些需求的实现没有太大把握，利用实验式原型，来对各个方案评估其可行性，明确可行的技术实现方案。
3、演化式
- 原型是作为整个项目开发的一部分，被不断的改进和增强，最后成为最终的软件系统
为什么要坚决抛弃抛弃式原型年考）
答：按照名字，因为代码质量较差，这些原型理所应当被抛弃。有些开发者和管理人员从人力、成本的角度，认为不应该抛弃，转而把抛弃式原型交付了，最终导致较差的产品质量。这些人应该充分认识到：抛弃式原型的贡献不在于它的代码，而在于它所包含的内容，它解决了需求中的不确定性，让我们得到了正确的的需求和正确的技术方案，这是它的宝贵之处，如果不认识到这一点，只能得到低质量的代码，并且抛弃式原型大多数是探索式的！
5、控制原型成本
1、根据抛弃式特征控制成本
- 因为抛弃式原型始终都要被抛弃的，可以在开发原型的过程中忽略与原型目标无关的功能，只要它能满足原型制作的目标就行
2、水平控制原型成本
系统构建是分层的，常见的比如三层架构，这边有两种类型
- 水平原型方法：仅关注特定的一层，比如用户界面层，在这层处理较大范围的功能
- 垂直原型方法：关注所有层，但处理较小范围的功能
3、尽量使用简单的介质降低原型成本
- 常见的介质：白纸、黑板、便签、PPT动画、快速语言工具、程序语言
6、原型方法的风险
1、成本失控
- 一不小心对原型开发投入太多的人力、成本、时间，导致最后被迫交付原型。必须认识到原型只是一种工具，帮助我们解决不确定性。
2、给客户造成错误的印象
- 客户看到一个正在运行的原型，可能直接得出对这个产品的印象，但实际上这个原型是不完整的产品。所以我们不到万不得已绝不能提交抛弃式原型
3、用户关注点到了非关键功能上
- 用户忽略了他们应当重视的功能。
4、原型掩盖了一些用户假设
- 原型虽然能澄清需求，但是会掩盖假设，比如一些功能之外的特性如性能、响应速度、美观度等，我们默认是满足用户需求的，但肯能实际上没有达到用户期望。
第十章 需求获取方法之观察与文档审查
观察：用户专心于做自己的工作，不需要向工程师解释自己的工作，工程师也站在一旁，很少去打断他们，通过观察得到相关信息。
1、常见的观察方法
考试考采样观察与民族志！！
1、采样观察：目的明确，选定时间段和特定事件来观察
2、民族志：浸入式观察方法，观察者深入到用户中，花较长时间观察（一般几个月）
3、话语分析：对用户之间的交谈行为进行观察，得到特定的话语形式
4、协议分析：让观察对象一边执行任务，一边说出他们执行任务时的想法
5、任务分析：专门对人机交互行为进行的观察
2、采样观察
分为两种
1、基于分时的采样观察
- 允许工程师在指定时间间隔来观察用户活动情况。
- 优点
- 节约时间和成本
- 通过随机观察减少偏差
- 缺点
- 无法为某件事提供充分的观察时间，不能贯穿整个业务
- 一些细节之处可能得不到观察
- 使用场景
- 发现异常流程
- 验证用户实际工作的一致性
2、基于事件的采样观察
- 有目的的选取整个事件进行观察
- 优点
- 能对整个行为过程进行观察，连贯
- 缺点
- 耗费时间
- 漏掉频繁发生时间的代表性样本
- 使用场景
- 获取默认知识
- 验证用户实际工作的一致性
3、民族志
对于一些复杂的协同工作而言，工作的协同安排具有 会性，有突现的情景性，民族志可以帮助开发者了解这些工作的 会性因素，解决突现的情景性因素。
- 优点
- 深度理解信息。由于在实际环境中观察，所以开发者能看到他们实际做的事情，一段时间后，开发者能够对他们的工作环境、工作内容有深度的理解。
- 让 会因素可见化。开发者通过日积月累的观察他们的活动，能够感知开发者所需要的 会性因素，进而描述出来，打破了一些已有的错误假设和观念。
- 缺点
- 耗费时间太长，花费大量时间观察、做记录以及分析结果。
- 调研结果很难传递到开发过程，得到的数据太多，内容广泛，但开发者并不需要全面描述在其业务中
- 如何应对复杂协同问题
- 工作的分布式协同
- 个人任务往往是复杂任务中的一个步骤，把所有人的步骤整合起来构成一个大任务。这就要求每个人清晰自己的职责，要求观察者将用户的活动看作整体活动的一部分，而不是单纯的个体活动。在组织规模较大、问题较为复杂的时候，可利用备忘录、文件、表格等物件实现分布式协同，使用这些物件的人能了解协同中其他人已做的事。
- 工作的计划和程序
- 指的是在某个工作场所产生的资料，记录多种任务完成的细节步骤和过程，这些任务集成起来满足整个工作要求，比如项目计划、日程、程序手册等。
- 工作的意识
- 指的是某个活动的组织方式，在这种方式下，活动可以对协同中其他人可见或可理解，比如一边工作一边大声谈论可以实现活动的可见和理解，或通过其他方式来实现。
第十一章 需求分析概述
1、分析模型
（1）需求分析的根本任务是
- 分解复杂系统，建模，达成开发者和用户对信息的共同理解
- 依据共同理解，发挥创造性，创建系统解决方案
（2）建模的几种手段
- 抽象：人们对抽象出的事物有更好的理解
- 分解：分治思想，解决子问题再merge
- 投影
（3）两个世界三种模型
计算世界与计算模型（看作软件实现之前的草案）
- 使用软件的构成单位作为模型的组元，软件构建单位之间的关系作为组元之间的关系
- 缺点是缺乏和软件实现相关的技术细节，用户无法理解，不适合分析建模
问题世界与业务模型
使用问题域中的重要概念作为模型组元，元素都来自问题域，使用业务联系作为组元之间的关系
缺点是问题世界太复杂，非形式化特征使得它不适合于进行需求建模
软件分析模型
- 是一种介于计算模型和业务模型二者之间的模型形式，使用了计算模型的组元形式，但在表现上采用了业务模型的表现方式 。
3、需求分析方法
这里主要是结构化分析和面向对象分析
结构化分析，使用数据流图、ER图、状态转移图
4、需求分析活动
主要活动有
- 背景、问题、目标、业务、系统边界的分析（问题域分析，前期需求阶段活动，指导用户获取需求）
- 需求建模、细化、确定优先级和需求协商（后期）
同步消息（发送方发出消息后，等接收方发回响应以后才发下一个数据）
异步消息（发送方发出消息后，不等接收方发回响应，接着发送下个消息）
片段操作符
（1）交互图例子
2、类图
3、状态图
如果有异常，异常出口是这么画的
涉及到决策选择的，使用菱形
如何构建状态图p>
- 确定上下文环境，搞清楚状态的主体，常见的状态主体有：类、用例、多个用例和整个系统
- 识别状态，标记初始状态和结束状态，可能会不存在确定的初始状态和结束状态
- 建立状态转换
- 补充详细信息，完善状态图
4、行为契约OCL
介绍：我们的概念类图、交互图、系统顺序图都是用于行为模型的，除了行为模型还有一些其他模型。OCL是对象约束语言，以表达式的方式定义对其他模型元素的约束。OCL约束其他模型元素的行为和状态的变化
OCL由三部分构成，分别是：类型、表达式、保留关键字
类型：包括原始数据类型（Boolean、String、Integer、Real）、集合数据类型（Collection、Set、Bag）, 又包括专门针对UML模型的类型
表达式：表达式=操作符+操作数，“1+1=2″中，112是操作数，+=是操作符，或者是”f()+g()=t”，f()、g()、t也是操作数
保留关键字：有一张表
保留关键字 声明 and,or,not,xor 逻辑运算 If…then…else…endif 条件判断 package…endpackage 声明OCL的package环境 inv,pre,post 声明不变量、前置变量、后置变量 let…in 为后续单个表达式声明变量 def,attr,oper 为后续一定范围内多个表达式声明属性或操作 考试时候书写方式
第十五章 需求规格说明
1、规格说明的基本特征
指的是作用吗p>
- 把软件系统需求和解决方案给开发者
- 拓展人们的知识记忆能力
- 作为合同协议的重要一部分
- 作为项目开发活动的重要依据
- 发现和减少需求错误，减少项目返工，降低项目工作量
- 有效的智力资产
2、优秀规格说明的特点
需求规格说明文档是众多单一需求的集合，这些单一需求必须都是优秀的需求，即使整份文档满足正确性、无歧义、可验证三个特性。除了这三个特性以外，还需要满足其他特性，如
- 完备性（需求完备、有意义、包括功能、性能、约束和对外接口，实际情况的输入有响应等）
- 一致性（1、细节需求同高层需求不能冲突；2、同一层次需求不能冲突）
- 根据重要性和稳定性分级（知道哪条需求易变、哪条对用户重要）
- 可修改（文档要能够修改，且要维护修改记录）
第十六章 需求验证
1、需求验证方法（重要）
需求验证
- 两层含义：验证与确认。需求验证是指正确的得到需求，能作为软件创建基础的需求，需求确认是指得到正确的需求，能准确反映用户期望的需求。
需求验证的方法（六种必考）
- 需求评审
- 原型与模拟
- 涉及复杂的动态行为的需求，需要使用原型或模拟方法来验证
- 开发测试用例
- 用户手册编制
- 利用跟踪关系
- 业务的三个层次存在逐步细化的关系，基于细化关系来建立需求之间的跟踪关系
- 自动化分析
- 使用自动化分析工具来验证需求
第十七章 需求管理
1、需求管理有啥作用strong>
- 增强了项目涉众对复杂需求的掌握
- 增进了项目涉众之间的交流，减少了可能的误解
- 需求管理能有效处理需求变更，提高生产力
- 需求跟踪信息能准确反映项目的进展，帮助我们更好地进行决策
- 需求管理使涉众认识到需求在项目工作中的重要性
2、需求管理的三个主要任务点！年年考）
- 维护需求基线
- 交流涉众需要什么
- 驱动设计和实现工作
- 测试与验证最终产品
- 辅助项目管理
- 实现需求跟踪
- 将需求应用到解决方案
- 将需求分配到子系统
- 变更控制
- 控制迭代开发中的变化
3、如何做到变更控制事项有哪些strong>
需求的变化是不可避免的，正确的做法是在形成需求变更基线之后，进行需求的变更控制。 需求的变更控制就是以可控、一致的方式进行需求基线中需求的变更处理，包括对变化的评估、协调、批准或拒绝、实现和验证 。
注意事项：
- 要认识到变更的必要性，并为之制定计划
- 维护需求基线，审计变更记录
- 管理范围蔓延，对新增需求要评估
- 灵活应对变更请求，比如推迟交付时间、增加人手、加班加点
- 使用辅助工具，比如可以定义变更请求中的数据项，可以为审计变更做记录
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！