【读书笔记】软件需求第3版

最新推荐文章于 2024-10-17 12:37:41 发布

塔纳阿玛

最新推荐文章于 2024-10-17 12:37:41 发布

阅读量1.5k

点赞数 1

分类专栏：软件工程

本文链接：https://blog.youkuaiyun.com/weijihai520/article/details/106767267

版权

软件工程专栏收录该内容

1 篇文章

订阅专栏

软件需求第3版

译序
- 试问需求从何而来？
第1章软件需求的本质
第2章从客户角度审视需求
第3章需求工程优秀实践
- 3.1 需求开发过程框架
- 3.2 开始新的实践
第4章业务分析师
第5章建立业务需求
第6章倾听用户的心声

译序

公司为何在某些客户那里声名狼藉，销售人员为何不能再次从他那里拿单，甚至连维护项目都不让你继续在做。因为第一个项目在客户那里就完全失败告终，无法得到客户的认可和信任。慢慢地，如果情况继续恶性发展，一家公司的命运也可想而知了。
一个软件项目的失败，不是因为软件做得不够酷炫，又或者没有应用最前沿的高大上技术而导致的，最根本的原因，就是你的软件产品在客户看来完全就是一堆臭狗屎，没有提供有价值的东西给客户，客户不能对其产生依赖，没有了你的产品，客户的业务和工作能正常开展，而且丝毫不受影响。又或者客户宁愿忍受没有软件带来的便捷和准确性，也不愿意使用你的产品。有些客户说“没有让我使用的欲望，设计太丑”，但我想，其中还是有一些软件没有和客户的业务产生高度吻合的原因，否则，客户不可能说用都不想用。以上种种，总结起来，就是软件工程初期的需求工作没有做扎实，没有牢牢抓住客户的核心需求导致的。
客户不满意产品，导致返工，返工导致成本增加，开发组织的高管失望，研发人员重复工作也是怨声载道，最终出现了上面说到的情况，一家公司也就慢慢走向下坡路了。
原来的“需求分析”的观念代表整个软件需求工作，现在看来是片面的。需求工作包括了需求获取，需求说明，需求分析，需求验证和需求管理等。问题出现的根源就在于需求获取和需求验证方面存在缺陷。

试问需求从何而来？

老板的想法，开发人员的自得其乐，从狭窄的工作和生活经验得到的需求，大部分情况都是闭门造车，到了市场上，往往啪啪打脸。
闭门造出来的需求共性

希望在上线的一刹那一举形成可行的商业模式
孰不知，一个商业模式的成功，不知道埋葬了多少初创公司的汗水和财富，才在社会大众或客户前获得认可。
假设最初的想法是正确的
快速的试错，马上承认错误，改变方向，才是明智之举。
认为专家就在办公室里
创新不能依靠经验或权威。
上线之前，知道这个想法的客户数量为0
想一举成名往往带来的是壮士一去兮不复返。

人们渐渐意识到，正确的需求是软件工程的基石，正确的需求，意味着客户愿意买单，即利润。正确的需求能避免软件中后期的返工，bug等问题，缩减了成本。一举两得，何乐而不为？
软件工程的四大理念

成功的商业模式需要依靠对正确需求的持续积累
要获得正确的需求，需要专家不断否定你的猜想
拥抱失败，反馈机制了解一下。不管是人体的体液平衡，还是大型的系统运转，都是一个反馈机制在其中，这就是系统控制理论的核心。让专家不断的反馈他们的意见，帮你证伪，使需求处于临界的恰到好处。
真正的专家是会购买你的产品或服务的客户
为什么你的产品无法吸引他们的注意力，为什么他们不会为你所假设的需求买单？客户说你不专业，说你做的不够好，解决这两个问题，答案就在其中。
走出办公室
正确的需求高于正确地需求。

第1章软件需求的本质

1.1 软件需求的定义

需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。

1.2 需求的层次和种类

