在下早年干过系统需求工程师的活，后来做过产品
回答本题当属合适

说明：本讨论仅限于互联网和软件行业

正文：

十年前的需求流转是这样的：

需求提出人----系统需求工程师----程序员

现在的需求流转是这样的：

需求提出人----产品经理----程序员

这样来看，系统需求工程师 与 产品经理 不是一回事吗？
是的， 但从现实的角度来讲，他们的技能、工作方式和产出却大不一样 。

因为真正意义上的系统需求工程师要有 SA（见附注）的能力，而当今市面上的产品经理则不具备

举个栗子：一个从零做起的系统
一、产品汪 与 程序员 版
第一天，产品汪跟程序员说，A商家要做活动，打8折促销，这个功能你实现一下，程序员照做了；
第二天，产品汪跟程序员说，B商家也促销，打7折，可以马上上线吧？
程序员一楞：怎么可能，这得一天；
产品汪：你昨天不是做过A商家的打折活动，复制粘贴一下不就行了吗？
程序员心堵：得重做。
产品汪：不都是打折吗？
程序员恼，不搭理产品汪，埋头重新做了一次；
第三天，产品汪跟程序员说，C商家做活动直降50元，程序员一楞，心里骂句MLGB不早说，然后又埋头重新做了一次；
第四天，产品汪跟程序员说，D商家做满300减80，
程序员怒了：你妹的，有啥需求你不能一次说清楚？ 
产品汪也不高兴：妹的，这需求都是商家提的，他们也没同一天来找我说呀；
程序员说：你丫不会想想清楚，规划一下再给我？
产品汪说：这怎么规划，我又不是神仙，我怎么知道这么多商家会有这么多奇怪需求？
程序员说：这次老子认了，下次别找我。 然后把代码写了。
第五天，产品汪找到程序员：E商家要做“第一件半价”活动；
程序员：……！！……！！……滚！！
产品汪找到了开发经理：你们有个同学不配合。开发经理出场镇压。
程序员心里想：你小子给我记着，敢打我小报告，看我以后怎么玩死你……
第六天，产品汪找到程序员说：A商家不做打折了，他们也要做满400减100
……

有没有发现，这就是 产品 与 程序 之间的万年宿怨
产品经理：这帮技术宅态度有问题，一个个拽得258万似的，工作不配合，产品经常推不动；
程序员：产品经理就是帮213，完全没脑子，需求根本没有规划，今天提了明天改，明天改了后天加，大后天又玩新花样，动不动就说：这是老板要求的、这是客户要求的、这是用户说的，CAO！

二、系统需求工程师 与 程序员 版
客户跟系统需求工程师说要做打8折促销，系统需求工程师马上想到打8折只是一个促销实例，
为此需要构建一个 促销模型 ，可以根据不同的促销方案 和 力度 配置不同的实例，
于是找到开发经理说：我们要搞一个促销系统，建议用策略模式实现，可以做成后台界面配置的方式，暂时只需要实现打折类型的促销，打折幅度需要后台可以配置，可以找个一两年经验的程序员搞一下，顺便让该程序员也提升一下对设计模式的了解和掌握，学到点新东西，相信他会觉得很有意思。
后来，客户陆续跟系统需求工程师提了无数种促销方案：直降、满减、买送……
程序员同学非常嗨皮的徜徉于 设计模式 的学习中，需求来得慢的时候自己重构重构，看着代码又优化了就幸福的忘了自己没有妹子，还不时主动攀着系统需求工程师问：哥们，客户有没有新的想法啊？比如，秒杀、随机免单什么的呀？现在很流行的，我可以做的！

归纳一下现在市面上的产品经理 和 曾经的系统需求工程师：
产品经理
主要技能：需求解析、画饼
主要工具：Axure、office系列、Xmind等
主要产出：概念、脑图、产品界面原型 等组成的 PRD
要求：思路清晰，头脑灵活，沟通能力强，推动力强

系统需求工程师
主要技能：需求解析、系统分析与设计
主要工具：UML工具
主要产出：UML架构图
要求：5年以上开发及架构经验，思维结构化、层次化，善与人交流

附：
SA：系统分析师 或 架构师 ，前者偏重问题域，后者偏重解决域。这二者是一个合格的系统需求工程师必须兼备的素质

需求工程系列：

软件需求工程习题1（1~4章）
软件需求工程习题2（5~7章）
需求工程中的面谈和原型（8、9章）
需求获取方法之观察与文档审查（10章）
需求工程规格说明、需求验证、需求管理（11~13章）

---

第十章 需求获取方法之观察与文档审查

