157 lines
3.5 KiB
Markdown
157 lines
3.5 KiB
Markdown
---
|
||
title: 软件需求
|
||
date: 2023-04-12 20:07:02.2
|
||
updated: 2023-04-12 20:07:02.2
|
||
url: /archives/ruanjainxuqiu
|
||
categories:
|
||
- 软件测试
|
||
tags:
|
||
- 测试基础
|
||
---
|
||
|
||
## 需求工程
|
||
|
||
### 需求开发
|
||
|
||
- 需求获取
|
||
|
||
从用户那里获取原始需求，即用户的真实想法
|
||
|
||
- 需求分析
|
||
|
||
将用户的需求具体化或者条目化
|
||
|
||
- 需求定义
|
||
|
||
将分析出来的需求写成需求规格，完成需求规格说明书（SRS）
|
||
|
||
- 需求验证
|
||
|
||
需求人员通过一些原型工具，把确定好的需求实现成一个界面，演示给用户看，进行确认验证
|
||
|
||
### 需求管理
|
||
|
||
- 需求分配
|
||
|
||
分配给多个需求人员协同一起进行需求分析
|
||
|
||
- 需求评审
|
||
|
||
保证项目组所有人对需求的理解是一致的，保证 需求从设计角度和测试角度都是可以实施的
|
||
|
||
- 需求基线
|
||
|
||
评审后的需求规格作为标准文档供项目组成员使 用，保证大家拿到的需求规格是一致的、完整的
|
||
|
||
- 需求跟踪
|
||
|
||
保证设计和测试是按照需求规格来的
|
||
|
||
- 需求变更
|
||
|
||
项目过程中对需求规格进行修改的过程
|
||
|
||
## 需求规格说明书内容
|
||
|
||
- 产品环境介绍
|
||
- 软件在什么环境下使用
|
||
- 搭建什么配置的测试环境
|
||
- 用户特征
|
||
- 软件给谁用
|
||
- 测试人员需根据这些用户特征，站用户的角度而 去考虑如何测试
|
||
- 假设和依赖关系：开发语言、开发环境
|
||
- 用户接口
|
||
- 功能需求：软件的基本功能
|
||
- 性能需求
|
||
- 技术限制
|
||
- 软件接口：与外部软件的接口（软件模型中的互操作性）
|
||
- 标准符合性：软件质量模型中的功能性依从性
|
||
- 需求分级
|
||
- 螺旋模型可以根据需求分级来确定哪些功能先做
|
||
- 测试用例的重要级别和需求分级相关
|
||
|
||
## 同行评审
|
||
|
||
来源于IBM
|
||
|
||
**目的**：用于检查研发工作成果是否有问题
|
||
|
||
**常见的工作成果物**
|
||
|
||
- 管理类
|
||
- 项目计划
|
||
- 软件开发计划
|
||
- 软件测试计划
|
||
- 技术类
|
||
- 需求规格
|
||
- 概要设计、详细设计、代码
|
||
- 测试方案、测试用例、测试报告
|
||
- 程序、用户手册、帮助文档
|
||
|
||
**分类**
|
||
|
||
- 正规检视：仅针对基础性的技术类工作成果物
|
||
- 技术评审会议
|
||
- 管理类工作成果物
|
||
- 测试的工作成果物
|
||
- 走查（邮件审核）：代码、用户手册、帮助
|
||
|
||
## 需求评审
|
||
|
||
**角色和职责**
|
||
|
||
被评审工作成果物相关的人
|
||
|
||
项目经理、设计人员、测试人员、用户
|
||
|
||
**评审流程**
|
||
|
||
1. 需求提交SRS
|
||
|
||
2. 项目经理确定评审专家并提供SRS、评审表单、评审checklist
|
||
|
||
（可选）需求较复杂或不好理解可召开介绍会议
|
||
|
||
3. 评审专家评审并提供评审反馈
|
||
|
||
4. 项目经理汇总评审反馈给需求
|
||
|
||
5. 组织评审会议，需求逐一确认每条评审意见
|
||
|
||
（可选）针对评审意见可召开第三小时会议
|
||
|
||
6. 需求人员确认评审意见后修改需求规格
|
||
|
||
7. 评审专家确认修改是否正确
|
||
|
||
8. 最后需求规格正式发布
|
||
|
||
## 需求跟踪
|
||
|
||
开发：需求项-模块-函数-代码
|
||
|
||
测试：需求项-测试项-测试用例-缺陷
|
||
|
||
**作用：**
|
||
|
||
避免有些需求被遗漏
|
||
|
||
需求变更时能很快确定哪些地方需要同步修改
|
||
|
||
## 需求变更
|
||
|
||
**变更原因**
|
||
|
||
- 用户需求变化
|
||
- 缺陷导致
|
||
- 需求跟踪引起
|
||
|
||
**变更流程**
|
||
|
||
1. 需求发起变更请求
|
||
2. CCB审核是否变更（基于成本和进度影响）
|
||
3. 如果能变更，开发给出变更方案1、技术能否实现，2、时间进度影响
|
||
4. 评审变更方案
|
||
5. 需求人员修改需求
|
||
6. 重新进行需求评审流程
|
||
7. 评审通过，需求跟踪 |