业务需求：开发产品的组织或者获取产品的客户所需的高层次业务目标
业务规则：政策法规，行业标准，计算算法等。
约束：对开发人员在产品设计和构建上的限制条件。比如银行卡必须支持芯片或者磁条读取用户信息。
外部界面需求：
特性：一组功能性需求来共同描述。
功能需求：描述系统在特定条件下展现的行为，-行为
非功能需求：-属性或特性，或约束。强调的不是系统要做什么，而是系统做得有多棒。不能狭隘地等同于质量属性，设计和实现约束也是非功能需求，外部接口需求也是。平台、可移植性、兼容性和约束等系统运行环境也是。
质量属性：
系统需求：包含多个子系统的产品的顶层需求，子系统可以是软件，也可以是软硬件。这是个有机的整体，如同地球就是一个超级生命体的大细胞！要整体理解，甚至人也是系统的组成部分。
用户需求：特定用户群必须能够用系统所完成的目标或任务，或者是用户期望有的产品属性。

这里的业务需求，实际上指的是客户的业务目标或者远景，是可以进行度量的。寻找组织的老大是关键。而业务用例变成了这里的用户需求，但是没有软件系统，也必须要做的业务工作，在哪里描述呢？？？所以有了改进前和改进后两个业务序列图。。系统用例描述的是这里的功能需求了。
1、处理三种层次的需求
三种主要的需求交付物：愿景和范围文档、用户需求文档和软件需求规范说明。三者可以融合在一起，但不是一次性给某一类人员看的，三种交付物包含着不同的信息，要在项目的不同点进行开发。开发人员也可能不同，目的和目标受众也不相同。
2、产品需求和项目需求
项目包含的其他的诉求和产出，不在团队执行的软件范围之内，但对项目的整体成败尤为关键。这些都是项目需求而非产品需求。

1.3 需求开发和管理

在这里插入图片描述

需求开发

     分为获取、分析、规范说明和验证。

获取需求，包括识别产品的预期客户群和其他干系人；理解客户任务、目标以及这些任务相关的业务目标；了解新产品的应用环境；与每一类客户群的代表一起工作，理解他们的需要和预期。
分析需求，深入并准确理解每个需求，然后将各个需求以不同的方式表达出来。
规范说明，以一种连贯并结构清晰的方式来表达和存储收集到的需求知识。
验证，需求验证是指确认需求信息是正确的，能使开发人员制定出能满足业务目标的解决方案。检查记录的需求，开发验收测试和标准。

需求管理

确定需求基线
评估需求变更
项目各阶段和需求演化协同
预估的需求变更带来的影响并商定新的承诺
定义各个需求之间存在的关系和依赖
跟踪每个需求到他们各自对应的设计、源代码和测试。
在整个项目过程中跟踪需求状态和变更活动。

1.4 每个项目都有需求

1.5 人对了，得出的需求却很糟糕

确定更精准的需求是一种投资，并不只是成本。
需求实践的不足会对项目的成功造成很多风险，这里的成功指的是在规定的成本和时间内交付预期功能和质量的产品。
下面介绍一些最常见的需求风险：

1、用户参与度不够
2、规划不当
3、用户需求蔓延
为了管理需求蔓延，必须一开始就对项目的业务目标、战略愿景、范围、边界和成功标准给予明确说明。
4、需求模棱两可
模棱两可的需求会使不同干系人产生不同的期望。
非正式的同行检查只是从自己的角度来阅读，一般看不出模棱两可的需求。如果不同的检查者只按照自己的理解从不同角度理解需求，也看不出歧义性需求。因此，干系人应作为小组以工作坊的形式来讨论和解读需求，共同获取和验证需求。
5、镀金
不要未经干系人同意就擅自主张增加新的特性，先向干系人展示创意。
开发人员不要增加自己觉得有趣或者自认为用户会喜欢的功能。
6、忽视干系人
确定所有的用户分类之后，还要保证倾听用户的声音。除了显而易见的用户，还要考虑维护人员和现场支持人员，他们也有自身的需求，包括功能需求和非功能需求。

1.6 高质量需求过程带来的好处

在优秀的需求上投资，会事半功倍。潜在的收益如下：

需求中的缺陷和交付产品中的缺陷更少。
开发的返工减少了。
开发和交付更快。
不必要和无用的特性更少。
减少成本追加。
信息错误传达的现象减少了。
范围蔓延减少了。
项目的混乱现象减少了。
客户和团队成员的满意度更高了。
产品按照人们当初的设想顺利进行。

第2章从客户角度审视需求

