软件需求分析-0-Intro

Posted 2021-10-16 MREQ#

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件需求分析-0-Intro相关的知识，希望对你有一定的参考价值。

什么是需求？

==需求==是对我们应当==执行的任务==的规范说明。
它描述系统的行为特性或属性，可以是一种系统开发进程的约束。
需求涵盖：
来自客户视角的外部系统行为
来自开发人员视角的一些内部特征
几个概念：
- ==业务需求== 客户所需的高层次业务目标
- ==用户需求== 使用产品的用户完成的任务和目标
- ==功能需求== 开发人员需要实现的功能以便用户完成任务
- ==系统需求== 包含多个子系统的产品的顶层需求
- ==非功能需求== 系统必须展现的属性/特性/必须遵守的约束。
  - eg. 系统的安全性/易用性/性能
- ==业务规则== 策略、纲领、标准、制度
  - eg.个调税计算规则
- ==特性== 单个或多个为用户提供价值的、有逻辑关系的系统性能，可以通过一个功能需求集合进行描述。如自动升级

需求在软件项目中扮演的角色

准确判断开发什么是开发软件系统最困难的部分
确定详细的技术需求是最难的概念性工作
- 包括所有面向用户、机器和其他软件系统的接口
需求迭代
- 不会/没必要在开始设计&执行之前，就指定全部功能需求
敏捷开发的精髓
- 充分理解需求，制定周全的优先级排序和发布计划，尽快交付
软件需求文档的核心问题
- 核心问题不在于写需求，而在于判断需求。
- 写需求只是对自己所了解的内容进行分类、阐述和记录。
- 只有对产品需求有充分的认识，团队才能正确处理问题，并针对问题设计开发出最佳的解决方案，获得用户认可。

软件需求工程
- 需求管理
- 需求开发
  - 需求获取
  - 需求分析
  - 规范说明
  - 需求验证

软件需求开发

1、需求获取

需求开发的核心是需求的获取。
需求获取是一种为软件系统-确定各类干系人的-需要和约束的-过程。
需求获取-不等同于-“收集需求”，也不是简单地将用户所说的全部记录下来。
获取是一个综合协作和分析性的过程，其活动包括收集、发现、提炼和定义需求。
获取的目的是为了发现业务需求、用户需求、功能需求和非功能需求，还有一些其他类型的信息。
需求获取可能是软件开发各个方面中最具有挑战性、最关键、最易出错和最需要密集沟通的阶段。

需求获取的一般过程

准备阶段
- 决定需求获取的范围和日程
- 准备资源
- 准备问题和Strawman模型
执行阶段
- 举行需求获取会议
跟进阶段
- 组织并分享笔记
- 记录未解决问题

需求获取的方法

访谈
工作坊
焦点小组
观察
问卷调查
系统接口分析
用户界面分析
文档分析

需求获取的注意事项

平衡干系人出席的人数
定义范围要适当
避免需求对抗设计
合理调查

假设需求与隐晦需求

假设需求：是人们期望但没有明确表述出来的需求，你的假设虽然很明显，但与开发人员做出的假设可能不一致。
隐晦需求：之所以需要，是由于存在另外的需求，但隐晦需求的表述不是很明确。开发人员无法实现自己都不知道的功能。
例如：

电话号码，邮箱的有效格式；
身份证号，银行卡号不重复的隐晦需求；
网站发布内容的显示与检索。

非功能需求--软件质量定义

==外部质量属性==
描述软件运行期间能够感受到的属性。
易用性、可安装性、完整性、互操作性、
性能、可靠性、健壮性、安全性、防护性
==内部质量属性==
在软件运行期间不会直接表现出来的属性。
有效性、可修改性、可移植性、
可重用性、可伸缩性、可验证性

2、需求分析

对客户提出的需求进行分类

操作流程解决思路数据需求约束
外部接口需求质量属性功能需求
业务规则用户需求业务需求无效需求

