软件需求
软件需求:是指用户对系统在功能、行为、性能、设计约束等方面的期望。是指用户解决问题或达到目的所需要的条件或者能力,是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或者能力,以及放映这些条件或能力的文档说明。
软件需求管理分为需求开发和需求管理两大过程。

业务需求:
用户需求:
系统需求:
1)功能需求:
2)非功能需求:
3)设计约束:
质量功能部署(QFD)是
需求获取
需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。
常见的需求后去方法包括:
1)用户访谈:
2)问卷调查:
3)采样
4)情节串联版
5)联合需求计划(JRP)
6)需求记录技术
需求分析
需求分析:一个好的需求应该具有无二性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性,因此,需求分析人员要把杂乱无章的用户要求和期望转化为用户需求,这就是需求分析的工作。
需求分析的任务
1)绘制系统上下文范围关系图
2)创建用户界面原型
3)分析需求的可行性
4)确定需求优先级
5)为需求建立模型
6)创建数据字典
7)使用QFD(质量功能部署)
结构化的需求分析
结构化特点:自顶向下、逐步分解、面向数据。
三大模型:功能模型(数据流图)、行为模型(状态转化图)、数据模型(E-R图)以及数据字典。

状态流转图STD

数据流图描述数据在系统中如何被传送或变化,以及如何对数据流进行变化的功能或子功能,用于对功能建模,数据流图相关概念如图:
数据流图是可以分层的,从顶层(即上下文无关数据流)到0层、1层等,顶层数据流图只含有一个加工处理整个管理信息系统,描述了系统的输入和输出,以及和外部实体的数据交互。数据流图示例如下:
1)对象
2)类
3)抽象
4)封装
5)继承
6)多态
7)接口
8)消息
9)覆盖
10)函数重载
11)绑定
面向对象的分析
面向对象的分析是为了确定问题域,理解问题。包含五个活动:认定对象、组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信息。
面向相对需求建模:

统一建模语言UML
UML(统一建模语言)是一种可视化的建模语言,而非程序设计语言,支持从需求分析开始的软件开发的全过程
从总体上来看,UML的结构包括结构块、规则和公共机制三个部分。
1)构造块:UML有三种接触的构造块,分别是事物、关系和图。事物是UML的重要组成部分,关系把事物紧密联系在一起,图是过个相互关联的事物的集合。
2)公共机制:公共机制是指达到特定目标的公共UML方法。
3)规则:规则是构造块如何放在一起的规定。
事物分为:
结构事物
行为事物
分组事物
注释事务
关系:
依赖
关联
泛化
实现
UML 4+1视图

1)逻辑视图:逻辑视图也称为设计视图,它表示了设计模型中在架构方面具有重要意义的部分,即类、子系统、包和用例实现的子集。
2)进程视图:进程视图是可行性线程和进程作为活动类的建模,它是逻辑视图的一次执行实例,描述了并发和同步结构。
3)实现视图:实现视图对组成基于系统的物理代码的文件和构建进行建模。
4)部署视图:部署视图把构件部署到一组物理节点上,表示软件到硬件的映射和分部结构。
5)用例视图:用例视图就是最基本的需求分析模型。
需求定义
需求定义(软件需求规格说明书SRS)是需求开发活动的产物,编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解,使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一,对于任何规模和性质的软件项目都不应该缺少。
需求定义方法:
1)严格定义也称为预先定义,需要的严格定义建立在以下基本假设之上。所有需求都能够被预先定义。开发人员与用户之间能够准确且清晰地交流,采用图形或文字可以充分体现最终系统
2)原型方法:迭代的循环型开发方式。需要注意的问题:并非所有的需求都能够在系统开发前被准确地说明。项目干系人之间通常存在交流上的困难,原型提供了克服空难的一个手段。特点:需要实际的,可供用户参考的系统模型。有合适的系统开发方法环境。反复是完全需求和值得提倡的,需求一旦确定就应遵从严格的方法。
需求验证
需求验证也称为需求确认,目的是与用户一起确认需求无误。对需求规格说明书SAS进行评审和测试,包括两个步骤:
1)需求评审:正式评审和非正式评审
2)需求测试:设计概念测试用例
需求验收通过后要请用户签字确认,作为验收标准之一,此时,这个需求规格说明书就是需求基线,不可以随意更新,如果需要更改必须要走需求变更流程。
需求管理
定义需求基线:通过了评审的需求说明书就是需求基线。
需求变更和风险:主要关系需求变更过程中的需求风险管理,带有风险的做法有:无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不确定的估算。
变更产生的原因:外部环境的变化,需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。
变更控制委员会CCB:也称为变更控制委员会,其任务是对建议的配置变更做出评价、审批,以及监督已经批准变更的实施。
需求跟踪
双向跟踪两个层次如下:

正向跟踪表示用户原始需求是否都实现了,反向跟踪表示软件实现的是否都是用户要求的,不多不少,可以用原始需求和用例表格(需求跟踪矩阵)来表示。