软件需求工程--需求分析

需求特性

无二义性,完整性,一致性,可测试性, 确定性,可跟踪性,正确性,必要性。


需求分析的7个方面

绘制系统上下文范围关系图--系统与系统外部实体之间的界限和接口的简单模型

创建用户界面原型--关键界面接口示意图

分析需求的可行性--成本,性能,技术可行性。 发现需求之间的冲突和依赖

确定需求的优先级

为需求建立分析模型--一图抵千字, OOA的用例模型, 领域模型。 SA的DFD和ER

创建数据字典--所有数据项和结构定义

QFD


需求分析方法

PDOA方法(Problem Domain Oriented Analysis: 面向问题域分析方法)

与SA和OOA相比, PDOA更多的强调描述, 少强调建模

PDOA的两个部分

(1)关注问题域:对问题域进行相关的描述, 列出需要再该域中求解的问题列表(需求列表)

(2)关注系统实现的待求行为:对系统待求行为进行描述

PDOA过程

(1) 收集基本信息并开发问题框架, 以建立问题域的类型

(2) 在问题框架类型的指导下, 进一步收集详细信息, 并给出一个问题域相关的特性的描述

(3) 给予以上两点,收集并用文档说明系统的需求

SA方法(Structured Analysis 面向结构的分析方

关注功能的分层和分解, 符合自上而下,逐步分解问题, SA方法分析模型的核心是数据字典,围绕这个核心,有三个层次的模型

1. 数据模型  E-R图

2. 功能模型  DFD图 

3. 行为模型(状态模型) STD图 

      OOA方法(Object-Oriented Analysis:面向对象分析方法)

基于抽象,信息隐藏,功能独立和模块化的基本理念对系统进行分析。

OOA,对象彼此之间通过接口来互相沟通,只有观测内部才能看到具体的属性和方法。

需求验证:

SRS正确的描述了预期的,满足项目干系人需求的系统行为和特征

SRS中的软件需求是从系统需求,业务规格和其他来源中正确推导而来

需求是完整的和高质量的

需求的表示在所有地方都是一致的

需求为继续进行系统设计,实现和测试提供了足够的基础


需求评审:

评审方式: 评审, 检查,走查

如何做好评审推荐方法如下

分层评审

正式评审和非正式评审相结合

分阶段评审

精心挑选评审人员

对评审人员进行培训

充分利用需求评审检查单

建立标准的评审流程

做好评审后的跟踪工作

充分准备评审

需求测试:

很多项目中, 软件测试都是后期的开发活动, 实际上,软件测试在需求定会就应该开始。

如果在项目早期就定制测试计划进行测试用例设计,就可以发送错误时立即检测并纠正他。

需求遗漏和错误具有很强的隐蔽性, 仅仅通过阅读SRS,很难想象特定环境下的系统行为。

概念测试用例:

需求开发不可能有真正意义的测试进行, 因为没有可执行的系统, 需求测试仅仅是给予需求进行概念上的测试

以需求为基础(SA需求分析模型)或用例为基础(OOA需求分析模型)来书写测试用例, 可以是项目干系人更清楚

的了解系统的行为,虽然没有执行测试用例,但是设计测试用例的简单动作可以解释需求的很多问题。

需求测试的过程:

1. 根据概念测试用例所描述的若干可能过程, 进行“概念”上的执行,期望发现遗漏的,错误的, 不必要的需求

2. 根据测试结果快速的修改对应的需求文档,完成一轮完整的需求测试过程。


需求获取,需求分析,需求定义,需求验证 4个阶段,不应该是瀑布式的发展,应该采用迭代式的演化过程。


需求管理

需求管理是可重复级的一个关键过程域, 其目标是为软件需求建立一个极限, 供软件开发及其管理使用,

使得软件计划,产品,活动与软件需求保持一致。其中有如下几个活动

1. 需求变更管理

2. 需求风险管理

3. 需求跟踪--设计跟踪矩阵, 各种测试用例跟踪矩阵,缺陷跟踪矩阵。



你可能感兴趣的:(读书笔记,项目管理)