项目的成功离不开客户和开发人员的紧密合作
本章所阐述的客户-开发人员关系是软件项目成功的关键要素。软件客户拥有的权利清单和对应的义务清单
三输的局面：开发、客户和高管

2.1 期望落差

缩小其网络差的最好方法是与合适的客户代表频繁沟通。
形式可以是正式访谈，对话，需求评审，用户界面设计走查，原型评估以及敏捷开发中在可执行软件每个小的增量功能上收集的用户反馈。

2.2 谁是客户

干系人是指积极参与项目的某个人、群体或组织，他们可能会受项目过程和结果的影响或影响项目的过程和结果。
客户是干系人的一个子集。
用户需求应该来自于直接或者间接使用产品的人，这些用户（通常称为“终端用户”）是客户的子集。
用户通常能够描述他们需要用产品执行的具体任务、他们需要的输出以及他们希望产品达到的质量标准。
业务需求应该来自于最终的产品业务价值负责人。用户需求则应该来自于按下按键、点击屏幕或者接收输出的人。
项目干系人之间可能会出现矛盾。业务需求有时会反映用户不可见的组织战略或预算约束。

2.3 客户-开发的合作关系

卓越的软件产品来自基于卓越需求的卓越设计。卓越的需求则根植于开发人员与客户（特别是终端用户）高效协作的土壤中。

软件客户的需求权利法案

期望业务分析师使用自己的语言
期望业务分析师了解自己的业务和目标
期望业务分析师用适合的形式记录需求
收到需求实践和交付物的相关解释
变更需求
期望有一个彼此尊重的环境
聆听关于需求以及解决方案的建议和替代方案
描述能提高产品易用性的特性
了解调整哪些需求可以实现复用，加速产品开发
收到满足自己功能需求和质量期望的系统

软件客户的需求责任法案

向业务分析师和开发人员传授自己的业务知识
准备足够的时间用来澄清需求
提供具体而准确的需求描述
被问到有关需求的问题时及时做出决策
尊重开发人员对需求可行性和成本的估算
和开发人员协作设置符合实际的需求优先级
评审需求和评估原型
设定验收条件
及时沟通需求变更
尊重需求开发流程

作为项目计划的一部分。关键用户和开发干系人应该讨论这两个列表并且达成一致意见。

2.4 建立尊重需求的企业文化

糟糕的需求如何减慢设计并在修正产品方向时花费巨大的成本。
开发人员
质量保障人员和测试人员是优秀需求的贡献者，眼尖！
对流程或文化改变的抵触大多来自于恐惧、不确定性或知识的缺乏。
领导必须理解这一点：组织需要把高效业务分析和需求工程能力作为自己的战略性核心竞争力

2.5 识别决策者

变更控制委员会：代表各个关键领域（比如管理、客户、商业分析、开发和市场部门）的小组

2.6 对需求达成一致

对在建产品的需求达成一致或是在某部分达成一致是客户-开发人员关系的核心。涉及的多个角色应形成如下共识：

客户承认需求描述了他们的需要
开发人员承认理解需求并且认为他们是可实现的
测试人员承认需求是可验证的
管理层承认需求可以达成他们的业务目标

用签字的方式来代表干系人认可需求。

在需求上签字是毫无意义的例行公事？让其不能成为未达成目标或者需求变更时的依据？
开发经理把签字视作需求冻结的一种手段
上述两者均忽略了一个事实，即我们不能在项目早期就知道所有的需求，而且毫无疑问，需求会随着时间的变化而变化。
不要把签字作为武器，把它当做一个里程碑，表示大家对签字活动的意义有清晰的共识，也包括理解未来可能有变更。

需求基线

比签字仪式更重要的是确立一条需求基线，一个特定时间点的需求快照。需求基线是一组需求，在评审和确认后作为后续开发的基础。不论团队使用正式的签字流程或其他方式对需求达成一致，潜在的含义都应该如下所述：
“我同意当前这组需求代表我们对项目下一阶段需求最深入的理解，并且基于目前我们对问题的理解，这个解决方案能够满足我们的需求，我同意再未来使用项目定义好的变更流程基于这个基线对需求进行修改。我清楚变更可能导致我们重新讨论项目的成本、涉及的资源以及对时间表的承诺。”
一个有意义的基线确定流程可以在以下几个方面为主要干系人带来信心。