理解用户需求
- 用例
- 用户故事

一图胜千言
记录业务规则、照章办事
没有哪一个需求视图能够让我们全面理解需求
为了看清需求全貌，需要在不同的抽象层次综合描述

3、规范说明

需求开发的结果

就是各方干系人，对所要开发的产品，达成一个==协议文档==。

业务需求包含在愿景和范围文档之中；
用户需求以用例/用户故事的形式来捕捉；
产品的功能&非功能需求，通常都存储在一个软件需求规格说明书(SRS)中；
交付对象：包括客户、市场、销售、项目经理、设计人员、开发人员、分包商和验证解决方案人员。

优秀需求特点--需求陈述

在理想状况下每一个业务需求、用户需求、功能性需求和非功能性需求应该具备的特点。
①完整性 ②正确性 ③可行性 ④必要性
⑤优先级排序 ⑥无歧义 ⑦可验证性

优秀需求特点--需求集合

各个独立需求都有完美表述是不够的。
一些需求集合是为一个特定发布的基线或者迭代而产生。
①完整性 ②一致性 ③可修改性 ④可追溯性

需求编写注意事项

细化程度
- 需求规范应该细化到包含的信息==刚刚够用==的程度，让开发人员和测试人员正确实现。
- ① ==恰当细化==；
- ② ==一致的粒度==。
表达技巧
- 尽量使用最有效的表达方式。
- 除了自然语言表述外，还可以使用列表、表格、可视化分析模型、图表、数学公式、图片、音频和视频片段等补充信息手段。
避免歧义和不完整性
- 使用清晰明了，没有歧义词表达。留心同义词和近义词。
- 避免遗漏功能，可以把关注点放在获取用户任务上而不是~~系统功能~~上。
- 使用分析模型，有助于发现遗漏需求。

4、需求验证

需求确认与验证

1、需求评审
正式评审（同行评审）
非正式评审（同级桌审、轮查、走查）
2、需求原型
原型是能够-将需求变为现实-的确认工具。
3、需求测试
根据功能性需求/用户要求，进行测试，可以使项目人员-感知到预期的系统行为。（设计测试、功能测试）

通过原型来减少风险

软件原型是对提议新产品的部分、可能的或是初步的实现。
原型能够实现三个主要目的：
1、明确-完成-验证需求
作为一种需求工具，原型能够辅助我们取得共识、查找错误和遗漏以及评估需求的准确性和质量。
2、探究设计的选择方案
能够使项目干系人探究不同的用户交互技术、设想最终产品、优化系统的易用性以及评估潜在的技术方法。
3、创建一个可以演变为产品的部分系统
原型是对部分产品的功能实现，通过一系列小规模的开发周期，它演变为完整的产品。

需求开发之外

估算需求工作量
从需求到项目计划
从需求到设计和代码
从需求到成功交付

软件开发V字模型

需求获取、分析基本流程

软件需求管理

1、需求管理实践

需求管理包括项目过程中所有保持需求协议的完整性、准确性和流通性的活动。

版本控制
- 定义版本标识方案
- 跟踪单个需求的版本
- 跟踪需求集合的版本
变更控制
- 提议变更
- 分析影响
- 做出决定
- 更新单个需求
- 更新需求集合
- 更新计划
- 度量需求变动
需求状态跟踪
- 定义可能的需求状态
- 记录每个需求的状态
- 跟踪所有需求的状态分布
需求追踪
- 定义到其他需求的链接
- 定义到其他系统元素的链接

2、需求变更

变更控制策略
- 所有变更必须遵循流程；
- 对于未批准的变更，除了可行性探索外不进行设计和实现工作；
- 只是简单提交一个变更不会保证其一定会被实现；
- 变更数据库的内容必须对所有项目干系人可见；
- 每个变更必须进行影响分析；
- 每个变更必须可以追溯到一个通过批准的变更请求；
- 变更请求的批准或否决都需要记录其背后的理由。