课程内容提要
概述
需求基线：经过确认的计划
B
B
需求分类
软件需求、硬件需求、网络需求
用户需求是偏操作的需求，系统需求是系统的界面，实现等的需求。
非功能需求：如性能需求、安全性、可靠性
设计约束：开发语言约束、信创等
兴奋需求从项目管理上来说是坚决不要做的，会消耗项目资源也不一定可以提高客户满意度。如何区分期望需求和兴奋需求，这就需要通过原型来挖掘客户的需求。
性能指标：响应时间，吞吐率等可量化的指标，因此这里可以排除性能指标
1是一个用户操作角度的描述，因此是用户需求
2的前半部分（显示提供替换词的对话框）是用户操作角度的描述，看上去是用户需求，但是后半部分是功能的描述，因此这里看做是一个功能需求
3是最笼统的描述，表明业务需要，因此是业务需求（抽象层次最高）
BCA
需求获取
用户访谈：开放式问题（案例、论文） 与 封闭式（选择题） 问题相结合
联合需求计划：会议形式获取需求，因此成本较高
情节串联法：原型
用户访谈或联合需求计划（会议）或问卷调查，故选C
现场观摩或参加业务实践，故选D
需求分析
结构化需求分析：数据流图（DFD）、实体联系图（ER）
面向对象需求分析：UML、用例模型、类模型
结构化需求分析
以数据流图为核心
数据流图
分层数据流图，自顶向下，逐步分解求精
外部实体可以是一个外部系统，比如这里的培训部，辅导老师
父图与子图的平衡：指任何一张DFD子图边界上的输入/输出数据流必须与其父图对应加工的输入/输出保持一致。
子图内平衡：黑洞、奇迹、灰洞
1.加工只有输入没有输出，即黑洞
2.加工只有输出没有输入，即奇迹
3.加工输入不足以产生输出，即灰洞
状态转换图
实体联系(ER)图
实体、联系。属性
例题
A A
A B
面向对象需求分析
实体类：对应数据表，如学生表-学生-实体类
边界类：接口性质，跟外界打交道的
A C
UML
统一建模语言
AD
注意区分静态/动态图以及各自的特点
定时图：定时任务 顺序图的时间顺序是相对的
重点考核用例图和类图
包含关系和扩展关系可以笼统的概括为依赖关系。
包含关系在UML1.0又称为使用关系
D
使用关系 === 包含关系
include(包含) extend(扩展) generalize(泛化) call(调用)
李氏替换原则：子类可以替换父类（因为 子类拥有父类的所有功能，因此可以用子类替换父类）
依赖关系是类图中的关系，见《类图与对象图》章节
D B C
类图与对象图
泛化关系中的特殊/一般关系就是子类与父类的关系
聚合关系 - 汽车和轮子（轮子可以用到其他汽车上）
组合关系 - 公司与部门（部门是公司的一部分，不可分割）
实现关系：一个类可以实现多个接口（PPT图片里面上面的画错了，是下面的那种虚线箭头）
多重度表示2者的关系，一对多，一对一，多对一
DC
顺序图
定时图
核心就是状态转换+时间因素
活动图
活动图的另外一种画法：泳道图
状态图
S1: 订单挂起 S2：订单备货 S3：订单定制 S4：订单发货 S5：订单收货
通信图(协作图)
和顺序图类似，强调收发对象，不强调时间顺序
构件图
部署图
圆圈代表构建接口
例题
AB
排除所有静态图，故选B
活动图和结构化里面的程序流程图是一样的一种结构，因此用来描述算法流程是合适的，故选A
CDA
需求建模
细化用例模型如下图：
C
判断哪些工作归属分析阶段，哪些工作归属于设计阶段
B
系统范围之外的名词可以删除，只考虑系统范围内
不具备独特行为的名词可以删除，这个没有解释，我的理解是系统内没有行为或行为单一的部分，如图书管理系统的图书管理员
一个对象的同义词可以删除，冗余
C
A D
需求包括业务层级、系统层级、用户层级。我们会通过需求分析得到系统的功能和非功能层级的需求
数据流（未处理的）、信息流（加工处理后的）、控制流
D
框架的范围比类大
做题思路：先看问题，再看试题题干说明
什么样的事物可以充当参与者？
人、组织、外部系统、时间等系统的触发因素
用例图的绘制如下：
需求定义
严格定义法：瀑布模型的思想
软件需求规格说明书（SRS）：需求定义的产生物
需求验证
课外知识：合同是有多种类型的，如固定总价、成本补偿等。国内主流的合同类型是固定总价，只适用于需求明确的项目，对于现在主流的需求都是较难明确下来的，因此留下了隐患。对于客户不签字确认的情况，需要事前做好会议纪要，需求规格说明书以及确认验收标准等方式尽量规避。
需求管理
定义需求基线
完成需求验证会形成需求基线
上面是一个需求状态变迁图2
需求跟踪
用例是用于系统开发的，如果原始需求里面没有而用例里面有，说明这是一个兴奋需求，如果原始需求里面有而用例没有的话，说明这是一个遗漏的需求。
C
需求风险管理
SRS: 需求规格说明书
练习题
试题答案解析：
问题1：
数据流图作为一种图形化工具，用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。
流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述处理过程的控制流。
两者的区别主要包括：
(1) 数据流图中的处理过程可并行；流程图在某个时间点只能处于一个处理过程。
(2) 数据流图展现系统的数据流；流程图展现系统的控制流。
(3) 数据流图展现全局的处理过程，过程之间遵循不同的计时标准；流程图中处理过程遵循一致的计时标准。
(4) 数据流图适用于系统分析中的逻辑建模阶段；流程图适用于系统设计中的物理建模阶段。
问题2： 如图所示的数据流图中存在的错误有以下4种：
(1) “分类训练”加工：只有输入没有输出，产生数据黑洞；
(2) “分类处理”加工：只有输出没有输入，无中生有；
(3) “规则文件”数据流：外部实体没有经过加工处理，直接到数据存储;
(4) “配置信息”数据流：外部实体之间没有加工处理，存在直接数据流。 
问题3： 髙质量数据流图设计时应考虑的三个原则：
(1) 复杂性最小化原则。DFD（数据流图）分层结构就是把信息划分为小的且相对独立的一大批子集例子，这样就可以单独考查每一个DFD。如果要了解某个过程更加详细的信息，可以跳转到该过程的下一层；如果要知道一个DFD如何与其他DFD相关联，可以跳转到上一层的DFD进行考査。
(2) 接口最小化原则。接口最小化是复杂性最小化的一种具体规则，在设计模型时，应使得模型中各个元素之间的接口数或连接数最小化。
(3) 数据流一致性原则。一个过程和它的过程分解在数据流内容中是否有差别？是否存在有数据流出但没有相应的数据流入的加工？是否存在有数据流入但没有相应的数据流出的加工？
问题3见需求获取章节
试题答案解析：
【问题1】
答：联合需求计划(JRP)是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是由企业主管部门经理、会议主持人、用户、协调人员、IT人员、秘书等共同组成的专题讨论组来分析、讨论问题并定义系统需求。
JRP和其他需求获取方法相比的优势：
(1)发挥用户和管理人员参与系统幵发过程的积极性，提高系统开发效率：
(2)降低了系统需求获取的时间成本，加速系统开发周期；
(3)采用原型确认系统需求并获取设计审批，具有原型化开发方法的优点。
【问题2】
答：（a）文档分析或实地观察 （b）用户访谈或联合需求计划
（c）用户访谈或联合需求计划（d）问卷调査或文档分析（前面有多种人员，后面是文档）
（e）联合需求计划 （f）联合需求计划（看题干感觉问卷调查似乎更合理，只能说题干不清晰吧，如果人数过多，JRP就不适合了）
【问题3】
答：样本数量=0.25*(可信度因子/可接受误差)2
所以，抽取的样本数量=0.25*(1.645/0.1)2≈68份。
历年考到的需求分析的知识点
本文链接： http://www.ionluo.cn/blog/posts/bb6b18c8.html
版权声明： 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处！
