[2020]《有效需求分析》作者: 徐锋

内容简介：

　　本书首先借助生活中的隐喻故事帮助读者建立“问题级需求”思考意识；接着通过一个需求变更处理实例阐释如何在日常需求工作中落实“业务驱动、用户导向的需求思想”；然后引出“组织应用类软件系统需求全景图”，帮助读者理解需求分析的四条主线：价值需求、功能需求、数据需求和非功能需求。本书可作为计算机软件专业本科生、研究生和软件工程硕士的软件需求分析教材，也可作为软件工程、软件开发管理培训的教材，更是一线项目经理、需求分析人员、甲方需求管理人员的必备参考书。

本书是围绕着“我们要做什么，应该如何思考？”为主线展开的。 

用故事、案例，让大家从中感悟到需求分析的有效思维，并且使用一系列的“任务指引卡”模型帮助大家快速记忆。 

18个按需求组合的关键任务，针对每个任务的一步步指导，以及每个任务输出的“软件需求规格书”片段模板，让大家更容易在实践中应用。

作者简介：

　　徐锋 资深需求咨询师，致力于IT系统、互联网及消费电子产品的用户研究，需求分析与产品策划的研究，擅长从生活、实战中抽取可复制、可落地的工作方法。在过去的十几年时间里，为诸多大型金融机构、政府组织、通讯运营商、互联网公司、消费电子厂商、行业软件开发商提供过卓有成效的咨询与培训服务。著有《软件需求最佳实践》等畅销书籍，多次受邀成为中国软件技术大会、中国软件工程大会、MPD等大会的演讲嘉宾。

精彩书评：

壹：短评

#  价值+详细（功能，数据，非功能）。理想主义和自由主义。书中例子生动～

#  写给人看的，通俗易懂。

#  大量的框架工具。可以看出，作者的大型项目经验十分丰富，当项目规模超过 1000 人天，管理协调难度大大增加，就需要构建各种框架工具来降低难度。文中的工具，应该都是实战总结，作者还补充了很多场景化的小故事，帮助理解工具解决的具体问题。对于想自己建需求分析工具的人，还是很有参考意义的。

贰：

读过几个小节后，感觉非常好，有点相见恨晚，正本书读起来轻松，没有那种靠专业词语，客话套话来显现自己，靠的是货真价实亲身经历，对业务流程，优化有自己独到之处，是做需求分析人不可多得参考资料。看过本书之后各种概念，要做的工作一清二楚，对实际工作有指导意义。个人强烈推荐，值得研究。大家可以把自己的读后感一起来分享。聊聊如何做好需求分析。

叁：

需求分析思想：

需求分析最重要的是思维方式，要站在用户的视角展开，即“业务驱动”思想，关注问题而非方案。

以变更/优化型需求为例，针对用户提出的需求，首先要判断是方案（直接告诉你做什么）还是问题（告诉你他实际想解决的问题）。第一步就是澄清问题，2W1H，明确谁的，什么问题，并知道遇到该问题当事人目前是怎样解决的，若有概念的不确定，需明确；第二步了解该需求具体的使用情况，2W1H（谁，什么时候，怎样做），业务术语澄清，并了解该需求的使用频率及满足不了的后果，涉及到哪些人；第三步，提出建议，分别列出可行方案，成本比较，提出建议，对用户而言的优缺点等，并可简单问一下有无其它类似需求。

将了解的所有情况，以表格的形式记录下来，详见书中模板。

肆：

信息系统的核心价值之一是支持管理，而管理支持的核心是通过管理流程事前规避风险，通过规则和审批事中控制风险，通过数据分析做事后优化。

在数据分析过程中，首先要明确“数据≠信息”，数据后，不妨多问为什么，从而挖掘出用户所需要的信息，比如，大家查询当日天气情况，实际是想了解如何穿衣等等。判断数据的完整性，需要明确想要获得的信息具体是什么。

管控点识别即通过数据分析实现的管理意图。比如一个考勤系统，可以通过业务报表来继续挖掘用户的深层需求，比如统计员工迟到情况，其实是为了评估员工积极性，找到该管控点，然后再从积极性角度分析，还有哪些报表可以反应该管控点，可以就此问题与用户进行交流。

伍：

识别出业务场景后，接下来就是进行场景分析。

先站在用户的角度，对场景进行描述；

然后采用“场景——挑战——方案”的过程进行分析。

一般先从用户视角将场景进行细化，形成事件流，然后站在用户角度逐条分析会遇到哪些问题，最后针对问题，寻找解决方案。

陆：

识别业务场景，目的是让用户产生共鸣，实现“用户为中心”的需求获取与理解，具体技术表现为用例和用户故事。

用例即业务场景、使用场景，比如同样是增删改查，不同的用户就会有不同的使用场景，比如图书管理员需要新增图书时可能有两种情况：办理图书入库、办理遗失图书返库，那我们如果简单定义成新增图书就不如定义成办理图书入库、办理遗失图书返库更容易被使用者接受。

用例也是有边界的，那么多大才算是合适的用例呢？我们把这个边界称为粒度。实际上一个用例就是一个完整的业务场景，应该是独立的、可汇报的、可暂停的单元。在一个信息系统中，业务流程是指不同岗位之间通过协作满足外部服务请求的过程；而业务场景则是以某岗位为主完成的、相对独立的、可以汇报的业务活动。因此，从某个角度而言，粒度是由组织分工决定的。

用户故事，就是让用户或用户代表使用固定格式描述其需求，具体格式为：“作为xxx（角色），希望通过系统xxx（解决方案、功能要求），以便达成xxx业务目的、要解决的业务问题”。如果用户故事过大，还需要明确粒度的标准，对故事进行拆分。

微Q同号:2802031363    公众号：pengdiary

本文章为有偿阅读：1元/篇 ，请自觉投币。