客户管理层或者市场营销人员相信项目不会超出可控范围，因为客户会为范围变化的决定负责。
用户代表相信开发团队会和他们一起工作，交付正确的解决方案，即使他们在开发开始之前没有考虑清楚所有的需求。
开发部门的信心建立在开发团队有业务伙伴保证项目始终聚焦于其目标上，同时业务伙伴也和开发团队一起平衡项目计划、成本、功能和质量。
业务分析师和项目经理有信心有效控制项目变更带来的风险，并使风险最小化。
质量保证和测试团队有信心开发测试脚本并且为自己在项目中的各种活动做好准备。

达不成共识怎么办

分析干系人不愿意确认的原因，先小心地推进项目，在风险列表中做记录（把它和遗漏或错误的需求可能带来的影响同等对待）。

对敏捷项目的需求达成共识

在敏捷项目中，产品负责人对迭代选择或拒绝需求，需求包括一系列用户故事以及相应的验收条件和验收测试。最终的签字就是接收迭代所产出的经过测试的可工作的软件。
签字代表我们找到了一个参照点，一个可以进行需求变更的基线。即使是变更，也要指出变更哪里，而基线的需求内容就是依据。

第3章需求工程优秀实践

最佳实践方法是丰富的工具箱，运用不同技术来应对不同的挑战。
需求工程优秀实践

1、获取
- 定义愿景和范围
- 识别用户群
- 选择产品代言人
- 组织焦点小组
- 识别用户需求
- 识别系统事件和响应
- 需求获取访谈
- 举行引导式需求获取讨论会
- 观察用户如何完成工作
- 分发调查问卷
- 分析文档
- 检查问题报告
- 重用已有的需求
2、分析
- 应用环境建模
- 创建原型
- 分析可实现性
- 排列需求优先级
- 创建数据字典
- 需求建模
- 分析接口
- 将需求分配到子系统
3、规范说明
- 采用需求文档模板
- 识别需求源头
- 为每个需求分配唯一标识
- 记录业务规则
- 描述非功能性需求
4、验证
- 评审需求
- 测试需求
- 定义验收条件
- 模拟需求
5、需求管理
- 建立变更控制流程
- 分析变更影响
- 建立基线，管理需求版本
- 维护变更历史
- 跟踪需求状态
- 跟踪需求问题
- 维护需求可跟踪矩阵
- 使用需求管理工具
6、知识
- 培训业务分析师
- 向干系人讲解需求内容
- 向开发人员讲应用领域知识
- 定义一个需求工程流程
- 建立一个词汇表
7、项目管理
- 选择合适的生命周期模型
- 规划需求方案
- 估算需求工作量
- 基于需求做计划
- 发现需求决策者
- 重新协商承诺
- 管理需求风险
- 跟踪记录需求工作量
- 回顾学到的经验
3.1 需求开发过程框架

需求工程的获取、分析、规范说明和验证等实践，不是一次性线性顺序完成的，而是相互交织、渐进的和迭代式的。“逐步完善细节”
**优秀实践：**包含但不限于以下内容：

需求获取活动
需求分析
需求规范说明
需求验证
需求管理
知识
项目管理

3.2 开始新的实践

不要试图在新项目中一个不落地使用所有这些技巧。
需求工程的优秀实践，根据价值高低、难度高低进行了分类。

第4章业务分析师

4.1 业务分析师的角色

在这里插入图片描述
分析师是一种项目角色，而不一定是个头衔。业务分析师还有一些别名，例如需求分析师、系统分析师、需求工程师、需求经理、应用分析师、业务系统分析师、IT业务分析师或者简单称为分析师。
特定项目中，此角色可能有一个或多个全职专家来扮演，或者也可能被分配给团队成员，包括项目经理、产品经理、产品负责人、主题专家（Subject master expert，SME）和开发人员，有时甚至是用户。
警示： 不要妄想谁不经过培训和辅导就能自动成为高效的业务分析师，即使他是有天赋的开发人员或知识渊博的用户。
才华横溢的业务分析师可以使项目起死回生。减少错误，提高效率，减少工作量，降低成本。