软件工程学习笔记（三）

最新推荐文章于 2024-09-29 16:42:21 发布

JncmdWZJ

最新推荐文章于 2024-09-29 16:42:21 发布

阅读量901

点赞数 16

文章标签：软件工程学习笔记

本文链接：https://blog.csdn.net/m0_74750126/article/details/142459581

版权

前言

这一讲将进行软件需求有关的学习。需求分析是软件工程中的重要步骤，是决定软件项目成败的关键影响因素之一，需求阶段的错误在后期的纠错成本将远远高于软件设计和实现阶段的错误的纠错成本，因此需求工程成为软件工程和系统工程重要的分支领域之一。
在需求工程中，我们主要关注的是软件和系统需求的获取、建模、分析、验证和管理。接下来的学习，主要是围绕软件需求的获取技术、建模方法和分析方法进行的。即将学到的是：

如何产生软件产品的新的创意
如何和干系人进行有效地沟通
如何基于目标、场景和主题来建模软件系统的需求
如何用图形化的方法对软件系统的行为和结构进行分析。

在这部分的学习中要注意两点：

首先要注意将问题的分析和解决方案的生成区别开来
其次要根据软件项目本身的规模、人员的技能、客观的条件、项目的成本来选择合适的需求获取技术和建模方法，选择最合理的软件系统设计方案

一、需求工程师是什么？

需求工程师是软件工程师的一个分支。软件工程师的思维方式是做出尽可能简化问题复杂度的假设。
作为一位当代的需求工程师应该具有以下技能：

分析问题和解决问题的能力
人际沟通及交流能力
软件工程知识技能
应用领域有关知识
书面语言组织和表达能力

一名优秀的需求工程师的目标有：

识别错误假设
确保一致性
提升依从性
减少彼此误解
提高支持速度和效率
提升客户满意度
撰写优质需求文档

需求分析师的七宗罪有：

干扰
沉默
过度规约
矛盾
含糊
向前引用
不切实际与一厢情愿

二、需求定义

来自美国科罗拉多州立大学科全分校的Alan M.Davis教授给需求的定义是这样的

“需求”是对外可见的系统特征

“需求管理”有三项任务：

学习——需求获取
剪枝——需求优选
文档化——撰写需求规格说明书

它强调的是需求的对外可见性以及需求关注的是系统的特征描述。

IEEE对需求的定义是

需求，是人们要解决的某个问题或达到某种目的的需要。是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所要具备的能力。需求将作为系统开发，测试，验收，提交的正式文档依据。
——IEEE 610.12，1990

诺贝尔经济学奖以及图灵奖的获得者Herbert Simen教授对需求的定义是

每一个“人造物”都是一个内部环境与外部环境的“接口”。这里内部环境指人造物本身的设计组成。外部环境指人造物的周遭及其作用环境。对这个接口的描述即是需求。

需求描述的难点和挑战在于，它是连接应用领域现象与机器领域现象的桥梁。我们要从应用领域的固有性质和用户待解决的需求描述转化为可以用计算机软件实现的系统行为的描述。

需求是系统为满足客户期望的目标而完成的行为
需求要体现出对问题领域的清晰理解
给出系统的使用场景和上下文

需求定义涵盖如下内容

为什么要设计该系统
系统由谁使用
系统要做什么
系统涉及哪些信息
对解决方案有何额外限制
如何使用该系统
质量需要达到何种程度

在定义需求的过程中，我们要注意将问题与解决方案分开，建立单独的问题描述文档：

表面上的问题vs.真正要解决的问题
将问题描述提交给干系人进行讨论
按问题描述选择候选设计方案
问题描述作为测试用例的来源

在这里插入图片描述
从上图我们可以看出，问题陈述和实现陈述之间要进行模型正确性的证明。

在这里插入图片描述

在对需求进行描述时应该避免以下情况：
在这里插入图片描述

好的需求是可以度量的，能给出项目成功的必要条件

在这里插入图片描述
这些需求的质量检测标准为我们评估自己的需求文档的质量给出了客观的参照依据。

三、需求获取技术

需求获取过程中，最困难的不是记录用户需求，而是与用户探讨磋商，发现真正要解决的问题，确定适用的方案。
——Steve McConnell

以下是一些最常用的需求获取技术：

面谈
- 一样的地点，一样的时间
- 少量人参与，分析师驱动
问卷调查
- 不同的时间，不同的地点
- 很多人参与，分析师观察
群体诱导技术
- 相同或不同的地点，同样的时间
- 20人左右，分析师参与
参与调查法
- 同样的时间，同样的地点
- 分析师参与
文档分析
头脑风暴
情景分析
原型化方法
建模方法
需求讨论会

