成为工程师，而不是码农（需求分析）

成为工程师，而不是码农（一）

一个成功的软件开发步骤

针对框架、类库、组件等非业务系统的开发，其中一个比较大的难点就是，需求一般都比较抽象、模糊，需要你自己去挖掘，做合理取舍、权衡、假设，把抽象的问题具象化，最终产生清晰的、可落地的需求定义。需求定义是否清晰、合理，直接影响了后续的设计、编码实现是否顺畅。所以，作为程序员，你一定不要只关心设计与实现，前期的需求分析同等重要。需求分析的过程实际上是一个不断迭代优化的过程。我们不要试图一下就能给出一个完美的解决方案，而是先给出一个粗糙的、基础的方案，有一个迭代的基础，然后再慢慢优化，这样一个思考过程能让我们摆脱无从下手的窘境。

1、需求分析

分成需求收集、需求分类、需求挖掘、需求分级四个阶段。
需求分析准备工作
人员分析：干系人的背景，职务，对业务的熟悉程度，对系统的熟悉程度
项目分析：项目目标、招投标文件分析、项目类型、项目大小、项目边界、项目组织架构（人员）

需求收集

需求调研收集工具和技术：访谈、观察体验、头脑风暴、会议/研讨会、问卷、标杆对照、单据分析、报表分析、焦点小组、名义小组、群体创新技术，群体决策技术、产品试用、需求探针、售后反馈，专家研讨、行业推广会等

1. 焦点小组技术 VS 名义小组术技术

1)定义区别：

焦点小组：要有一个有经验的主持人明确把握会议讨论的方向，防止跑题，因为参加会议的都是专家，所以讨论内容要围绕希望的“焦点问题”展开。着重于互动讨论。

名义小组：这是群体创新技术中的一种方法，是用来筛选头脑风暴会议结果的。通过对头脑风暴结果的投票（或权威决策）进行取舍，然后开展下一轮头脑风暴或开展其他活动。着重于结果的筛选。

2)组成人员不同。焦点小组的组成人员主要是专家，名义小组没有这方面的要求。

3)着重点不同。焦点小组着重于浮动讨论，名义小组着重于对结果的筛选。

4)对象不同。焦点小组的对象是“焦点问题”，名义小组的对象是头脑风暴的结果。

5)目的不同。焦点小组的目的在于解决“焦点问题”，名义小组的目的在于决策

群体创新技术: 头脑风暴法，名义小组技术(头脑风暴法的深化应用)、德尔菲技术、概念/思维导 图、亲和图(将大量创意分类)、多标准决策分析。

群体决策技术 : -致同意， 大多数原则，相对多数原则，独裁。

系统交互图(Context Diagram)是范围模型的一个例子，它是对产品范围的可视化描述，显示系统（过程、设备、信息系统等）与参与者（用户、独立于本系统之外的其他系统）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。例如，软件需求分析中的DFD、用例图都可以看作是系统交互图。

**需求分析技术：**流程图、用例图、用户故事（3C原则）、词汇表、ER图、分解图、数据流图、原型图(结果)

需求分类–渐进明细

客户需求(Customer Requirements)；2)产品需求(Product Requirements)；3)产品组件需求(Product Component Requirements)

客户需求是可以理解成客户为什么要做本系统，要解决什么问题，客户对系统有怎样的期望，希望能具备一些怎样的特点，简单的说，就是客户要什么。干系人的需要、期望、约束和接口要求被收集并转化为客户需求。
产品需求是能满足客户需求，并对软件产品规格进行了描述的需求，软件设计师可以根据产品需求进行设计、编码等工作。
产品组件需求，是对产品需求的进一步细化，分割成几个子系统、每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等。

业务需求/高层需求目标，功能需求，非功能需求、技术需求

分析业务目的和目标，将业务目标转化为用户行为。

从另外一个角度，需求可以分为功能性需求和非功能性需求两类，功能性需求就是系统具备怎样的功能，能做什么事情，而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。客户需求、产品需求和产品组件需求，都会包含功能需求和非功能需求。

通过以下必要的维度归属需求，如需求价值判断维度：广度、频率、强度。

使用人数很多、频率很高、需求很强烈，就是好需求。三者都不沾边，可以判断为无价值需求过滤掉。
用户故事

用户故事（User Story）：描述对软件（或系统）用户或客户有价值的功能,只是需求描述，而不是详细的需求规范。用户故事=用户+故事=人+故+事，那就是一个人因为什么原因要做什么事。

三要素： 角色、活动、价值

3C原则：

卡片（Card） – 用户故事一般写在小的卡片上。卡片正面写上故事的简短描述，格式为：作为一个<角色>, 我想要<活动>, 以便于<商业价值>。卡片背面书写完成用户故事的规则和完成验证标准，可随时补充。

交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的频繁的交流沟通。

确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

