软件需求第3版

• 译序
• • 试问需求从何而来/li>
• 第1章 软件需求的本质
• • 1.1 软件需求的定义
  • 1.2 需求的层次和种类
  • 1.3 需求开发和管理
  • • 需求开发
    • 需求管理
  • 1.4 每个项目都有需求
  • 1.5 人对了，得出的需求却很糟糕
  • 1.6 高质量需求过程带来的好处
• 第2章 从客户角度审视需求
• • 2.1 期望落差
  • 2.2 谁是客户
  • 2.3 客户-开发的合作关系
  • • 软件客户的需求权利法案
    • 软件客户的需求责任法案
  • 2.4 建立尊重需求的企业文化
  • 2.5 识别决策者
  • 2.6 对需求达成一致
  • • 需求基线
    • 达不成共识怎么办
    • 对敏捷项目的需求达成共识
• 第3章 需求工程优秀实践
• • 3.1 需求开发过程框架
  • 3.2 开始新的实践
• 第4章 业务分析师
• • 4.1 业务分析师的角色
  • 4.2 业务分析师的职责
  • 4.3 基本的分析技巧
  • 4.4 基本的分析知识
  • 4.5 业务分析师的培养
  • 4.6 敏捷项目中分析师的角色
  • 4.7 打造一个协作型的团队
• 第5章 建立业务需求
• • 5.1 定义业务需求
  • • 确定预期业务收益
    • 产品愿景和项目范围
    • 业务需求冲突
  • 5.2愿景和范围文档
  • 5.3 范围表示技巧
  • • 关联图
    • 生态系统图
    • 特性树
    • 时间列表
  • 5.4 聚焦于范围
  • • 使用业务目标来做范围决策
    • 评估范围变更的影响
  • 5.5 敏捷项目的愿景与范围
  • 5.6 使用业务目标来确定完成
• 第6章 倾听用户的心声
• • 6.1 用户类别
  • 6.2 用户画像
  • 6.3 与用户代表取得联系
  • 6.4 产品代言人
  • 6.5 敏捷项目的用户表达方式
  • 6.6 处理需求冲突

译序

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

试问需求从何而来/h2>

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

1. 希望在上线的一刹那一举形成可行的商业模式
   孰不知，一个商业模式的成功，不知道埋葬了多少初创公司的汗水和财富，才在 会大众或客户前获得认可。

2. 假设最初的想法是正确的
   快速的试错，马上承认错误，改变方向，才是明智之举。

3. 认为专家就在办公室里
   创新不能依靠经验或权威。

4. 上线之前，知道这个想法的客户数量为0
   想一举成名往往带来的是壮士一去兮不复返。

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

1. 成功的商业模式需要依靠对正确需求的持续积累

2. 要获得正确的需求，需要专家不断否定你的猜想
   拥抱失败，反馈机制了解一下。不管是人体的体液平衡，还是大型的系统运转，都是一个反馈机制在其中，这就是系统控制理论的核心。让专家不断的反馈他们的意见，帮你证伪，使需求处于临界的恰到好处。

3. 真正的专家是会购买你的产品或服务的客户
   为什么你的产品无法吸引他们的注意力，为什么他们不会为你所假设的需求买单户说你不专业，说你做的不够好，解决这两个问题，答案就在其中。

4. 走出办公室
   正确的需求高于正确地需求。

第1章 软件需求的本质

1.1 软件需求的定义

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

1.2 需求的层次和种类

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

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

1.3 需求开发和管理

4.2 业务分析师的职责

• 1、定义业务需求
• 2、规划需求方法
• 3、确定项目干系人和用户类别
  选出合适的代表，争取他们参与，确定责任，达成共识。
• 4、获取需求
  熟练使用各类信息收集技巧，帮助用户阐明自己需要哪些系统功能，满足其业务目标。
• 5、分析需求
• 6、记录需求
• 7、沟通需求
  沟通不是将需求记录在纸上然后将其束之高阁。
• 8、主导需求验证
  保证基于需求的解决方案能满足干系人的需求。分析师是进行需求检查的核心人物，还要检查需求引发的设计和测试，确保人们对需求的解读是正确的。
• 9、帮助推动需求优先级排序
  业务分析师作为中间人，让干系人和开发人员进行合作和协商，保证他们做出的需求优先级决策是合理的。
• 10、管理需求
  建立需求基线后，把重点转向跟踪这些需求的状态，验证产品是否满足需求，并对需求基线的变更进行管理。

4.3 基本的分析技巧

倾听技巧
访谈和提问技巧
才思敏捷
分析技巧
系统思考的技巧
学习技巧
引导技巧
领导力技巧
观察技巧
沟通技巧
组织技巧
建模技巧
人际技巧
创造性

4.4 基本的分析知识

4.5 业务分析师的培养

前用户

前开发人员或测试人员

前（或兼职）项目经理

主题专家

菜鸟

4.6 敏捷项目中分析师的角色

4.7 打造一个协作型的团队

分析师引领所有项目参与者达成需求方面的共识，从而在以下几个方面实现双赢。

• 客户对产品感到满意
• 开发组织对业务成果感到满意
• 所有团队成员对自己在这项富有挑战但又回 丰厚的项目中的优秀表现而自豪

第5章 建立业务需求

业务需求代表的是需求链的顶部。它们定义解决方案的愿景和实现该方案的项目范围。
任何无助于项目达成业务目标的需求都不宜实现。

5.1 定义业务需求

“业务需求”指的是一组信息，描述的是需要，在此需要的指导下，一个或多个项目交付一个解决方案和符合预期的最终业务成果。
业务机会、业务目标、成功标准和一个愿景声明共同构成了业务需求。

确定预期业务收益

业务收益必须体现对项目发起人和产品客户的真正价值。他们关心的是如何增加收入和降低成本。

产品愿景和项目范围

业务需求的两个核心元素是愿景和范围。

业务需求冲突

5.2愿景和范围文档

愿景和范围文档将业务需求集合合为一个独立的交付物，为后续的开发工作奠定基础。

• 1、业务需求

• 2、范围和限制

• 3、业务背景

5.3 范围表示技巧

关联图

生态系统图

特性树

时间列表

5.4 聚焦于范围

使用业务目标来做范围决策

评估范围变更的影响

5.5 敏捷项目的愿景与范围

5.6 使用业务目标来确定完成

第6章 倾听用户的心声

软件的需求，甚至软件开发的成功取决于开发人员能否听到用户的声音。为了听到用户的心声，可以采取以下三个步骤。

• 识别产品的不同用户类别
• 挑选用户和干系人小组代表，并与他们一起工作
• 对谁是项目需求的决策者达成共识

6.1 用户类别

• 用户分类
• 识别用户类别

6.2 用户画像

6.3 与用户代表取得联系

6.4 产品代言人

• 外部产品代言人
• 产品代言人的期望
• 多个产品代言人
• 推广产品代言人理念
• 产品代言人要避免的陷阱

6.5 敏捷项目的用户表达方式

项目团队成员与合适的客户之前

6.6 处理需求冲突

未完待续。。。