1.面谈

即问问题，听答案
什么时候面谈？

可以见到干系人
很少的人了解很多内容的时候
真正的专家存在的时候
干系人不能被聚到一起的时候
问题不依赖交互来得到最后解答时

类型	有组织的面谈通常事先制定议程，问题可以是开放的
类型	自由面谈则无既定议程
面谈的优点	可以获得大量丰富的数据
	有助于发现观点、感受、目标及事实
	可以进行深入探讨，根据面谈前一阶段获知的内容调整后续的问题
面谈的缺点	大量的数据是定性的，难以分析
	难于对问题的回答者进行比较
	面谈技巧难于掌握

面谈技巧
在这里插入图片描述
基于访谈的用户需求获取过程

2.问卷调查

预先定义的问题
面对广泛涉众的时候使用
统计分析的结果看起来更科学
什么时候使用问卷调查？
- 大基数的被访问者
- 需要关于良好定义的特定问题的答案
- 验证有限次面谈得出的结论
- 当你需要一个特定的结果的时候

优点	可快速获得大量反馈
	可以远程执行
	可搜集关于态度、信念及特性的信息
缺点	简单的分类导致对上下文的考虑较少
缺点	留给用户自由表达其需要的空间较小

问卷调查注意事项

选择样本时可能存在偏见
自愿的问卷回答者可能存在偏见
样本规模太小
自由发挥问题难于分析
对答案有诱导性的提问
问题的妥当性
含糊的问题

3.群体诱导技术

在同一个房间中聚集3-20个干系人
每个人都将自己的观点大声说出来
群体的答案往往比个体好
什么时候采用群体诱导技术？
- 当很多人各自知道关于整体的一小部分时
- 当人们需要彼此交互来得到一个最优的答案时
- 当你能把人们聚在一起时
- 需要匿名？采用一些工具
- 在不同地方？采用一些工具

类型	专题小组会议
类型	头脑风暴
优点	人们的交互比正式的面谈来的自然
优点	可以抛砖引玉（运用实体模型、情节串联板）
缺点	分组不一定自然（可能会令某些参与者不适应）
	少数服从多数所带来的危险
	可能对技术问题仅给出表面化的回答
	需要训练有素的协调人
注意事项	样本偏见
注意事项	统治与屈从
由几个人控制时	引导者角色
由几个人控制时	5分钟规定时段陈述
一些人缺少参与	引导者角色
一些人缺少参与	“好主意”券
无理的参与者	“恶意中伤” 券

4.需求研讨会

目标
- 介绍项目成员和干系人
- 收集需求列表
- 在会议过程中，运用头脑风暴、故事板、角色扮演、现有系统评估等方法获取需求
指导原则
- 主持人组织研讨会：
  - 给每个人发言的机会
  - 保持研讨话题的相关性
  - 定义需求属性
  - 记录需求发现
  - 总结并作出结论
用于总结成果或取得反馈
- 在每个阶段结束时与干系人安排会议
  - 讨论信息搜索阶段的结果
  - 对需求做出结论
  - 对某项设计取得一致意见
- 通过会议来确定所获得的信息，讨论新的发现
会议是重要的管理手段
- 用于推进系统开发项目的进展
- 需首先确定会议的目标
  - 例如：陈述介绍、解决问题、协调矛盾、项目进展分析、搜集和汇总数据、培训、计划
- 需对会议进行仔细筹划
  - 日程及设施安排
  - 确定日程并提前通知
  - 根据会议目的决定会议形式
  - 会议期间控制进度和程序进展
  - 对会议进行书面总结，并分发给与会者
  - 正式的陈述报告，项目预演及头脑风暴应遵循一定的规则

5.头脑风暴

目标
- 通过群组效应，激发对新产品和系统的新想法
- 在需求不完全明确的情况下比较有用
指导方针
- 采用有组织的研讨会形式
- 百花齐放，不评价、不争论、不批评
- 不受现实可行性限制
- 新观点多多益善
- 抛砖引玉
- 互相启发

6.参与观察法

分析师观察干系人进行日常工作
分析师越被动越好
观察影响观察到结果
观察参与者时，进行“动作研究”
什么时候观察？
- 当有人或事需要观察的时候
- 当知识无以言表的时候
方法
- 纵深调查：观察者参与被观察对象日常活动，成为组织中的一员
优点
- 总是上下文相关的
- 能够发现其他方法无法发现的细节
缺点
- 时间成本和开销很大
- 获取过于丰富的细节，难于分析
- 无法就改进建议所带来的结果给出更多评论
注意事项
- 有被同化的风险

