项目管理之信息系统开发基础(一、需求分析)

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zl834205311/article/details/80322778

    软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。

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. 需求跟踪--设计跟踪矩阵, 各种测试用例跟踪矩阵,缺陷跟踪矩阵。







阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页