构建之法阅读笔记04
第八章：需求分析
1、软件需求
1. 获取和引导需求；（软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。）
2.分析和定义需求；（对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化）
3.验证需求;(软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。)
4.在软件产品的生命周期中管理需求;
同时也可以在下面的这几个进行分析：
1. 对产品功能性的需求：要求产品必须实现某些功能。（例如我们小组设计的APP主要是设计给学生那些没有收入，每个月的花销量较小的，实现简单的功能，简洁的界面）
2. 对产品开发过程的需求（分析用户需要什么，想要什么，根据设计我们的APP，这样才能受到大众的喜爱）
3. 非功能性需求
4. 综合需求
2 软件产品的利益相关者
用户：直接使用软件系统的人（取决于软件的特点，一个软件也许有多种不同的用户。）
顾客：买这个软件或者根据合同或规定接收软件的人。这些人不一定是软件的直接用户，但是他们的利益和软件直接相关；
软件工程师：工程师也是软件需求阶段的一个重要角色；他们根据用户和顾客所提出的要求进行软件的修改，优化；
3、 获取用户需求——用户调查
用户需要什么是软件工程师需要设计的东西，不可能设计用户不喜欢的东西，没有任何的意义，也没有带来效益；
所有这就需要我们进行调查，成立调研小组：
焦点小组：找到一群目标用户的代表，加上项目的利益相关者来讨论用户想要什么，用户对软件的评价等等；
深入面谈：通过详细的面谈，广泛而深入地了解用户的背景、心理、需求等；
卡片分类：把各种需求做成便于规整的小卡片，然后进行讨论 → 明晰定义 → 归类 → 排序这一方法可以帮助我们更好地统一大家对软件需求的认识，可以刚好的帮助我们理解用户想需求；
用户调查问卷：这是经常背使用的一种调研方式；随机率更大，更能反映不同的人群的需求；
用户日志研究:要求用户记录自己日常工作或生活中与所用软件相关的行为，供软件团队分析。
人类学调查:可以解释为—和目标用户“同吃同住同劳动”。
4、竞争性需求分析的框架
同一类的软件有上很多很多种，我们需要分析出用户选择我们这款软件的有点，其他同类软件有什么缺点是我们需要避免的，有什么优点需要开发的时候借鉴；这样设计出来的APP才是用户真正需求的；
1. N（Need，需求）
2. A（Approach，做法）
3. B（Benefit，好处）
4. C（Competitors，竞争）
5. D（Delivery，推广）
同样在我们刚开始做APP的时候，老师让我们在讨论的时候写过NADBC，分析出我们的APP有什么亮点；
5、功能的定位和优先级
维持——以最低成本维持此功能。
抵消——快速地达到“足够好”、“和竞争对手差不多”。
优化——花大力气做到并保持行业最好。
差异化——产生同类产品比不了的功能或优势（我有人无的优势，或者一个数量级以上的优势）。
第九章
对于pm的介绍：
PM的M就Manager，但是P有这几种：Prod-uct Manager、Project Manager、ProgramMan-ager，在不同的行业和公司，他们的作用各不相同。
开发和测试搞不定的事情：
1. 和客户交谈，组织用户调查，发现用户需求
2. 了解和比较竞争对手的产品
3. 怎么让软件变得可用（Usable）、有用（Useful）
4. 怎么改进团队的流程
PM的出现让团队内部的互动出现了两个新特性：
1. 负责一个功能的开发/测试人员和相关的PM密切合作，再由PM代表这一小组去和别的小组或客户代表打交道，大大降低了交流的成本；
2. 有专人负责开发/测试之外的许多事务和项目进度的管理，让开发和测试人员专注于技术方面的工作。
PM做开发和测试之外的所有事情，带领团队达成最重要的目标，并保持团队的平衡
这种不用编程可以指挥程序员的pm需要下面的这几点：
1. 观察、理解和快速学习能力PM要能够在一个新的领域中很快上手。
2. 分析管理能力每天项目中发生的事情千头万绪，PM要能够分析出重点，找到优先级，做判断、做决定……
3.不需要特别高的专业能力，PM的专业就是理解和表达（pm主要是与甲方打交道，要理解跟表达能力好）
4. 自省的能力。
pm的任务主要有
1. 带领团队形成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计；
2. 管理软件的具体功能的生命周期（需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰）；
3. 创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导，而不是障碍；
4. 代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级；
5. 分析并带领其他成员对缺陷/变更需求形成一致意见，并确保实施；
6. 带领其他成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布令客户满意的软件；
7. 收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提振士气。
第10章
典型用户
受欢迎的典型用户——指那些按设计者的期望使用系统的用户；
不受欢迎的典型用户——指那些有不正当目的的用户，这些用户也许在别的系统中是受欢迎的。
用例
基本元素：
标题：描述这个用例要达到的目标
角色：和软件系统交互的角色
主要成功场景：一系列步骤描述角色是怎样和系统交互，从而达到目标的。
扩展场景：描述一些扩展的交互
对于功能说明书，我们要写的清晰全面让客户一目了然需要下面的几个步骤：
第一，定义好相关的概念。
第二，规范好一些假设
第三，避免一些误解，界定一些边界条件。
第四，描述主流的用户/软件交互步骤
第五，一些好的功能还会有副作用。
第六，服务质量的说明。