常见的观察方法：
1.采样观察（Sampling Observation）：传统、简单的观察方法。
2.民族志（Ethnography）：深入到用户中，长期、浸入式的观察方法。
3.话语分析（Discourse Analysis）：对用户之间的交谈行为的观察。
4.协议分析（Protocol Analysis）： 对用户任务的观察。
5. 任务分析（Task Analysis）：专门针对人机交互行为进行的观察。

观察方法的适用情况：
1.当用户无法完成主动的信息告知，或者用户与需求工程师之间的语言交流无法产生有效的结果时，采用观察方法。
2.用户无法完成主动告知的原因归结于事件的情景性（情景性是指某些事件只有在和他们发生时的具体情景环境联系起来才能得到理解）。

情景性的重要性质：
突现（Emergent）：集体促成 ，互动中突现 ，互动联系理解事件
局部（Local） ：事件及解释在特定的上下文环境 才成立
暂时（Contingent） ：事件及解释受活动演进过程的影响
涉身（Embodied） ：事件及解释需要特定参与者的认知和能力
开放（Open） ：对事件的解释要保持开放，以进一步完善
模糊（Vague） ：基于潜在知识 进行的模糊事件解释

采样观察分为2种（据实际情况结合使用）：
时间采样：指定时间间隔进行观察（7个8小时工作日内5个10分钟）
事件采样：有目的选取整个事件进行观察（董事会、用户培训会）

民族志：
最早由人类学家提出，用于理解原始社会的社会机制。民族志在需求工程中的普及主要归因于CSCW（计算机支持协同工作）领域的研究和发展。目前，民族志成功应用的典型示例也都是复杂的协同问题 ，旨在了解工作的社会性因素，解决突现的情景性问题。

文档审查：
是一种传统的需求获取方法，是专门针对文档进行的需求获取活动。

文档审查的获取对象包括：
 原有产品或竞争产品的需求规格说明
 硬数据
 客户的需求文档（委托开发的规格说明、招标书）

文档审查的方法：

小结：
在需求获取的诸多方法当中，观察的作用越来越显重要，它可以帮助解决情景性问题。
采样观察的应用方法较为固定，但民族志的应用非常复杂，需要很多的实践积累。
文档审查方法是专门用于处理各种硬数据的需求获取方法。

为什么说在面谈时仅仅倾听是不够的，观察和记录所观察的内容同样是很重要的？
面谈并不能确保用户能够将所有的信息都告知需求工程师，诸如一些语言无法确切描述的事务，而观察能够了解用户真正做什么，还能够获取到其他方法不能得到的用户及其工作环境的信息，还可以对从其他方法获取的信息进行确认，所以我们应该重视观察方法的应用。

那应该观察些什么呢？
观察客户所处的环境（得出何种需求才能更适合客户）。 观察客户行为、习惯特征（得出更适合客户使用的软件需求）。

---

习题：

1.当用户无法完成主动的信息告知，或与需求工程师之间的语言交流无法产生有效 的结果时，有必要采用（ 观察法）。
2.以下（ C）不是情景性的重要性质？
A、突现
B、涉身
C、完善
D、模糊
3.下列（ D）不是需求获取常见的模型驱动方法？
A、面向目标的方法
B、基于场景的方法
C、基于用例的方法
D、基于采样的方法
4.航空调度、证券交易、医疗手术控制等复杂的协同问题都具有（ 突现）的情景性。
5.民族志的一个主要应用目的就是研究和解决（ 复杂的协同）问题。
6.复杂的工作总会同时存在着正常流程和异常流程，异常流程大多是一些特殊情况下 的处理，限定了异常处理的上下文环境，即异常处理具有（ 局部）的情景性。
7.有很多重要工作的进行需要用户具备一定的认知，认知要求已经成了用户工作必备 的部分，即工作具有（ 涉身）的情景性。
8.采样观察是简单的观察方法，应用目的是发现（异常流程），验证用户所述知识和实际的一致性，以及发现默认知识。
9.时间采样允许需求工程师建立指定的（ 时间间隔）来观察用户的活动情况。
10.文档审查主要获取对象包括相关产品的需求规格说明、（ 硬数据）和客户的需求文档。
11.文档分析通常是数据建模方法的一个基础部分，它是通过检查采集的硬数据来确定（潜在的需求）。
12.如果当前存在一份客户的需求文档，就可以使用（ 需求剥离）技术，从需求文档中抽取单个的需求并加入到新的需求文档之中。
13.采样观察分为时间采样和（ 事件采样）2种。
14.文档审查是是专门针对文档进行的（ 需求获取）活动。

□ 做好一款软件从哪里开始呢？→ 客户需求的调研；
□ 一款软件的价值高低由哪个环节决定呢？→ 软件的分析与设计；
□ 软件顺利完成开发靠什么？→ 高效的项目管理；
□ 软件开发的主要角色？→ 客户、软件项目经理、需求工程师、开发工程师和测试工程师；
完成一个软件系统，需要有相应的分析设计方法、项目管理方法以及过程中不同阶段角色的分工协作。