用户故事 VS 用例：

目的不同：用户故事适合探索需求。用例适合交付给开发和测试人员，且作为备案。

范围不同：用户故事更轻量级、概括化、更随意; 用例更详细、更正式。

创造方式不同：用户故事是由客户团队、开发坐一起写在卡片上头脑风暴出来的。用例主要是BA书写的。

寿命不同：用户故事在功能上线后就被丢掉，而用例会作为书面文档保存。

用户故事没有上下文关系，是一个个的需求点，无法连成面（用户故事地图一定程度上可以缓解）

从0到1搭建起来的有现场客户支持的新系统、快速迭代的互联网公司。对敏捷和用户故事认同、用户较配合的理想的团队--------合适用用户故事。

传统瀑布式开发的团队、运行多年（没有现场支持客户）的大系统—系统化分析。

体会： 在需求初期调研阶段，以用户故事和问题跟踪表为工具快速捕获整理需求。

     需求确认较明确后，以需求文档内嵌用例的方式发给客户做评审确签名确认。

需求挖掘

需求挖掘，又可理解为需求评估等。通常产品经理在进行需求挖掘时需要结合常用需求挖掘方法进行深度思考分析得到产品需求。需求挖掘是先分析需求背后的动机找到深层需求，然后根据深层需求进行需求扩展形成产品需求。在分析需求背后的动机时会出现以下几种情况：

第一种是需求较为简单，出现没有找到深层需求的情况，此时对需求本身进行扩展形成产品需求即可；

第二种是找到了深层需求，然后进行需求扩展形成产品需求；

第三种是找到了深层需求但需要更深入一层挖掘用户心智，然后在此基础上进行需求扩展形成产品需求。

01 3W分析法
3W是指“What，Why，How” ，即这个需求是什么，为什么会产生这样的需求，如何将需求转化为产品进行后续的价值分析。3W分析法是比较聚焦的需求挖掘方法，一般只会进行针对性的1到2个产品方案设计来满足需求。

02 马斯洛需求层次理论分析
马斯洛需求层次理论把需求从低层次到高层次分别为七个层次：生理需求、安全需求、归属与爱的需求、尊重需求、认知需求、美学需求、自我实现的需求。

03 卡诺模型
卡诺模型（KANO模型）将用户需求分为基本型需求，期望型需求，兴奋型需求，无差异型需求，反向型需求五类需求，通过对用户需求的分类来对用户的不同需求进行区分处理，从而帮助产品经理找出提高用户满意度的切入点。

（1）基本型需求，又称为必备需求。如果不具备，产品的可用性会大大降低，所以用户的满意度会大幅下降。有，满意度不会提升。

（2）期望型需求，用户想要的，但又不是非要不可。如果满足此类需求，用户的满意度会提升。如果不满足此类需求，用户的满意度会下降。

（3）兴奋型需求，亮点需求，用户完全出乎意料的产品功能或服务，使用户产生惊喜感的需求。如果满足了用户对于兴奋型需求的期望，用户满意度会急剧上升。反之，没有用户的满意度也不会降低。

（4）无差异型需求，无论产品提供或不提供此类需求，用户满意度都不会有所改变。此类需求，有或没有都不会对用户的满意度产生影响。

（5）反向型需求，是指会引起用户不满的产品功能或特性。

例如我们运用卡诺模型对浏览器的用户需求进行分析，可以得到：

属于基本型需求的有浏览网页、收藏网址；

属于期望型需求的有网页打开速度快、系统占用资源少、界面简洁、拦截恶意广告等；

属于兴奋型需求的有屏蔽网页广告等；

属于无差异型需求有分享、意见反馈、退出前确认，反向型需求有强制弹框广告、推送过多通知等

04 5W1H分析法
5W1H分析法，中文也叫六何分析法，包括：What(是何)、Why(为何)、Who(何人)、Where(何地)、When(何时)、How(如何)。借鉴“5W1H分析法”，在做互联网产品或移动互联网产品设计时通常还需要考虑产品价值，于是可以用5W1H1V分析法来思考产品和功能：

What：用户可以用这个产品或功能能做什么？产品或功能为用户解决什么问题？

Where：用户在哪里会用这个产品或功能？

Why：用户为什么用你的产品，而不用别的产品？为什么需要这个功能？和其它产品有什么区别？

When：用户在什么时候会用这个产品或功能？

Who：谁是我们的用户群？产品或功能为谁设计？

How：用户如何使用这个产品或功能？

Value ：产品的价值？

PSP分析法是P(person)、S(scenes)、P(paths)的简写，即“角色-场景-路径”分析法。

角色是指对同一个功能，不同角色的需求不一致。产品经理在面对一个需求的时候要搞清楚提这个需求的人的角色是什么。

场景是指每个需求都有一定的应用场景，产品经理在分析需求时需要分析真实发生的场景，考虑实际情况。