7.亲身实践

目标
- 通过观察和提问了解工作内容
- 实时实地开展工作
- 立即反馈
指导原则
- 用户太忙无法安排专门时间来参加面谈
- 人们并没有意识到在做什么
- 反复观看一个任务的执行过程
- 学习任务技能并作给用户看
- 与用户或顾客建立密切联系

8.文档分析

目标
- 理解待解决的问题
- 作为下一步业务流程建模和访谈的基础
指导方针
- 确定当前业务流程或产品的优缺点
- 找出产品或信息中可充用的部分
- 从多个来源获取用户需求

9.原型、仿真

目标
- 明确含糊、不确定的需求
- 简化需求文档，确认需求
- 尽早获得最终用户和客户的反馈
指导方针
- 用于确认需求
- 用于提供需求评估的数据基础
- 用于评估不同的用户界面方案
- 帮助用户可视化关键的功能
- 直观、有效的沟通工具

10.情景分析

目标
- 清楚定义有用户参与完成的业务事件的步骤
- 获取用户可见的动作
指导原则
- 确定与用户间可能的交互：业务事件、感兴趣的领域性质
- 将业务事件细化为具体业务活动和业务过程

11.概念建模

目标
- 用图形描述现实
- 建立未来系统模型，即未来系统的抽象表示
- 在建模过程中对原始需求进行评估、扩展
- 清楚、完整、正确、一致的描述
指导原则
- 模型类型
  - 分解
  - 数据
  - 面向对象
  - 用例
  - 过程
  - 活动

12.竞争性需求分析

在这里插入图片描述

13.A/B测试

在这里插入图片描述

14.用户行为数据在线采集

在这里插入图片描述

15.获取技术的选择

在这里插入图片描述
用户需求获取是一门倾听的艺术

在这里插入图片描述

四、撰写需求文档

1.软件需求规格说明

在这里插入图片描述

2.需求文档的组织形式

在这里插入图片描述

3.软件需求规格说明SRS风格

在这里插入图片描述

4.选择合适的需求规格说明方式

在这里插入图片描述

5.生成不同风格SRS的方法总览

方法	使用时机	适合	效果	需要的资源
描述性文本	小项目	小产品的非正式说明	中	有良好写作能力的分析师
从用例模型生成	大中型项目	产品线的正式规格描述	中	有建模能力，好的过程标准，建模工具的分析师
从需求数据库生成	大中型项目	产品线的正式规格描述	小	需求数据库，有数据库管理能力的分析师
从混合模型生成	中小型项目	单个产品的定义	中小	有良好协作技巧，需求工程，数据库管理，建模能力的分析师

6.用户手册大纲

介绍
- 产品总览及基本原理
- 术语和基本特征
- 展示格式与报表格式的总结
- 手册的大纲
开始
- 开始指令
- 帮助模式
- 样例运行
操作模式
- 命令行/对话框/报告
高级特征
命令语法和系统选项

7.需求规格说明的用户

在这里插入图片描述

一个高质量的需求规格说明：

是所有需求的集合
描述产品要提供的所有功能
是软件系统解决方案的商业合同的基础
是测试计划的基础
定义产品需求的度量标准
是产品需求跟踪的先决条件
影响开发产品的项目计划

高质量的需求规格说明的评价标准

正确性 = 经过验证的
无歧义
完整的
可测试 = 可以证明的
可修改的
可跟踪的
易理解
一致的
有序的
项目或产品特定的其他特征

除了前面提到的几个规约的评价指标以外，还应保证需求的规约是简洁的：

定义：需求描述尽可能简洁
- 描述了系统的一个独立特征
- 除了必需的信息外没有包含其他信息
- 用清晰、简单、可理解的词表述
- 避免“应该”、“可以”、“可能”之类的用词

8.需求规格说明生成过程

在这里插入图片描述

9.需求规格说明的结构

在这里插入图片描述

10.需求规格说明SRS模板

在这里插入图片描述

11.IEEE-830 SRS模板大纲

在这里插入图片描述
其中最重要的是第三部分：

SRS模板的优缺点

优点	模板提高效率
优点	在有模板的情况下，面对一个完整的大纲，不容易遗漏重要的信息
缺点	并非对于所有的系统，模板的章节设计都是类似的
	如果仅仅为了满足标准，而填写模板的所有章节，在不相关的章节，会加入一些没有意义的内容
	读者很难将这些无意义的文字和真正的需求分开