软件成功完成需要客户、软件项目经理、需求工程师、开发工程师和测试工程师这五个核心角色的高效协作，这个协作的基础之一就是对“需求分析和软件设计”文档的理解、认同高度一致，这五个角色对文档有各自重点关心的内容，如

1.提需求的客户：可以清楚的表达出自己的需求、并在分析和设计期间就能够确认所提的需求是否被理解、并正确地反映到设计文档中；

2.软件项目经理：如何在项目开始前就能建立起有效的项目计划、实施流程、资源匹配、交付物模板、验收标准等事项，并可以达成项目管理的三大目标（质量、进度、成本）；

3.需求工程师：如何高效地调研需求、理解需求、分析需求、设计需求，如何将客户的原始需求准确地转换为需要开发的系统功能、并让文档容易传递给后续的开发工程师；

4.开发工程师：如何快速地理解需求文档，检查和判断需求文档的正确性、可行性。准确无误地将需求文档转换为技术文档是决定后期开发成功的重要保障；

5.测试工程师：如何快速地理解需求，编制出可以验证完成的系统是否满足需求规格书、技术设计的用例脚本，并自信地给出判断结果；

上述五个角色之间的重要交集点就是需求文档。因此，需求文档要建立共同语言、表达标准，让这五方之间不但可以定性、而且可以定量地进行交流、传递、确认、验收。

谈到软件工程，可能马上联想到的是软件的发展历程、理论、概念、大学教材等，认为软件工程不是用于支持实际软件开发的知识。《大话软件工程—需求分析与软件设计》是一本追求实用的分析与设计工具书，它集理论、方法、工具、标准于一身，尝试着为工作在一线的客户和软件工程师之间、软件工程师与工程师之间提供一套可以准确地进行交流与传递的“方法和标准”。

一、书的特点

1.图形化
本书将软件工程划分了不同的阶段和层次，在不同的阶段和层次中分别提供了对应的参考标准图形。图形化的表达方式可以明显地提升工作效率和产品质量。本书采用的图形是“自然图形”表达方式，图形是包括客户在内五个角色正确、快速交流的“共同语言”，而且不需要特别培训就能做到。
全书提供了约480张彩色实用图形。

图1-1 全书彩色印刷

图1-2 对每一种模型图给出详细的画法说明和使用案例

2.标准化
本书制定了从图形表达到文字描述的标准化方式。实现需求工程师和开发工程师之间的无缝传递、继承。所有的交付物不但定性而且定量，所有的交付物有理论、方法、模板、标准。

图2-1 书中标准化的知识体系

图2-2 常用分析与架构的标准模型

图2-3 常用画图标准符号

3.工程化
将软件实现的各个环节按照工程化的模式串联起来，使软件行业的设计过程和设计资料如同建筑业、制造业一样，可以按照流程进行操作，支持项目经理高效管理、达成项目管理三大目标。

图3 软件工程的标准作业流程

4.逻辑线
本书从需求调研开始直至应用设计为止，全书始终以“逻辑”为分析和设计的指导主线，让读者按照逻辑思路去理解知识、同时按照合乎逻辑的表达形式展示设计结果。确保分析和设计的成果-需求文档在满足软件工程师的要求的同时也可以让客户理解、确认、签字。

图4 逻辑线贯穿全书的说明

二、书的构成

《大话软件工程—需求分析与软件设计》构成的简介
本书追求的是软件分析和设计过程的工程化作业，所以书中的内容是按照软件工程师的实际工作流程编排的，以图3所示的流程为主线，将分析与设计需要的知识、方法、工具、标准等挂接在流程的相关节点上，方便读者理解、查询、引用。
全书共分为6篇22章
□第一篇：基础知识，分析与设计所需要的基础理论、概念；
□第二篇：需求工程，包括调研前的准备内容、调研方法、记录模板、分析方法、需求规格书的编写等；
□第三篇：设计工程-概要设计部分，系统的规划、设计理念、系统主线、架构规划、功能规划、数据规划等；
□第四篇：设计工程-详细设计部分，针对客户的业务内容（流程、界面、数据等）进行优化、详细的设计；
□第五篇：设计工程-应用设计部分，针对系统的应用内容（原型、操作、权限等）进行规划、详细的设计；
□第六篇：设计工程-综合设计部分，对系统的客户价值、管理价值、业务验证、应用验证方面进行设计；
□附录：能力提升训练：对读者的逻辑思维方法、逻辑表达方法等进行训练；

三、书的目录

作者从事需求分析与设计的培训工作已有二十多年，可以进行企业的集体培训，个人购书者可以参加《大话沟通群》进行直接交流（沟通群地址见书的前言）。