《有效需求分析》是一篇引人思考的文章。作者通过对需求分析的重要性进行深入探讨，强调了有效需求分析对项目成功的关键作用。文章提出了一系列实用的方法和技巧，帮助读者更好地理解和应用需求分析的过程。这篇文章深入浅出地阐述了需求分析的重要性，对于提高项目成功率具有很大的指导意义。
有效需求分析读后感第一篇
读过几个小节后，感觉非常好，有点相见恨晚，正本书读起来轻松，没有那种靠专业词语，客话套话来显现自己，靠的是货真价实亲身经历，对业务流程，优化有自己独到之处，是做需求分析人不可多得参考资料。看过本书之后各种概念，要做的工作一清二楚，对实际工作有指导意义。个人强烈推荐，值得研究。大家可以把自己的读后感一起来分享。聊聊如何做好需求分析。
有效需求分析读后感第二篇
之前无知的认为，产品设计是一件简单的工作。
现在真正从事需求分析和产品设计工作时，才发现并不是那么回事。
产品经理门槛看起来并不高，可谓“人人都是产品经理”，但想做到优秀，确实有些难度。
我想有个××功能，你帮我实现？
我碰到这样的问题，你给出个解决方案？
我们想做一个××系统，你看怎么弄？
…………
以上问题是不是经常在工作中遇到？
有时候真是一头雾水，不知从哪着手。
这个问题的真实需求到底是什么？这个系统我该怎么设计？
这本书给了我一个很好的答案。
从问题，到系统，到业务流程、场景、接口，再到数据、质量需求，从大到小，层层递进，让你由上而下，从产品架构上有了比较清晰的把握。
总之，这本书，可实操、可落地。有干货。
有效需求分析读后感第三篇
这是一本从事产品行业的必读书籍，无论你是初入职场的小白，还是久经沙场的专家，想必都能通过此书获取到不同凡响的收获和共鸣。
对于行业小白，这本书为你描绘了一名优秀的产品经理应该具备的能力，也把你提前识别了将来可能遇到的挑战，但更重要的是这本书梳理了需求分析的核心框架及可落地的操作工具。
对于行业老鸟，这本书帮你重新复盘了需求分析中各种经验和教训，也通过作者自己的感悟和体会梳理了不同场景的应对方案，当你回过头来重新审视过去或当前正在面对的需求问题时，或许你会不禁“啊哈”一下，原来是这样啊！
至少对我而言，这部书的启发意义还是极为显著的，至少包括以下方面：
作为B端产品设计，我们在识别业务不同场景下的复杂问题时，不如从这4点做下思考和对齐，通常意义上，提效是任何工具类系统或业务管理系统的核心目标；除外面向不同的执行角色，赋能可以帮助他们实现线上作业和管理；当然对于平台而言，业务流程中的数据也是不可忽视的价值；最后也是最具挑战的便是业务管理数字化，因为这要求业务体系中的所有对象、流程、制度和标准都需要被系统记录和驱动，数字化的背后是业务流程的再造，是管理思维的升级，是对人性的遵从而不是压制！
这是一个初级产品或需求分析师常犯的错误，当我们面对一个具体的业务需求时，往往容易被动地陷入这个需求的实现评估过程，殊不知这是一个巨大的陷阱，不仅会造成需求识别的偏误，更会导致大量的无用功。因此需求识别的关键动作就是要挖掘业务需求的真相，变方案级需求为问题级需求。当然，要做到这一点除了要求我们有专业的需求识别能力，也要求我们对业务有更深刻的理解和体感，这是产品能力的体现。
思维方式和视角的转变对一名优秀的产品而言是极为重要的，当我们习惯性的将业务需求带入到实现评估过程中时，其实就已经犯了混淆方案级需求的错误了，因此为了消除这种固化的思维模式，我们需要刻意训练自己对业务价值和场景的理解，通过与需求人员的反复对话和追问，不断识别其背后的业务诉求和实际场景，刨根问底、不耻下问或许能为你和需求方共同打开一片新天地，在那里或许才是你们真正找寻答案的地方。
既然我们已经意识到了思考视角转变的重要性，我们就需要在遵循照做的过程中坚持某些原则，这其中就包括我们需要深入问题场景，体察用户的感受，了解用户的目标，因为通过这个方法可以帮助我们建立起和用户的共情，从而找到那些被忽视的线头，从而串联起真正的需求主线。同时在这个过程中，我们可以基于主线去梳理核心问题，而将那些与主线无关的噪音和冗余信息剔除，毕竟做减法是为了专注，而无效的加法只会自欺欺人。
实质上这是一种场景化的思维训练，组织在制定业务目标时往往是一个代表某种业务结果达成的指标，但指标本身可能是许许多多生产关系所决定和造就的，它可以代表某种相关性，但或许无法证明因果性，所以我们除了设定业务指标，也可以在需求早期界定时就规划好其如何帮助不同业务角色在场景中解决问题，达成场景目标，相较于静态的指标，这样的描述会显得更生动，也更有指向性，有助于驱动项目相关人员推动需求的达成。
这里提到的本质还是业务视角和思维的养成方法，我们需要珍惜每一次和业务方对话的机会，了解他们的话术风格，表达框架和思考维度，切忌用一些所谓的产品术语去体现自己的专业，放低姿态是为了能更好地收集信息和搭建顺畅的沟通渠道，唯有这样才能真正借助自己的专业去解决业务问题，当然我们在过程中除了对齐语言体系，还要尽可能的利用VOC、统计数据等去建立表达的客观性，最后我们对问题的识别和分析务必要匹配客户的视角，这也是保证我们的分析和判断不会偏离轨道的关键检验方法。
在识别场景化的业务问题时，我们需要识别不同的业务角色及其核心的诉求，正向需求能帮助我们了解用户迫切想要的，可以通过系统赋能支持的部分；负向需求能帮助我们洞察用户担忧焦虑的，需要系统在上线后尽量规避和减少影响的部分，负向需求的识别往往需要配合运营计划，包括用户培训、宣导、制度激励和绩效考核等。如果只有正向而忽略了负向需求的识别，极容易导致需求上线或使用与预期不符，结果不达标等问题。
作为一个B端的业务系统或者产品工具，通常我们说的优化不外乎上面这4类：清除无效指的是剔除流程中的冗余节点，即充分遵循“奥卡姆剃刀原则”（如非必要，勿增实体）；简化高频指的是针对流程中的高频节点，通常也容易成为业务卡点，我们需要不断提升自动化能力，简化人工操作，提升效率；整合依赖指的是将流程节点中的上下游中相互依赖的部分识别出来，通过系统校验和数据流转，实现跨节点的整合，同样提升流程效率；自动化繁琐顾名思义，指的是将流程节点中业务规则复杂、策略判定繁琐的部分单独抽离出来，结合算法、人工智能等技术能力逐步迭代为自动化处理的效能工具，大幅提升流程智能化能力。
人机交互和人机界面的核心差异在于：前者通过情感化的界面交互驱动用户行为，同时在界面设计的过程中也更关心用户的心理活动，期望通过友好的交互引导简化用户的思考和犹豫过程，使其更顺畅平滑的进行作业活动。
用户意图和用户动作的核心区别在于：前者是遵循用户的内心和意愿，后者以管理和规范着手约束用户行为，好的产品设计一定是在用户主动意愿和平台规范管理之间找到合理的平衡点，通过巧妙的制度和策略设计令用户接受甚至有意愿地去执行。
无论是流程图还是用例图，都是产品需求分析和问题识别过程中的有效工具，用例图能帮助我们构建更具体的对象-场景关系，详尽的用例图能让我们还原真实业务场景中的复杂生产关系，有利于后续的方案设计和完善；流程图能将业务的生产活动通过不同对象/组织间的串联完整地表述出来，能帮助我们洞察到当前问题的全局流程、上下游依赖和组织间的联动关系，在向上汇报和管理决策时，更有助于识别作业流程以外的问题，包括组织设计、角色分工、资源分配不均等
有效需求分析读后感第四篇
最近在一个技术群里看到张逸大佬强力推荐一本关于需求分析的书《有效需求分析》，于是在 Kindle 上下单了，读完后有一种相见恨晚的感觉。
从书中的一些案例可以看出，作者擅长 ToB 软件的需求分析，如果您是从事的 ToB 软件的相关工作，那阅读本书时会有更多的共鸣。
书中有大量的案例，阅读起来不仅不枯燥，反倒觉得挺有意思，特别是一些日常生活中例子，能引发我们更多的思考。
每一个章节都有能落地的产物输出，所有的产物整合在一起就是完整的需求文档，可以让你不仅知道一些理论，还知道怎么落地。
1、辛辛苦苦开发的系统，跟客户演示的时候达不到客户的预期；
2、上线后，客户反复提出“变更”，从客户视角来看是功能没有按要求完成，从开发的视角感觉客户在百般刁难；
3、边界难以控制，已经按照“要求”完成了，客户还不断提出新的东西。
读完这本书可以立即解决这些问题吗？答案肯定是不能，但能给我们带来启发和思考，能让我们在解决这些问题的路上往前迈进一步。
书中的内容不少，本文只是我结合自己的认知把觉得重要的点展开来说说。
什么是需求？书中给出了一个非常精炼的回答：现实和期望之间的差距。就是中间这个差距需要我们去思考、调研，这是一个迭代的过程，直到最后达到期望甚至超过期望，如果用了一些错误的方法，或者被客户牵着鼻子走，最后结果可能还不如现实。
开篇例举的一个生活中的小例子充分说明了什么是需求，什么是方案：
如果客户的接口人稍微懂点技术，在做需求调研时就很容易提出方案级的需求，这时就需要警惕了，需要用一些问题来深挖背后的真实需求，比如：
如果能挖到真实的需求，就可以根据情况来制定最优方案了。如果我们“完美”地满足了客户提出的“方案级需求”，最终的结果未必能让客户满意，客户通常善于发现问题，提出问题，但给出的方案往往不能完美解决问题。
在公司的内部其实也存在着这种问题，比如项目团队的同事在遇到产品满足不了的功能时，需要给产品提需求，经常看到的需求描述是：
这些都是方案，而不是需求，项目的同事根据自己的理解和认知完成了从需求到方案的转换，而这个方案很多时候并不是最优。
所以每每收到这种“需求”时，会马上跟项目的同事反复确认客户到底想要什么，了解到真实背景后，才能结合产品的功能给出合适的解决方案。
任何企业准备上一套系统有各种各样的原因，可能是为了提高生产效率、提高协同办公效率，也可能是为了做一些政绩。所以针对不同的场景，我们首先需要找出这个系统的相关干系人。
识别干系人有几个重要的判断标准：
如果能够准确的识别关键关系人，还需要对关系人进行分析：
做项目不光是要做好事，关键还要能搞定人，能让重点干系人感受到系统的价值，项目就容易成功。
我认为项目的前期最核心的就是上面两个步骤：挖出核心诉求和找出重点干系人。剩下的就是分解需求进行开发实现了。不同的团队对需求分解和开发实现肯定都有适合自己的方式和方法，具体可以去阅读本书，下面说说在项目需求调研过程中经常会忽略的非功能性需求。
非功能性需求通常指，安全性、性能、扩展性、稳定性等等，这些非常重要，但也是最容易被我们忽视掉的。
非功能性需求针对不同的客户或系统会有不同的侧重点，比如：
这些非功能性的需求在调研阶段应该和功能性需求一起同步进行，根据客户的特征进行分析和识别，最终作为开发交付的一个检查项进行检查。
上面列举的都是和系统本身相关的一些要求，除此之外，还有很多的外在因素也是在前期调研时就应该考虑的，比如：
现在各种各样的书籍琳琅满目，感兴趣的书买了，就有机会去阅读，这是我一直以来的一个观点，做需求每个项目负责人都有自己的方法，但多读书学习一些方法和技巧，没准哪天就能用上了。再说了，多读书，往上可以提升我们的格局和眼界，往下也能夯实和固化我们的能力。
有效需求分析读后感第五篇
引导篇软件需求全景图有一天夜里，资深需求分析师老余刚忙完一个重要的项目，带着放松的心情进入了梦乡。这时他年仅3岁的小孩夜里醒来，吵着要吃饼干。孩子的妈妈首先被吵醒，带着情绪地训斥了小孩：“半夜三更吃什么饼干，好好睡觉！”没想到小孩不依不饶，继续哭闹着，不久老余也被吵醒了……他安静地起身到了客厅，找了一小会儿，果然没找到饼干！他随手拿了两块吐司面包走进卧室，脸上掠过一丝自信的微笑。“小子，没有饼干了，吃点面包填填肚子吧！”老余边说边把吐司塞到小孩手中。果然，小孩接过面包后就不再哭闹了，吃完一片就乖巧地躺下。不一会儿，老余家又回归了平静。在这个例子中，小孩提出“要吃饼干”，这实际上是一个方案级需求。由于家里没有饼干，因此妈妈认为孩子提出了一个不合理的需求，于是想办法让小孩放弃这个需求。而老余则快速意识到了这个方案级需求背后真实的问题级需求是“饿了”，因此找到了可行的解决方案——吃面包，小孩的需求也得到了满足。
变更/优化型需求分析任务执行指引
价值需求就是从黑盒子视角回答“整个软件系统为客户解决了什么问题、创造了什么机会”，“对于系统而言，最关键的干系人有哪些”，“各个重要干系人对系统的关注点是什么？有哪些担心（阻力点）”三个本质性问题。价值需求是组织应用类软件系统需求的灵魂和方向，但在很多此类需求分析实践中，这部分做得相对薄弱。这将使得项目范围更容易蔓延，客户从中获得的利益与价值不容易呈现，从而导致客户满意度难以有效提升。
详细需求就是从灰盒子视角完成三个主题的分析：“为了给客户提供业务、管理、维护支持，需要提供哪些功能？”“系统所涉及的问题域中有哪些数据，之间是何关系？”“所处的业务环境会带来哪些约束和质量要求？”
这三个主题实际上就是详细需求中的功能需求、数据需求、非功能需求三条主线。
功能主线的梳理可以从业务支持、管理支持、维护支持三个角度展开。
业务支持最典型的是三类：首先是固化、优化业务流程，因此业务流程是核心；其次是业务延伸到新的通道（诸如手机端），最后是将个人能力转化为组织能力，而这种能力存在于具体的业务场景中，因此“专家场景”是核心。
软件系统对管理的支持，主要可以体现在三个方面：
(1)事前风险避免，通过增加管理流程；
(2)事中风险控制，通过“规则”和“审批”；
(3)事后总结优化，通过“数据分析”。
前两种通常会在业务支持分析中统一处理；第三种则应该独立进行分析。
系统投入使用之后，还需要对其进行维护，最典型的包括初始化、配置、排错等，而这些运营维护场景也需要有相应的功能来支持。
要厘清维护需求，简单来说，就是从灰盒子视角回答两个问题：“有谁会需要对系统进行维护？”“他们需要执行哪些维护任务？”
功能主线是从“工作流”线索分析的。
数据主线，重点就在于厘清组织中的“信息流”。
数据主线的需求分析就是从灰盒子的角度回答三个问题：“系统相关的问题域中有哪些业务数据？”“它们之间是什么样的关系？”“每个业务数据的具体构成是怎么样的？”
非功能主线的需求分析就是从灰盒子的角度回答一个问题：“系统相关的外部环境会带来什么样的约束和质量要求”。
通过价值需求、详细需求（包括功能、数据、非功能三条主线）的梳理，识别并描述业务功能、业务报表、业务数据、质量场景、业务接口五类最小需求单元，基本覆盖了需求分析的所有内容。此外，还有两方面内容，一是约束，二是规则，有时需要单独进行更加详细的分析
组织应用类软件系统需求分析18项关键任务
项目目标也可以称为愿景，是组织应用类软件系统项目、产品的灵魂，是对于出资人（或发起人、属主）而言价值的体现。
目标/愿景分析任务指引
目标分析这一关键任务，可以分成四个步骤执行。
(1)访谈“问题”：通过对关键干系人的访谈，识别预期与现状的差距。
(2)研讨“机会”：通过与领域专家、技术专家、用户代表的交流，寻找潜在机会。
(3)定义问题/机会：描述问题、机会，以及它影响谁、产生什么结果。
(4)分析问题并确定解决方案：深入分析问题，然后确定策略级的解决方案。
访谈“问题”、研讨“机会”两个步骤可以根据实际的项目需要选择只执行一步，或者两个步骤都执行。
当你根据不同的项目触因选择合适的策略调研出问题场景，或者通过与业务领域专家、技术专家、需求团队从新业务、新技术、新人群的角度研讨出机会场景之后，接下来的一步就是清晰地定义它们。
经营层面的问题通常会是高层最关注的方向；
涉及管理模式、业务模式的宏观管理问题也会是他们关心的内容。千万别把操作层遇到的非共性困难当作问题列入目标分析。
描述问题只是第一步，紧接着应该说明这些问题影响了谁，给他们带来了什么样的影响，使得故事更加完整。在这部分的描述中，也要注意把握三个要点。
1)指代清晰，具体到人
2)视角匹配，影响明确
3)推理合理，层次清晰
我们需要提炼出一句话，对这个目标场景进行概述。其要点在于业务态、价值态，以“措施＋效果”的结构描述。下面这个例子就不太符合要求：构建物资管理系统，避免物资脱节。这个描述虽然是以“措施＋效果”的结构描述的，但“措施”不够业务态，“效果”没有体现价值态。更合适的是：基于安全库避免物资脱节，为门店扩张奠定后勤基础。
对于任何产品、项目而言，都会涉及各种干系人（Stakeholder），他们有着不同的诉求、关注点，甚至存在着各种冲突。在需求分析过程中，识别出关键干系人是十分重要的事情。
干系人识别任务指引
这个模板由类型、名称、说明、相关度、影响度五个栏目构成。
(1)类型：包括出资人/发起人、使用者、评价者、其他四种类型。
(2)名称：即该干系人的名称，通常会以职位的形式描述，也可能会以角色的形式描述。
(3)说明：简要说明他为什么是我们的关键或重要干系人。
(4)相关度：项目与他直接相关吗？涉及他的利益或责任吗？可以使用“高、低”两级评估或“高、中、低”三级评估。
(5)影响度：他对项目的方向、验收有很强的影响力吗？可以使用“高、低”两级评估或“高、中、低”三级评估。
相关度、影响度两栏通常仅限于开发团队内部阅读，不宜直接提供给客户代表阅读，以免带来不必要的麻烦。
干系人列表示例
识别出关键干系人只是第一步，选择合适的代表进行调研，分析他们的关注点、阻力点，以及满足关注点、避免阻力点所需的功能、非功能需求是一个重要任务。
干系人分析任务指引
干系人分析这一关键任务，可以分成三个步骤执行。
(1)选择干系人代表：如果有多个干系人，则应从中选择一位或多位典型的代表，以便聚焦。
(2)访谈干系人，分析关注点：通过访谈等手段，收集原始需求信息及相关反馈，从中分析出关键的关注点和阻力点。
(3)干系人关注点整理：横向评估不同关键干系人之间诉求、关注点的冲突，并制定相应的应对策略。
干系人档案模板主要包括三部分内容：基本信息、核心关注点和备注。
(1)干系人基本信息：主要包括名称、类别（与干系人列表的类别相同）、相关度、影响度（这两个同样只给开发团队看，不直接提供给客户代表）、职责（该干系人的工作职责要点，以便更好地理解他的关注点）、代表（如果有多名，从中选择一个）、联系方式（以便找到他）。
(2)核心关注点：逐条写出该关键干系人的关注点（正需求）、阻力点（负需求），还可以考虑写出相应的功能需求；另外，对其编号以便跟踪，判断重要度（可以使用“高、中、低”或“关键、重要、有用、一般”进行评估）以便管理。
(3)备注：记录一些其他便于理解干系人的相关信息，诸如专业背景、职业发展过程等。
运营副总（高层）
业务子系统划分任务指引
业务子系统划分这一任务主要包括以下三个步骤。
(1)划分业务子系统：根据系统特点，选择合适的划分策略进行分解。
(2)标识接口、确定关系：正所谓“哪里有分解，哪里就有接口”，在分解完成后，必须明确各子系统之间的服务接口。
(3)呈现业务子系统划分：根据实际情况选择合适的图表来呈现划分的结果，以便读者建立清晰、直观的理解。
划分业务子系统不是目的，而是一种手段，一种控制复杂度的手段。如果系统涉及的业务简单、用户群单一，那么就没必要划分。
业务子系统描述及说明
业务接口分析任务指引
在“业务接口分析”模板中，可以分为三部分：接口概述及用途、接口交互过程与数据包说明、接口设计约束
(1)接口概述：包括接口名称、提供该接口的子系统，以及使用它的各个子系统（包括使用的子系统名称、使用该接口的业务目的、什么时候使用、大致频率如何）。
(2)接口交互过程与数据包说明：如果交互过程比较复杂，可以考虑使用序列图来呈现，而数据包则可以使用数据词典来细化。
(3)接口设计约束：最典型的有协议要求（指定使用的相关协议）、性能要求（诸如响应时间等）、环境要求（网络、部署环境、用户使用环境等方面的信息）。
业务接口分析示例
业务流程识别任务指引
业务流程分析与优化任务指引
业务流程分析，最重要的是厘清业务流程八要素，包括五个基本要素（分工、活动、协作、产物关系、分支），三个管理要素（审核、规则、异常）。
业务流程八要素
业务流程分析这一关键任务，可以分成四个步骤执行。
(1)选择流程图描述方式：根据读者、流程类型选择合适的流程图来描述流程分析的结果。
(2)勾勒流程主体：厘清业务流程中的分工、活动、协作、分支、产物关系五要素，搭出流程的主体框架。
(3)补充事中管控点：厘清业务流程中的异常、审批、规则。
(4)分析流程执行过程的监管需求：从管理者对流程的进度、异常等方面的管控，识别、补充一些辅助的相关需求。
我们在做业务流程分析，而不是画活动图、数据流图，这些图只是分析的一种结果。
勾勒出流程主体之后，也就厘清了业务过程；接下来可以花时间通过沟通、讨论，对流程事中控制的管理要素进行分析。这主要包括异常、审批、规则。在实战中，建议按照以下步骤来补充这些事中管控点。
(1)首先和业务专家、客户代表就“异常”进行交流，主要的思考方向是：“是否存在完全不能够按这个业务流程执行的情况？如果存在，那么应该怎么处理呢？”诸如“应急流程”、“绿色通道”等，都是典型的“异常”处理流程，建议用文字或另一张流程图来描述它们。
(2)其次再把重心放在“审批”上，可以询问“现在有哪些审批点？还有哪些环节存在执行风险？需要增加什么样的审批？由谁来审批合适呢？”等问题来收集相关信息。
(3)最后再沿着流程，思考一下是否需要设置一些规则。从规则类型角度上，主要有两类，包括“决定是否能够执行、如何执行”的行为规则，以及操作权限、数据构成等数据规则。具体在实战中，可以从以下几个角度逐一思考、梳理。
①协作间规则：也就是用于控制流程协作的规则，诸如“物资管理员应在每个月5日前向采购部门汇总本月物资采购申请单”。
②业务活动执行规则：也就是在执行各个业务步骤时需要遵循的规则，诸如“在体检科室，只对盖章的体检单进行体检”。
③数据规则：针对表单、文档、生成产物的格式、内容进行限制的规则，诸如“所有金额取小数点后两位”。
“业务流程分析与优化”任务的输出结果示例
业务场景识别任务指引
用例、用户故事的精髓在于“用户视角”，在于“业务场景/使用场景”。它要求你不再关注于系统提供什么功能，而是用户在什么场景下需要系统提供支持。
用例图示例
管理者与执行者的不同视角
“业务场景识别”任务输出结果示例
当我们识别出系统要支持的业务场景之后，将以“场景—问题/挑战—方案”的逻辑来分析每个业务场景，从而导出所需的功能。这种思路将取代传统需求分析方法中使用的“输入、输出、处理”模式。
业务场景分析任务指引
对一个场景的分析，首先需要“概述业务场景”，以便大家对这个场景建立总体的认识。具体来说，
有三个思考点：
(1)该业务场景中，用户要实现什么样的业务目的？
(2)执行该场景有什么前提条件？结束前需保证何状态？
(3)除场景执行者之外，还有谁关心它？关心什么？
细化业务场景的业务步骤时，可以通过访谈用户代表、观察他们工作，或者直接收集他们的操作规程作为输入。在执行的过程中，可以思考三个问题：最典型的、用户预期内的业务步骤是怎么样的（基本事件流）；针对各个步骤，有哪些潜在的变化情况（扩展事件流）；针对各个步骤，有无异常情况，异常如何处理（异常事件流，通常是错误处理部分）。
质量要求和约束是有局部性的，在分析一个业务场景时，还应该考虑到环境、业务特点给系统实现带来的要求和影响。通常可以从以下几个方面着手分析。
(1)性能相关：主要包括执行该业务场景的人数、典型的业务量、峰值情况的业务量、密度（特别是一天内业务发生的频率不一时需要说明）。
(2)易用性相关：主要就是用户的成长经历和相关系统使用的经验，它对于系统易用性设计有指向性作用。
(3)部署环境相关：说明用户所在的网络、软硬件等相关环境。
需求分析需要做初步交互设计，起到澄清需求的作用，作为后续专业交互设计师(UI/UE)完成最终设计时的建议或约束。而初步交互设计中主要包括以下几个方面的内容。
(1)交互过程：也可以理解为界面流转图，用来表达你希望系统如何来实现该场景的所有业务步骤。
(2)静态快照：即每个页面上的具体内容，可以使用纸上原型呈现。
(3)设计说明：针对每个页面内容、界面流转做一些描述，核心在于说明自己为什么这样考虑，以及它是一种建议还是一种约束。
在这个“业务场景分析”模板中包括场景概述、场景分析、例外分析三部分；对于业务系统而言，场景就是操作层用户要执行的任务，因此在模板中用“任务”来代替了“场景”一词，以便用户更易于理解。
(1)场景概述：说明该场景/任务的名称（任务名称）、该场景/任务的执行目的（任务简述）、执行该场景/任务的前提条件（任务前提），以及该任务出现的频率（任务频率）。
(2)场景分析：以“场景/任务、问题/挑战、方案/所需功能”的形式整理分析结果。其中，“子任务”一栏写出该场景最预期的步骤及每个步骤的问题；“任务变体”则写出一些扩展事件流及相应的问题；最后在“所需功能描述”部分写出这些问题、挑战所需要的功能，如表9-11所示。
(3)关键例外：在该场景中一些特殊的、需要开发特点功能来支持的场景例外，这个部分并不是必填的。需要注意的是，它们并不是一种正常执行过程中的分支（或称为变体），而是一种例外情况，如酒店前台要接待一个旅游团就是“办理入住”这个任务的关键例外。
“业务场景分析”任务输出示例
管控点识别与分析任务指引
在执行该任务时，应该首先在子系统层面寻找相关的决策层（也就是高管）、管理层用户（也就是中、基层管理者）；然后在流程层级寻找相关的管理层用户；最后应该在整个系统层级寻找相关的决策层用户。
标识出所有相关的管理者之后，接下来可以通过访谈、侧面了解、职位职责及考核指标分析等方法来标识其希望通过系统来实现的管控点。管控点表示想通过数据分析实现的管理意图）。
“管控点识别与分析”任务输出结果示例
业务设置合理性分析
业务报表分析任务指引
业务报表分析的重点在于厘清报表的使用场景、报表的内容，以及输出的相关要求。
业务报表分析首先要清晰地定义出它的使用场景。在这一步中，核心是厘清三个问题：谁使用、为什么用、使用频率如何。
报表的本质不是“事件流”，而是“内容”，即生成报表之前要输入什么条件，从哪里得到所需数据源，生成哪些数据项及其格式、计算方法。
(1)生成报表所需的输入条件：可以使用界面呈现，也可以说明需要哪些查询条件。
(2)数据来源：直接列出该报表应该从哪些数据表中获得基础数据，如果涉及大量的数据表，也可以考虑画一张领域类图片段，把涉及的数据表、数据表之间的关系都呈现出来。另外，还应该说明统计口径，也就是对哪些数据进行统计。
(3)报表中的数据项、格式、计算方法：逐一列举报表中各个数据项，以及每个数据项的格式、计算方法。
业务报表描述示例
本任务的核心目标是：分析系统投入使用之后，运行维护阶段所需要提供的辅助功能，主要包括配置、运维、升级迁移及其他三方面。
维护需求分析任务指引
要执行好“维护需求分析”这一任务，关键在于抛开功能性思考，转而识别有哪些“维护场景”，以及该维护场景需要提供什么支持。
对于信息系统而言，第一种最典型的维护场景就是“各种配置”，以应对变化带来的影响。既然配置是应对变化，那么标识配置性维护场景就应该从变化入手，系统会遇到什么变化呢？从里到外主要有以下几方面。
(1)用户群变化：也就是使用这个系统的用户发生改变，他们的职位发生改变，他们的权限发生改变。因此，要想维护用户、维护角色、维护权限，也就相应地需要一些配置功能。对于权限而言，核心包括功能权限、数据范围权限、分配权限的权限。
(2)流程变化：企业的流程总会根据自身在发展过程中关注点的改变而不断进行调整，以满足阶段性管理目标。因此，如何有效应对流程变化对系统带来的影响，是需要提前考虑的。
(3)数据变化：随着企业业务的不断发展、深化，会需要在系统中引入更多的数据项、更多的数据细节。因此，如何应对未来数据项的增加、数据构成的调整与变化，也是需要提前考虑的。
(4)法规变化：企业在经营过程中，有时会涉及法律法规的要求，而法律法规在一定的时间周期内可能会更新或出台不同的实施条例。因此，应该考虑到当这些法规发生变化时，如何有效地应对。
在系统运行过程中，运维团队有责任保证系统安全、可靠、稳定地运行，因此需要一些系统工具来支持这些工作。这方面可以从“正常时”、“故障时”两个角度展开分析。
对于系统正常运行时，主要涉及的运维场景有两个方面：一是对运行状态的监控，二是数据备份。
系统在运行时，必然会出现各种各样的故障，因此需要故障定位、排错、故障恢复及应急措施的支持。
除了配置、运行时维护之外，典型的其他维护场景包括运行前的初始化，系统升级、迁移时所需的支持。
(1)系统初始化：在系统第一次安装、部署时需要提供什么样的工具支持，如安装工具、初始化配置工具、测试工具等。
(2)系统升级：系统在升级时需要提供什么样的支持，如远程升级、自动化升级、版本检查等。
(3)系统迁移：每次升级时，是否需要对原有系统进行数据迁移，是否需要支持双系统并行运行等支持。
维护需求描述模板
在信息系统需求分析中，数据主线的重点在于范围与关系，也就是哪些数据要纳入系统，它们之间的关系是什么，而领域建模正是解决这两个问题的关键。
领域建模任务指引
领域建模的结果需要选择一个模型来表示，可选的模型只有两个：E/R图和类图。由于E/R图只能描述关联关系，而类图能够呈现出更多关系，因此强烈建议使用类图。
在类图中，“类”是最基本的元素，它表示一个具体的业务数据。它用一个长方形表示，分为类名、属性（字段）、方法三栏。
类元素图示法
领域类图示例
领域类图片段建模示例
业务数据分析任务指引
数据应用分析，就是厘清哪些流程、场景在使用这些数据，使用这些数据的哪些部分，甚至厘清CRUD的关系；通常我们只需要对核心的、重要的业务数据执行这一步骤。
第一件事，在于分析哪些流程会使用这些数据。如果需要的话，还可以使用更加复杂的CRUD矩阵来细化，说明这些流程会Create（创建）、Retrieve（查询）、Update（更新）、Delete（删除）这些数据。
数据构成分析，首先要厘清这个业务数据包括哪些字段，然后针对各个字段厘清以下几方面的内容。
(1)数据类型：诸如字符串型、整型、布尔型等。
(2)数据规格：主要包括长度、精度信息，也可以直接使用数据表设计中的规格描述方式，诸如Varchar(100)。
(3)约束/取值范围：也就是该字段可以接受的值，对于复杂的取值范围还可以考虑使用传统的“数据字典法”描述。
(4)其他：如“是否非空、是否为键值、是否自动编号”等细节，如果该字段的值是计算出来的，那么还应该提供计算公式或计算方法。
数据的结构特点、使用特点等细节，将影响程序实现，对于核心的、重要的数据可以考虑对其做相应的分析，下面是一些供参考的思考线索。
1、结构特点
(1)主要字段与次要字段：也就是用户主要会看哪些字段，它将决定在列表中显示哪些字段。(2)稳定字段与不稳定字段：针对新业务带来的数据通常是不稳定字段，在表结构设计时需要考虑未来的扩展。
2、使用特点
(1)即时数据与历史数据：多久才算历史数据？这将影响历史数据的迁移，以提高实时查询的速度。
(2)关键字段与辅助字段：谁会被用来作为关键字？我们可以使用索引等手段来加快速度。
在“业务数据描述”模板中，主要分成三个部分：
(1)数据构成分析；
(2)数据应用特点：数据与流程之间的关系，以及数据窗口分析；
(3)数据使用特点，也就是其他说明部分。
这部分主要是描述数据构成，包括说明数据的字段名称、类型/规格、约束/取值范围等。下面一部分则用来说明哪些流程会使用到这些数据（数据与流程之间的关系）、分别使用到哪些部分（数据窗口分析）。而最后的“其他说明”部分则用来描述数据的结构特点、使用特点等。
“业务数据描述”片段示例
标识关键质量需求任务指引
质量场景分析任务指引
质量场景分析示例
业务规则分析任务指引
约束实际属于非功能需求，非功能需求包括质量和约束两类，质量是对我们的要求，约束是对我们的限制。约束又分成两类，一类是项目约束，一类是设计约束。
约束分析任务指引
项目约束，主要可以从进度、资源、预算三个角度来进行整理。
(1)进度要求：建议不仅仅列出最晚交付时间值，还应该理解这个最后期限背后的理由；诸如是为了新业务上线？新法规正式实施？参加新品展示会？以便更好地指导分阶段交付，以及未能完全满足时的预案。
(2)资源支持：明确接口人、开发/测试环境支持等；有一个小技巧，可以争取用户为每个业务主题设置相应的业务接口人，以获得更大支持。
(3)预算要求：在需求分析中一般不涉及，通常直接参考合同约定。
实现约束，主要可以从技术选型、部署环境、开发环境角度来进行整理。
(1)技术选型：客户有时会对开发提出具体的技术选型要求。通常原因有以下几种：一是相关政策、法规规定，诸如国产化平台要求；二是内部规范要求；三是接口人的技术偏好。前两者一般是不能改变的，第三种则有协商可能。
(2)部署环境：对实现产生约束的另一个方面将是部署环境的影响，主要包括遗留系统，用户采购的软硬件平台（服务器、终端、网络等），用户所处的国家、文化区域、社会环境（这将涉及用户的相关使用偏好、语言等相关内容），甚至生命周期也会有影响（如果是长生命周期对技术的先进性要求更高）。
(3)开发环境：实现约束还可能受到开发人员的技术能力、开发资源的影响而改变，也就是“开发人员能不能干、有没有资源干”。当然，这是需求分析工作中通常不必明确考虑的。
