目录
4.3文档模板内容撰写说明（应该不是很重要，主要是没找到在哪儿）
软件需求获取基础
软件危机：
- 用户需求不明确
- 软件规模越来越大
- 软件开发复杂度越来越高
- 缺乏正确的理论指导
1.2.1 软件需求的分类
功能性需求：
- 业务需求:描述组织或客户的高层次目标，实现项目或系统目标
- 用户需求：指用户使用产品必须要完成什么任务，怎么完成需求。
- 系统需求：是用户对系统行为的期望，一系列的系统需求联系在一起，帮助用户完成任务，达成用户需求，进而满足业务需求。
非功能需求：
- 性能需求：精度、时间特性要求、灵活性、并发性、故障处理需求
- 质量属性：功能性、可靠性、易用性、效率、维护性、可移植性
- 对外接口：使用者、内容与格式、设计约束与要求
约束：表格法、条目文本、部署图
优秀需求的特点
完整性、正确性、可行性、必要性、无歧义性、有优先次序性、可验证性
需求定义的错误
需求并没有准确反应用户的真实需要、需求定义模糊、需求信息不完整
需求工程
重点：需求工程的过程（p13
- 需求获取
- 需求分析
- 需求规格说明（需求文档化）
- 需求验证
- 需求管理
重点：需求工程师需要具备的技能要求
- 计算机专业技能
- 沟通能力
- 协调能力
- 文档编写能力
- 创新能力
2、需求获取
基本概念
- 什么是软件需求获取（p18
软件需求获取是软件开发的第一个阶段，主要涉及软需求工程师如何与客户建立有效沟通，是从需求来源获取需求的技术，是一个确定和理解不同用户类的需要和限制的过程。
- 软件需求获取在需求工程中的地位
- 软件开发时，需求获取是最关键的环节，是需求方和需求获取方就项目沟通协商最终确定需求方案的过程。
- 软件需求获取是软件需求工程的主体。
- 软件需求获取可能是软件开发过程中最困难、最关键、最易出错及最需要交流的阶段。
- 需求获取结果（p19
- 前景与范围文档
- 用例说明文档
- 软件需求规格说明文档
需求获取的活动过程
需求获取的内容
三大类：需求本身、业务描述、环境和约束（p20
确定获取需求的来源(p21-22
- 涉众
重点：涉众分析
涉众识别、涉众描述、涉众列表、涉众扩展描述、涉众评估、涉众选择
- 硬数据
- 相关技术标准和法规
- 重要文档
需求获取的方法
重点：传统方法（p23
面谈法
面谈法的优点
①开展面谈的条件简单，经济成本低。
②能获得包括事实、问题、被会见者观点、态度、信仰等各类信息，内容广泛。
③通过面谈，需求工程师可以和涉众间建立友好关系。
面谈法的缺点
①面谈比较耗时。
②被会见者地理分散情况下难以实现面谈。
③面谈对需求工程师的人际交往能力要求高。
④态度偏见、潜在知识、默认知识、表述不清等各种问题不可避免地影响面谈结果。
⑤会见者不了解被会见者认知结构的情况下，面谈结果将比较糟糕。
原型法
原型法的基本概念：原型法是指在获取一组基本的需求定义之后，利用高级软件工具可视化的开发环境，也即是模拟一个系统。
原型的特征：它具有以下特征。
- （1）它是一个可实际运行的系统。
- （2）它没有固定的生存期。一种极端是扔掉原型(以最简便方式大量借用已有软件，做出最后产品的模型，证实产品设想是成功的，但产品中并不使用);另一种极端是最终产品的部分即增量原型(先做出最终产品的核心部分，逐步增加补充模块)，演进原型居于其中(每版本扔掉一点，增加一点，逐步完善至最终产品)。
- （3）从需求分析到最终产品都可作原型，即可为不同目标作原型
- （4）它必须快速、廉价。
- （5）它是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可。
优点
- 符合人们认识事物的规律，系统开发循序渐进，鼓励用户积极参与，有助于解决用户之间的差异。
- 能给用户一个对最终系统的直观感受；开发周期短，成本相对低。
- 反复修改，确保较好的用户满意度。
- 由于有用户的直接参与，系统更加贴近实际。
- 易学易用，减少用户的培训时间。
- 应变能力强。
缺点
- 不适合大规模系统的开发；
- 开发过程管理要求高，整个开发过程要经过“修改—评价—再修改”的多次反复；
- 用户过早看到系统原型，误认为系统就是这个模样，易使用户失去信心；
- 开发人员易将原型取代系统分析；
- 缺乏规范化的文档资料。
-
模型驱动法
-
基于上下文法
-
认知方法
-
调查法
-
现场观摩法
非传统的方法：基于知识的方法，基于观点的方法（看看就ok）
确定项目前景和范围（p28-33
- 业务需求
- 前景与范围
- 系统边界
- 前景与范围文档的编写
需求分析
3.1需求分析概述
- 需求分析做什么（P65
分解、提炼、消除矛盾三个方面。
- 分解采用自顶向下
- 提炼采用自底向上
- 解决出现的矛盾
-
建模的目标与要点
目标：
（1）帮助需求分析员按照实际情况或按需要的样式对系统进行可视化。
（2）提供一种详细说明系统的结构或行为的方法。
（3）给出一个指导系统构造的模板。
（4）对需求分析所做出的决策进行文档化。
要点：
（1）设计要考虑到计划之外的变化。
（2）设计要文档化。
（3）用可视化的模型表达架构，有助于理解变化所代表的含义。
需求阶段常用的工具
-
建模工具UML（查看ppt）
结构化分析方法（P69-p82）重点！！！
- 数据建模：ERD
- 过程建模：DFD（数据流图）
数据流图Data Flow Diagram
DFD由四种基本符号组成：
A.外部项（外部实体）（S)
B.加工(P)
C.数据流(D)
D.数据存储（文件）(F)P71
- 行为建模：状态图/矩阵
- 过程/数据关系建模：功能实体矩阵
- 信息工程法：功能分解图和过程依赖图
面向对象分析方法
业务建模（活动图）
活动图符号
7.分叉/结合
8.对象流
9.扩展区域
如何绘制活动图（学习通视频）
用例建模（用例图）
用例图组成元素：
- 参与者
- 用例
- 元素之间的关系
用例描述（看ppt）
如何绘制用例图（回顾作业＋ppt）
面向对象分析过程中主要使用的工具
用例图
类图
交互图
活动图
状态图
对象约束语言
面向问题域分析方法
OOA的大致方法是标识出问题域中的对象类；定义这些类的属性和方法；定义这些类的行为；对这些类之间的关系建模。
需求规格说明文档
4.1编写的目的（重点）
- 帮助记忆
- 帮助发现需求存在的问题
- 使文档记录成为解决方案
- 为后续活动提供依据
- 成为协议的基准
4.2文档模板的选择与裁剪
4.3文档模板内容撰写说明（应该不是很重要，主要是没找到在哪儿）
4.4文档撰写
撰写注意事项
撰写特点
需求验证
5.1需求验证概述（p143
需求验证、系统验证、需求确认、系统确认
需求验证是需求工程过程中发生的验证活动，主要观察需求是否正确和充分地表达了涉众的需要。
需求验证要确保需求的正确性、完备性、一致性。要确保需求的技术可行性。
5.2需求验证过程
需求验证的过程，就是在软件需求规格说明文档完成后，对文档采用相应的验证方法进行验证，发现问题，并提出修改建议，在问题修正后，继续验证，继续发现问题，同时提出修改建议，重复该过程，直到需求被用户确认。
5.3需求验证的方法（p143-149 （重点）
需求管理
6.1需求管理概述
需求管理是一种用于查找、记录、组织和跟踪需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统变更上达成并保持一致。需求管理主要包括维护需求基线、实现需求跟踪和控制需求变更等阶段。
作为需求开发的结果，最终的需求被明确和固定下来并传递给其他的项目成员，该需求集合即为需求基线。需求基线在建立后并非是一成不变的，在产品开发中以及产品使用之后，用户等产品涉众仍然会提出需求的变更，这些变化都要及时、一致的反映到需求基线中。
需求跟踪是一种有效的控制手段，它能够在涉众的需求变化中协调系统的演化，保持各项开发工作对需求的一致性，避免软件系统在开发过程或者演化过程中发生与需求基线不一致和偏离的风险越来越大。
需求变更控制以可控制的方式进行需求基线中需求的变更处理，包括对变化的评估、协调批准或拒绝、实现和验证，它是以一种可控制的严格的过程方式来执行需求的变更，从在控制产品生命周期成本的同时，还可以提供最高的客户价值和业务价值。
6.2需求基线
需求基线的定义为：已经通过正式评审和批准的规格说明或产品，可作为进一步开发的基础，而且只有通过正式的变更控制过程才能修改它。
软件需求是需求基线的关键内容。
6.3需求跟踪
6.3.1需求跟踪的方式
它分为前向跟踪和后向跟踪两种方式。
6.3.2需求跟踪的必要性
6.3.3需求跟踪能力联系链
6.3.4需求跟踪的方法
6.4控制需求变更
6.4.1需求变更的原因（重点）
6.4.2需求变更的应对策略
6.4.3变更控制的过程与涉众
6.4.4需求变更控制过程的注意事项（重点）
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
