软件需求是软件开发人员在开发软件产品之前应该做的事情。
导致软件开发失败的因素中有三条最重要的原因，他们所占失败因素比例超过了三分之一。分别是：
- 缺少用户的输入：占软件失败因素13%
- 不完整的需求和规格说明书：占软件失败因素12%
- 需求和规格说明书的变更：占软件失败因素12%
定义
- 确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景
- 需求就是以一种清晰、简洁、一致且无二义性的方式，对一个待开发系统中各个有意义方面的陈述的一个集合
特点
- 多样性：并非所有都是需求
- 变化性：需要挖掘
要求
- 可验证性
- 有优先级
- 可量化
- 折中
分析过程
🌟理解与分析问题及环境，涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化、最终形成需求规格说明的一系列活动
- 建立分析模型：准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。
- 编写需求说明：用 <需求规格说明书> 规范的形式准确地表达用户的需求。
需求分析原因
-
希望对开发进行指导
-
希望开发人员对用户的要求理解
-
希望用户理解开发人员
-
测试部门有理可依
- 需求获取
- 需求提炼
- 需求描述
- 需求验证
软件需求获取指的是软件需求的来源以及软件工程师收集这些软件需求的方法。它也称为需求抓取、需求发现和需求获得
需求类型
-
功能性需求：描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务
-
非功能需求：必须遵循的标准，外部界面的细节，实现的约束条件，质量属性等等
非功能需求限定了选择解决问题方案的范围，如运行平台、实现技术、编程语言和工具等
需求获取技术
- 向系统相关者进行问卷调查
- 主持与用户的面谈和讨论
- 需求专题讨论会
- 复查现有的报表、表格和过程描述
- 观察商业过程和工作流
- 应用用例
- 建立原型
面临挑战
- 客户说不清楚需求
- 需求易变性
- 问题的复杂性和对问题空间理解的不完备性与不一致性
对应用问题及环境的理解和分析，为问题涉及的信息、功能及系统行为建立模型。将用户需求精确化、完全化，最终形成需求规格说明书。
- 需求分析的核心在于建立分析模型
- 需求分析采用多种形式描述需求，通过建立需求的多种视图，揭示出一些更深的问题。
- 需求分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要，其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。
- 结构化分析模型
- 面向对象分析模型
- 分析模型描述工具
- 数据流图、数据字典和加工规约
- CFD、控制规约和状态变迁图
- E-R图
- 用例图，对象-关系图，对象-行为图
结构化思维
软件工程学科中一种典型的分析系统、设计系统的思维方法，采用系统科学思想、依据层次分解、自顶向下分析和设计系统
系统论基础
- 作用性：有目标的
- 外特性：有边界的
- 内特性：有组成要素且相互关联
- 复杂度：组成要素多、且关系复杂
控制论基础
- 物理系统
- 控制系统
- 通常为计算系统，接收来自物理系统的数据及状态，进行决策并下达指令控制物理系统的运行
分解论基础
- 化简复杂系统的简单方法是分解，将系统分解为不同的部分，各个击破
- 分解、再分解，直到清楚为止
功能描述
- 功能：将输入转换为输出的一种变换过程，宏观称功能、微观称活动
- 输入：从功能外传入功能内的信息
- 输出：从功能内传入功能外的信息
- 目标与控制：功能应该达到的目标，即在“目标与控制”的控制下执行
- 支撑：执行功能或活动所需的必要支撑条件
功能分解
- 功能分解:上层功能被分解为若干个下层功能
- 子功能：描述每个子功能的输入输出控制描述
- 子功能关系：建立子功能之间的关系，一个子功能的输出可能是另一子功能的输入或控制
- 子功能数量，不是越多越好，要恰当
- 功能=子功能集合+子功能IOCS集合+子功能关系集合
- 自顶向下、逐层分解，由粗至细
- 将复杂系统刻画清楚
需求分析特点
- 多样性
- 功能与过程：功能分解、流程
- 构件与结构性：不同结构具有不同性能
- 产品需求与过程需求：过程需求为软件开发上的约束
- 功能性需求与非功能性需求
- 综合性/系统性需求
- 定性需求与定量需求
- 系统需求与软件需求：系统需求通常为环境要求
- 解决多样性需求方法
- 多视角多层次分析理解
- 视角：what(data)，how(function), where(networks), who(people), when(time), why(motivation)
- 层次：0，1，2，3，4，……
软件需求规格说明书（SRS）------软件系统的需求规格说明，是对待开发系统的行为的完整描述。他包含了功能性需求和非功能性需求
- 需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书
- 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础
需求规格说明原则
- 从现实中分离功能，即描述要“做什么”而不是“怎样实现”
- 要求使用面向处理的规格说明语言（或称系统定义语言）
- 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中
- 规格说明必须包括系统运行环境
- 规格说明必须是一个认识模型
- 规格说明必须是可操作的
- 规格说明必须容许不完备性并允许扩充
- 规格说明必须局部化和松散耦合
如果在后续的开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工。由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大的多
对需要文档检查
- 有效性检查
- 检查不同用户使用不同功能的有效性
- 一致性检查
- 在文档中，需求不应该冲突
- 完备性检查
- 需求文档应该包括所有用户想要的功能和约束
- 现实性检查
- 检查保证能利用现有技术实现需求
需求验证技术
-
需求评审
由分析员、设计员、测试员、用户参与的正式或非正式的会议评审。正式会议要有严格的评审程序，要有会议记录，开发组根据缺陷建议修改需求说明并重审
-
利用原型检验系统是否符合用户的真正需要
-
对每个需求编写概念性的测试用例
-
编写用户手册。用浅显易懂的语言描述用户可见的功能
-
自动的一致性分析。可用CASE工具检验需求模型的一致性
需求变更管理
管理和控制需求基线的过程
需求变更控制系统
- 一个正式的文档，说明如何控制需求变更
- 建立变更审批系统
软件需求贯穿于软件工程的整个生命周期
软件需求：用户对目标软件系统在功能、行为、性能、设计约束等方面的期望
需求分析的任务建立需求分析模型和编写需求说明
- 描述需求分析中用例图的缺点
- 需求分析主要的步骤是什么？
- 需求获取
- 需求提炼
- 需求描述
- 需求验证
- 给出功能和非功能性需求的例子。
- 在产品需求和过程需求中的不同点是什么？
- 请举出一些需求分析的主要来源。