路径是指分析满足需求的关键路径。用户提出一个需求，产品经理在设计功能的时候要去考虑能不能够在一条完整的路径上都去满足他，而不是说只满足这个需求中的某一部分

需求分级

需求归类匹配产品定位
用户体验要素有五个层次：战略层、范围层、结构层、框架层、表现层，其中涉及战略层和范围层，战略层和范围层即表示：

战略层：企业与用户对产品的望和目标（做什么，为谁而做？）

范围层：功能及其内容需求集合（需要做哪些？）

到这一步，要考虑产品定位，战略目标、目标用户、功能范围。

需求要为产品的目标服务，不然功能越做越多反而用户流失。确定目标用户很关键，分析目标用户的过程也很有趣，因为只有这样，才能会这个阶段的需求进行再次筛选。

定义优先级

需求优先级的判定要在产品所处生命周期的判断之上，不同产品生命周期的产品侧重点不一样。

产品初期（0-1）：最小可行产品(MinimumViable Product,简称MVP)，满足用户核心需求，快速上线，快速迭代。积累种子用户。

成长期：继续打磨核心需求，完善功能短板，让产品朝着指定方向发展。这时候会加大运营投入，用户大量导入，需求激增。这时候团队压力很大，要控制好需求，把握好核心用户，把资源用在刀刃上。同时重点关注留存和活跃，提高粘性和使用时长。

产品成熟期：不断打磨产品，巩固产品壁垒，制造兴奋性需求，挖掘潜在用户，扩大用户规模。同时要开始考虑变现。

产品衰退期：尽量延长产品生命周期，持续带给用户新鲜感，留住用户。扩充品类，孵化新产品。

二、系统架构设计

1、为什么要做系统架构设计

做任何事之前，建议我们都要先问一下为什么。这样有利于我们以终为始，不至于在执行或做决策的过程中出现偏差。

那么我们在做软件开发时，为什么要做软件架构设计呢？我认为做架构设计的真正原因是：

软件开发是一个复杂的工程，且我们对软件是有功能和性能要求的，我们必须先做设计论证功能和技术的可行性，不能边做边想。
软件开发需要多人相互合作，所以必须先做出设计，有了全貌，才能让参与开发的人了解自己的位置，才能有条不紊的进行开发。
基于以上两点，所以我们必须要做软件设计，可能有人会说，我学习软件开发的过程中，从来没有做过软件设计，同样开发出软件了。这种情况的愿因是：

软件不够复杂，功能简单，也没有并发、响应时间的要求。
不需要多人协作，一个人开发了所有功能。
举个例子，如果是自家盖三间大瓦房，可能就不需要先做设计，如果要盖一幢公寓，就需要先做设计了。

简而言之，架构设计的主要目的是为了解决软件开发复杂度太高而提出的一个解决方案。

2、系统架构设计都设计哪些内容

系统架构设计就是把系统需求转化为软件系统的过程。这个过程包括：设计系统的整体结构、划分功能模块、确定每个模块的数据库设计和实现算法，从而形成具体设计方案。

从软件开发工程师的角度看，系统设计包括软件结构设计、数据设计、接口设计、过程设计。最后形成概要设计文档和详细设计文档。文档内容包括：软件架构设计、数据库设计、模块详细设计等。

这个过程中，其实很大一部分时间是在和产品一起对需求、对功能、了解业务、了解业务特性、技术调研、技术选型等。因为上面说了，架构设计的主要目的是为了解决软件开发复杂度太高而提出的一个解决方案，所以我们做架构设计是，首先就是要分析出系统的复杂度。只有正确的分析出系统的复杂性，后续才能在架构设计时不会偏离方向。

明确了业务和系统复杂度之后，就可以进行系统架构设计了，很多人可能以为系统架构设计和超前的技术，天才般的创新能力联系在一起，自己悟性不高，这辈子不可能成为架构师了，其实不是这样的，绝大多数架构师无须天才般的创新能力，成熟的架构师只需要对已经存在的技术非常熟悉，对已经验证过的架构模式烂熟于心，然后根据自己对业务的理解，挑选合适的架构模式进行组合，然后再对组合后的方案进行修改和调整即可。

3、系统架构设计的原则

做任何事情都有道。道即路也，如从广州开车去北京，顺着G4京港澳高速走就可以到达北京。

系统架构设计也有道，架构设计的道就是架构设计的原则，主要有三个：

1. 合适原则：合适优于业界领先。
2. 简单原则：简单优于复杂。
3. 演化原则：演化优于一步到位。
   按照这些原则去做，有助于我们做出最好的选择。

另外，上面也说了，架构师需要对已经验证过的设计模式烂熟于心，目前，在运用面向对象的思想进行软件设计时，需要遵循的原则一共有6个：

系统架构设计拓展看此处

三、懂得代码设计

四、有优化手段