软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。
1,需求的层次
1)业务需求;
2)用户需求;
3)系统需求;
2,质量功能部署(QFD)
一种可以将用户需求转化为软件需求的技术,QFD将需求分为三类,常规需求,期望需求和意外需求。
3,需求获取
需求获取是一个确定和理解不同的项目干系人的需求和约束的过程,常见的需求获取方法包括,用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
4,需求分析
1)PDOA方法(Problem Domain Oriented Analysis: 面向问题域分析方法)
与SA和OOA相比, PDOA更多的强调描述, 少强调建模
PDOA的两个部分
(1)关注问题域:对问题域进行相关的描述, 列出需要再该域中求解的问题列表(需求列表)
(2)关注系统实现的待求行为:对系统待求行为进行描述
PDOA过程
(1) 收集基本信息并开发问题框架, 以建立问题域的类型
(2) 在问题框架类型的指导下, 进一步收集详细信息, 并给出一个问题域相关的特性的描述
(3) 给予以上两点,收集并用文档说明系统的需求
2)SA方法(Structured Analysis 面向结构的分析方法)
关注功能的分层和分解, 符合自上而下,逐步分解问题, SA方法分析模型的核心是数据字典,围绕这个核心,有三个层次的模型
1. 数据模型 E-R图
2. 功能模型 DFD图
3. 行为模型(状态模型) STD图
3)OOA方法(Object-Oriented Analysis:面向对象分析方法)
基于抽象,信息隐藏,功能独立和模块化的基本理念对系统进行分析。
OOA,对象彼此之间通过接口来互相沟通,只有观测内部才能看到具体的属性和方法。
5,软件需求规格说明书(功规,SRS)
国标规定SRS需要包含以下内容
1)范围
2)引用文件
3)需求
4)合格性规定
5)需求可追踪性
6)尚未解决的问题
7)注解
8)附录
6,需求验证
包括以下内容:
1)SRS正确的描述了预期的,满足项目干系人需求的系统行为和特征
2)SRS中的软件需求是从系统需求,业务规格和其他来源中正确推导而来
3)需求是完整的和高质量的
4)需求的表示在所有地方都是一致的
5)需求为继续进行系统设计,实现和测试提供了足够的基础
7,UML(Unified Modeling Language又称统一建模语言或标准建模语言)
1)UML的结构
①构造块 事物(thing)、关系(relationship)
②规则
③公共机制
2)UML中的事物
①结构事物
②行为事物
③分组事物
④注释事物
3)UML中的关系
①依赖关系
②关联
③泛化
④实现
4)UML2.0中的图
①类图
②对象图
③构件图
④组合构件图
⑤用例图
⑥顺序图
⑦通讯图
⑧定时图
⑨状态图
⑩活动图
⑪部署图
⑫制品图
⑬包图
⑭交互概览图
5)UML视图
①逻辑视图
②进程视图
③实现视图
④部署视图
⑤用例视图
8,需求评审:
评审方式: 评审, 检查,走查
如何做好评审推荐方法如下
分层评审
正式评审和非正式评审相结合
分阶段评审
精心挑选评审人员
对评审人员进行培训
充分利用需求评审检查单
建立标准的评审流程
做好评审后的跟踪工作
充分准备评审
9,需求测试(6,需求验证,详细化):
很多项目中, 软件测试都是后期的开发活动, 实际上,软件测试在需求定会就应该开始。
如果在项目早期就定制测试计划进行测试用例设计,就可以发送错误时立即检测并纠正他。
需求遗漏和错误具有很强的隐蔽性, 仅仅通过阅读SRS,很难想象特定环境下的系统行为。
概念测试用例:
需求开发不可能有真正意义的测试进行, 因为没有可执行的系统, 需求测试仅仅是给予需求进行概念上的测试
以需求为基础(SA需求分析模型)或用例为基础(OOA需求分析模型)来书写测试用例, 可以是项目干系人更清楚
的了解系统的行为,虽然没有执行测试用例,但是设计测试用例的简单动作可以解释需求的很多问题。
需求测试的过程:
1. 根据概念测试用例所描述的若干可能过程, 进行“概念”上的执行,期望发现遗漏的,错误的, 不必要的需求
2. 根据测试结果快速的修改对应的需求文档,完成一轮完整的需求测试过程。
需求获取,需求分析,需求定义,需求验证 4个阶段,不应该是瀑布式的发展,应该采用迭代式的演化过程。
10,需求管理
需求管理是可重复级的一个关键过程域, 其目标是为软件需求建立一个极限, 供软件开发及其管理使用,
使得软件计划,产品,活动与软件需求保持一致。其中有如下几个活动
1. 需求变更管理
2. 需求风险管理
3. 需求跟踪--设计跟踪矩阵, 各种测试用例跟踪矩阵,缺陷跟踪矩阵。