既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上Go语言开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
OA中有一个很重要的功能,那就是对协同的支持。近几年来,企业/组织开始关注流程的效率。将串行的流程转变成并行的流程就是一种很重要的策略,但并行执行的流程就涉及并行部门、岗位之间的沟通和协作问题,*这些协作场景就是此类系统的需求线索*。
例如,可能会需要文件交换、信息共享等,先将这些场景归纳出来,再针对每个场景细化其中的行为需求,就能很好地完成此类系统的需求收集与整理工作。
注:此0A(办公自动化系统)非大家日常谈到的OA,它只是其中一个子集。平常开发的OA系统会涉及联机事务处理系统、管理信息系统的范畴。
前面,针对不同的信息系统分析了具体的需求线索,但这些都是主线索。在信息系统的需求工作中,还需要注意其他的一些线索,它们概括**为人、事(过程)、物(数据)、接口。**其中事、物是主线索,人和接口是辅助线索。在联机事务处理和办公自动化系统中,事是主线索,而管理信息系统、决策支持系统中物是主线索,在专家系统中也更偏重于物的线索。
二、嵌入式系统的需求视图
嵌入式系统可分为面向直接用户、面向特定设备和面向综合应用的三类系统。
- 面向直接用户的嵌入式系统
在梳理需求的时候应该采用层次结构来梳理。此类系统的需求主线索是具体的使用场景,而为了更好地保持其完整性,建议根据其逻辑性归纳成不同的功能域、功能子域。
手机系统分析示例
手机接打电话行为分析:
**行为一:**用户在接打电话的时候,经常会遇到需要记录一些电话号码、地址之类信息的情况,相信对于“你等一下,我找下纸和笔”之类的回答并不陌生,但这里就蕴藏着潜在的功能点。细致的需求人员就会设计这样一个功能,当接听电话时能够调出“便笺”,同时打开免提,这样用户就无须找纸和笔了。
**行为二:**用户在接到询问某人电话号码的电话时,用户可能就需要能够在通话状态中调出“通讯录”的功能。
*对于面向用户的嵌入式系统,行为分析是要点。*
- 面向特定设备的嵌入式系统
需求主要包括对外接口和内部功能两部分。
**对外接口:**首先找到相关联的外部系统,然后明确外部系统与其的功能交互点。因此在需求描述时可以采用上下文关系图确定其与外部系统的协作。在标识了这些接口之后,接着在需求的后续阶段逐步分析、捕获这些接口的使用时机、功能要求和内容等。
**内部功能:**可以采用事件作为线索。事件分为外部事件(通常是外部接口触发的)、状态事件、时间事件和内部事件(内部设备触发的)。识别事件最基本的方法是寻找触发点。如果内部功能比较复杂,就需要对这些事件进行归类,归纳成不同的功能域、功能子域。
*面向特定设备的嵌入式系统,外部接口和事件分析是要点。*
三、软件产品的需求视图
与软件产品相对应的是软件项目,项目通常是针对一个企业/组织的,软件产品则是为多个企业/组织设计的,生命周期会更长。
从需求的角度,根据与问题域的相关度将软件产品划分成3类。而其中游戏类软件通常是不需要需求分析人员的,需要的是策划、编剧。
- 信息系统类软件产品
诸如进销存、ERP、OA、财务电算化等软件产品都属于此类产品,是与现实问题域息息相关的,成败关键在于对问题的理解。与信息系统项目在需求梳理时采用的方法是类似,也有自身固有的特点。一般需要做目标市场分析和商业模式分析等。
目标市场分析
商业模式分析
商业模式举例
产品体系设计
产品体系设计与需求工作有直接相关的核心要点是根据不同的商业模式来封装变化点。将不同商业模式之间的共同点做一些抽象,然后将不同点封装到可插接的模块中。
①共同点抽象
例如对于上面提到的直销模式,不管是电话销售还是邮件销售,它们的共同点就在于销售漏斗(潜在客户+跟踪客户+意向客户+签约客户),不同点在于具体的跟踪手段。
②先找出通用性,再通过插接解决扩展性
假设在开发一个人力资源管理软件时,发现不同企业对请假的审批流程是不同的,那么该如何处理呢?通过分析发现,整个请假过程可以分解成如下图几个步骤。
填写请假条和记录请假两个阶段是通用的,而请假审批则是复杂的,那么就可以将其抽取出来封装在独立的模块中,并预留插接点(接口)。填写请假条模块提供输出请假条的接口,记录请假提供用来接收请假审批结果的接口,请假审批使用这两个接口。
- 工具软件类软件产品
工具软件通常利用电脑为人们解决日常工作、生活中可能遇到的问题。其灵感通常来自于两个方面:对现实世界中某种工具的仿真,例如计算器、便笺等;利用电脑的优势创造新的体验,例如QQ、电子词典、AutoCAD等。
***基于使用场景的困难点分析是工具软件的需求要点。***对于工具软件而言,人机交互部分是十分重要的,可以在需求描述时采用用户界面原型驱动的形式。
4.软件需求最佳实践笔记 | 软件需求与需求工程
一、什么是软件需求
可从三方面对软件需求进行定义:
业务知识:包括业务事件、业务实体和业务规则。
问题列表:用户在工作中遇到的困难与障碍,这也是软件开发时需要解决的问题。
其他因素:包括了一些设计约束和非功能方面需求。
- 需求的三个层次
包括业务需求、用户需求和功能需求。
反映到需求文档中,可用下图表示:业务需求一般在项目视图/范围文档中体现,用户需求通过用例文档以用户的视角呈现,软件需求需要写到软件需求规格说明书(SRS)中。
- 需求的三种类型
需求按类型划分可分为功能需求、非功能需求以及设计约束。
- 优秀需求的标准
优秀的需求要符合以下几个标准:
**①完整性:**验证需求规格说明书中罗列的主题域、业务事件、业务活动、业务步骤等是否完整;同时,需求是有层次的,高层管理人员、中层管理人员、操作人员,在验证需求完整性时需要采用分层评审。
**②不失真:**求在信息传递的过程中不失真,即正确和无歧义。
③有优先级:“事有轻重缓急”,想要更好地对项目进行管理,就需要有效地区分出优先级。
④**有技术早期介入:**解决方案既要具备可行性,又要具备可验证性。
而一旦需求不完整、失真,会使软件项目付出很大的成本代价,甚至失败风险。
上张图是说,如果在需求阶段只需花费1个单位时间就能改正的错误,拖到设计阶段来改正就需要5倍的时间,到了编码阶段将是10倍,测试阶段可能达到20~50倍,而到了运行与维护阶段或许会达到200倍之多。足见需求分析人员对一个软件项目的重要性。
二、软件需求工程
- 需求工程的范畴
软件需求工程包括需求开发和需求管理两个过程域。需求开发是收集、分析、整理、编写、验证需求的全过程,重点在于开发出高质量的需求规格说明。需求管理是对需求的实现、变化进行追踪的全过程,重点在于确保开发的软件满足这些需求。
- 需求开发工作要点
通过需求获取、需求分析、编写规约和需求验证4个具体活动多次循环的形式进行需求开发。
需求开发工作示意图
一般经过三次循环,可形成一份合格的需求产物。
需求开发的三次循环
需求获取也称为需求捕获,它们都是主动动词。而现实的需求实践中最大的问题恰好是比较被动的。存在捕获范围不足、缺乏计划性、缺乏科学性、捕获对象不明确、捕获手段不足等问题。
软件需求捕获中的常见问题
需求分析是需求开发中的核心任务,但在实践中却经常被“忽略”,也就是直接将需求捕获得到的信息整理到需求规格说明书中。
①需求分析首先是业务分析,是对问题域进行研究,要从从业务线索入手,而非系统结构。
②需求分析是一种分解活动,将待开发的系统按职责划分成不同的主题域(可以将其理解成子系统,在划分时是按业务视角进行),然后分解成组成该主题域的所有业务流程,再分解到业务活动(用例)、业务步骤。
③需求分析是一种提炼与整合活动:将用户的原始需求合并到业务活动中去,将各个业务流程合并成全局业务流程图,将每个业务事件相关的领域类图片段合并成全局领域类图,将各个业务事件的用例图片断合并成全局的用例模型等。
④需求分析是一种规格化活动:要找到冲突、矛盾,并且通过访谈等手段解决这个问题。
注意区分内容与形式,需求分析是任务,建模是手段。建模的过程就是分析的过程,核心思想是用“图形”代替“文本”,以更加可视化的方法表述信息。建模产生的结果并不一定非得是规范性很高的模型,重在分析、交流,重在解决问题。
需求分析和需求捕获交替进行,获取了部分信息之后,就可以对其进行分析,并将分析的结果填写到已经规划好章节的需求规格说明书中。通过分析会发现更多的不明确项,更多待捕获的信息,这时就可以生成第二次需求调研的计划、问题、素材。
注:按照现代软件工程思想,通常会采用迭代、增量的开发过程,需求分析工作贯穿整个软件生命周期。
编写规约是将需求分析结果文档化的过程。软件需求规格说明书总结了四字要诀:共享、更新,而每个要诀都包括两层含义。
**需求验证,**对于需求验证工作,大多数组织都不够重视,有时只是找一个客户代表签字确认,甚至直到交付系统时通过测试系统来验证。这样当系统交付时,可能会出现大量需求变更。
需求验证的关键手段是评审,且要分层次、分内容进行验证,以期在早期阶段尽可能多地暴露出问题。
- 需求管理工作要点
需求管理工作包括基线管理、变更管理和需求跟踪三个活动。而要想真正使需求管理活动获得实效,可以将整个管理改进分成4步:
①统一明确的需求项划分标准;
②引入基线管理;
③引入变更管理;
④引入需求跟踪。
- 需求分析人员的技能组成
需求分析人员是需求收集、分析、记录和验证等职责的主要承担者,是用户群体与软件开发团队间进行需求沟通的主要渠道。他们需要完成的活动包括:定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求等。
因此必须掌握的技能包括倾听、交谈和提问的技巧,分析、协调、观察、写作、组织、建模、人际交往和创造能力。而这些能力可以概括为业务知识、技术知识和沟通能力三个方面。
- SERU软件需求过程框架全景图
对于遗留系统项目,SERU模型也适用。在S层,考虑项目是一个新主题域,还是对某些主题域产生影响;在E层,考虑项目新添或修改了哪些业务事件。
5.软件需求最佳实践笔记 | 需求定义
一、需求定义的任务
需求定义,就是确定项目的宏观需求。也就是定义项目的业务需求,明确项目的目标和范围。
- 需求定义在项目立项时完成
清晰的项目目标和范围定义,能够引导需求工作顺利进行。
而事实往往是有不少项目在立项时并没有很好地完成需求定义工作。造成这一现象的主要的原因是:在项目立项阶段开发团队(包括需求分析人员)还没有开始工作,可能招标还没有完成,项目团队还没有成立。不管怎样,需求分析员应认真审视需求定义阶段的产物,如果没有达到要求必须做一些“补课”工作。
- 需求定义的理念与策略
在现实工作中,似乎每个项目都经历了立项环节,也会产生一个定义项目目标和范围的文档。但经常比较空洞。诸如“全面提高企业的信息化应用水平”、“打造一流的信息化管理平台”等难以落实的虚目标。
要对混沌不清的项目目标进行破解,通常有两种方法。
①内部寻根
尝试在提出项目的企业/组织内部寻找真正的项目发起人,和这些项目发起人的深入沟通。
②外部溯源
外部因素所激发的项目,需求定义时要找到目标参照物,通过对目标参照物的分析与了解,就能够很好地做好需求定义工作。有可能领导在外面考察,他山之石给他留下了较好印象,即受到了外部刺激。
**需求定义工作的着手点可概括问题与机会。**因为对于信息系统而言,要么是解决问题的,要么是创造机会的(例如,互联网发展催生了网上银行、外卖、打车等新的商业模式)。
基于以上分析,需求定义的策略可总结为四步:
**目标:**通过内部寻根或外部溯源的方法,先将项目要解决的问题或机会罗列出来,如“废品率太高”。
**问题:**对目标层面的问题进行分析,找到导致该问题产生的根源问题,然后将其全部列出来,例如“订单不准确”、“运输损耗”等。
**可选方案:**针对每个问题罗列出可能解决的方案,如针对“订单不准确”问题,可选方案包括“用户直接通过电子化手段下订单”、“对订单内容进行电子化校核”等。
**建议方案:**最后从各种可选的方案中挑出认为比较合理,对解决问题贡献度更高的方案。
二、问题分析的五步法
RUP给出的问题分析5步法,为需求分析人员提供一个很好的理论指导框架。
- 在问题定义上达成共识
问题分析就是理解真实世界中的问题和用户需求,并提出解决方案的过程。第一步是把问题拿出来,得到所有人的共识。虽然名为问题定义,实际上也可以定义为机会点。
下面是一个描述机会点的例子:
对问题进行了正确的定义,意味着成功解决了一半。而在问题定义时应该善于使用转换和本源两个技巧。
本源—发现问题的真正所在,建议读一下《你的灯亮着吗?》这本书。
- 分析问题背后的问题
通常使用鱼骨图分析来找到原因,然后再通过收集相应的统计数据,再以直方图表示出来,并对其进行相关的分析。
鱼骨图示例
帕累托图示例
- 确定相关人员和用户
一般按Stakeholder和用户两类角色进行分析。
- 定义解决方案的界限
首先需要确定范围和边界,范围是指系统涉及哪些内容(事、物),而边界则是系统与人的职责边界。
产品销售公司的销售过程示意图
先看1号边界,如果系统只实现“记录订单”的功能,意味着用户必须手动完成接订单和信用核查工作,系统只起到了一个电子化功能。这显然不是投入20万~30万的系统所应该采用的边界。
接着看2号边界,不仅实现了记录订单功能,还可根据该顾客的历史交易记录、提供的信用卡进行信用检查,这里实现的功能显然是与用户的投入相匹配的。
再看3号边界,也就是实现订单接收的自动化,可能的方法有呼叫中心、Web网站等。这些功能虽然很合理,但它是超出系统预算的,不应该将其纳入系统边界内。
综上分析,2号边界是一个很不错的选择。超出预算的边界,要进行边界谈判。当然也有创新边界,对于上例而言,通过考虑计算顾客对各种商品的消耗速度,直接在客户缺货前主动营销。
- 确定加在解决方案上的约束
可从技术开发和项目实施两个方面去考虑:
三、需求定义的产物和要素
- 需求定义的产物
一般包括项目综述(POS)和愿景(Vision)。
POS的主要内容:
Vision的主要内容:
- 需求定义的要素
**①目标:**写作过程中,应该注意从目标、业务优势、度量指标、合理性、可行性和可达成性方面进行编写。
一个好的目标描述应该满足SMART原则。具体(Specific)的,能够指导具体的工作,可度量(Measurable)的,能进行成本/效益分析,可达(Attainable)的,否则是没有意义的目标,和其他目标具有相性关(Relevant),有明确的截止期限(Time-based)。
项目目标编写示例
**②范围:**项目的范围对于需求分析人员的意义是相当重要的,可以说需求分析人员在进行需求定义工作时,核心的工作就是确定范围。
很多书籍推荐通过上下文关系图描述范围,但在实际的应用过程中仍然存在很多疑问与误区。SERU推荐的方法是“两图一纲”。
③相关人员和用户:在进行需求定义时,需要对和软件项目相关的人员进行研究。系统的使用者(用户)也是相关人员的一种,不过在整理这些信息时,思考的角度是不同的。
对于用户而言,需要收集和分析的信息包括:与主题相关的经验、技术上的经验、智力能力、对工作的态度、对技术的态度、受教育程度、语言技能、年龄、性别等信息。换句话说,是对其能力进行建模。
项目相关人员分析示例
四、需求定义范围
定义需求范围通常会用一段话,或者一个程序分解结构(系统+子系统+模块+子模块)来表示。自顶向下的程序分解结构使用户无法介入到需求范围的评价中,导致需求范围执行时存在困难。
SERU建议采用业务导向的层次结构来,通过三个相互独立的步骤逐渐演化出需求的范围定义,采用两图一纲(构件图、上下文关系图和需求大纲)来描述,为软件需求规格说明书提供最初的目录结构。
以“体检医院管理系统”为例进行分析说明。
体检医院管理系统背景资料
- 划分主题域(子系统)
①按照业务的职责区块来划分的子系统称为主题域
传统子系统划分示例
这种划分在进行需求捕获和分析时会发现各个子系统和模块与客户部门是交错在一起的,每个模块都需要对不同的部门进行调研。并没有很好地把业务结构体现出来。
原因在于传统的划分方法经常采用“业务名词+管理”的形式命名,其中业务名词实际上是业务实体,也就是“物”的线索;对于大多数业务系统而言都不是最佳的分解方式,因为这些业务实体会牵涉到大量的业务流程。
更合适的分解方式是根据业务流程来分解,也就是以“事”为线索。
②为什么使用构件图
每个系统/主题域都不是孤立存在的,它们之间总是会有这样那样的协作,需要提前将这些协作标识出来,这就是主题域之间的服务接口。各个主题域之间的服务接口是需求变更的防火墙。
某连锁酒店构件图示例
在构件图中,只有两种元素,即构件、接口,构件对接口而言有两种关系,一种是实现关系(表示这个接口是某个构件提供的),另一种是使用关系。
在考虑和标识服务接口时,最有参考价值的思想是“职责驱动设计”,通过一个实际的例子来阐释。
所谓的职责驱动设计,简单地说就是职责必须匹配。什么是职责呢?一个类或构件的职责包括两个方面:一个是知道的事,对于一个类来说就是它的属性;一个是能做的事,对于一个类来说就是它的方法。
**解决的方法之一是将行为接口改变成数据接口。**抽象出一个“逻辑资源池”的概念,从而避免营账系统直接预留物理资源,而只是预留逻辑资源,让资源管理系统来完成物理资源与逻辑资源的对应关系。于营账系统而言,并不需要知道每个物理的资源情况,只要知道某个片区是否有足够的资源数即可。
③体检医院管理信息系统案例分析
下面是主题域划分的思考过程:
**销售区块:**主要完成对客户的销售、服务跟踪,再考虑到其部门的命名,把针对这个职责区块的主题域称为“客服管理子系统”。
**生产区块:**负责向体检者提供全程的体检业务。因此这个职责区块的主题域称为“体检业务管理子系统”。
**后勤区块:**为企业提供支撑的,它涉及了两个相对独立的部分:一个是财务,另一个是物资。考虑到它们之间的独立性,通常在划分主题域时会建议将其分成两个,即“财务管理子系统”和“物资管理子系统”。
目标决定范围。在最终确定主题域之前,还需要结合目标来考虑这些主题域。财务管理子系统对系统既定目标没有直接贡献,根据目标决定范围的原则,就应该将它移出。
主题域划分完毕后,开始绘制构件图。
绘制完成的构件图示例
- 确定主题域范围
以“体检业务子系统”为例来说明上下文关系图的绘制方法。
首先将体检业务子系统当作一个黑盒子,用一个矩形表示;接着思考该主题域有哪些外部的Customer,很显然最重要的是体检者。所以先分析他会发起对系统有影响的什么行为(事件)。显然,申请体检就是最重要的一个,然后考虑为了处理体检者的申请,主题域的内部Worker要做些什么,这个思考过程将得到如下图所示的片断。
体检者除了申请体检之外,还有什么独立的行为呢?体检者可能会因为有事而中途修改体检项。这是一个独立的、不是必然发生的事情。首先应该由体检者提出申请,然后由收费人员做相应的处理即可,因此将这两个信息添加到上下文关系图上,这时就会得到如下图所示的结果。
接下来再看看是否还有其他Customer。可以从构件图中获得线索,发现客服管理子系统会需要查询团队体检的进程,财务部门会输入团队缴费信息。将其添加进来,就可以得到如图所示的结果。
外部的Customer都分析完之后,上下文关系图的主体也就完成了。接下来再思考内部的Worker是否有主动的行为。例如:维护人员要管理体检项(包括名称、费用等)信息、系统通知体检者取报告。将这些内容添加到图中,将得到了一个完整的上下文关系图,如下图所示。
- 标识业务事件与报表
上下文关系图绘制出来之后,整个主题域的范围也就框定出来了,但还不足以为后续的需求捕获、分析与建模活动提供良好的基础。还需要做进一步的工作,将主题域的内容以业务事件列表和报表列表表示出来。
注:对于联机事务处理系统而言,业务事件(流程)是核心线索,对于管理信息系统而言*,*Report(包括各种查询、分析、统计)是核心线索。而通常的业务系统都包含了这两种成分,因此应该在需求定义阶段将这两个线索明确地标识出来。
业务事件是梳理业务系统需求的一个很重要的线索,因为一个企业或组织存在的核心价值在于接受外部用户的请求,通过响应请求让用户满意的同时也创造了相应的价值。
业务事件是业务流程的触发点,标识出业务事件能够帮助我们识别出业务流程;
业务流程是为了响应业务事件而触发的一系列业务活动,它通常是由不同部门、不同岗位协作完成的。
业务活动则从属于一个特定的业务流程,它是一个人的活动,一个业务流程应该是由一个或多个业务活动组成;
业务步骤是完成某个业务活动所需要的具体步骤。
业务事件可分为外部事件(来自系统外部的事件,也就是系统参与者发起的)和内部事件(也就是系统内部触发的)两类,而每种类型的业务事件又可以分成两种。
**Customer发起:**由主题域外的客户发起的,在绘制上下文关系图时建议的主线索,如体检者申请体检。
**Worker发起:**由主题域内的客户发起的,在绘制上下文关系图时也涉及了这种事件,例如维护人员管理体检项。
**时间事件:**由于到达某一时刻所发生的事件,如到信用卡结算日时向客户发送账单,是一种时间事件。
**状态事件:**由于到达某一状态时所发生的事件,如当体检结果出来并出具报告之后,通知体检者领取报告。
上一小节,绘制出了针对体检业务子系统的上下文关系图,在绘制的过程中,寻找的就是业务事件,可以得出该主题域所涉及的业务事件:
①体检者申请体检
②体检者中途改单
③财务部门体检团队缴费情况
④客服中心查询体检情况
⑤维护人员管理体检项
⑥系统通知体检者取报告
业务事件标识出来之后,可在此基础上分析潜在的报表类型。在需求定义阶段主要是标识出报表的类型,说明为什么要这些报表,它们的使用场景是什么样的。根据前面的分类,可以大致分析出一些潜在的报表类型。
- 生成需求大纲
通过这三步把需求的范围界定之后,就可以把它填到POS或Vision文档中的“项目范围”小节中,先从主题域划分,然后每个主题域一个小节,分别阐述业务事件和列表需求。
也可以利用这些范围信息把软件需求规格说明书(SRS)的框架搭建出来,以便在后续的环节中不断演化、填充。
链接:https://pan.baidu.com/s/1iSCj7dje10DBQTaPuNvpHw
提取码:tavx
6.软件需求最佳实践笔记 | 需求捕获
一、需求捕获的策略
- 需求捕获应该是主动的
需求捕获或称为需求获取都是主动动词,强调需求分析人员在整个过程中应充分发挥主动性。
两种需求捕获模式的对比
- 需求捕获应该是聚焦的
需求捕获案例
这个案例中,小张提问的方法就将导致整个捕获过程是发散的,而老李的问题就能够使整个问题很聚焦,这样产生镀金需求、非重要需求的可能性就会大大下降。
- 破解需求的冰山模型
用户的需求是一个冰山,有很大一部分信息是埋藏在海平面之下的,这就会对需求捕获工作带来很大的困扰。这个冰山可以分为三层。
解需求的冰山模型
**意识到的需求:**通常是一些困扰用户的问题、用户自己能够设想得到的功能。如果只知道捕获这一层信息,就不算是合格的需求分析人员,因为这将导致大量的需求将以变更的形式出现。
**无意识的需求:**它是用户的实际工作场景,如果能够对这些场景做到“感同身受”的话,可以大大减少变更的数量,而且能够开发出更加合理的解决方案,具体的方法就是加强对业务知识的捕获。这是每一个合格的需求分析人员都应该做到的。
**未梦想的需求:**用户对技术解决方案不是最擅长的,因此他们无法构想出对其工作产生革新性变化的解决方案。这就需要通过需求分析人员在对问题域充分理解的基础上,选择合适的技术方案,才可能创造出用户未梦想到的功能。能够做到这一点就可称为优秀的需求分析人员。
这就是意识到的需求,用户能够清晰地表示出来。但小宁却没有进一步分析。
这是无意识需求搞的鬼!房产经纪人提出这个需求的原因是客户对房源的需求是多样化的,他可能需要某路段的两房或另一路段的三房,无法用一组查询条件将它们总结在一起。以前在本子上查找时,人的脑子是可以记录多组条件的。
去理解业务场景是合格需求分析人员的良好习惯。
这就是一个未梦想的需求,用户代表是不可能想到这样的解决方案的。只有理解了用户的实际场景,并有其他领域的经验、熟悉技术能力时,才会想到这些更优化的解决方案。
善于利用技术为用户创造全新体验是优秀需求人员的特质。
- 破解阻碍需求捕获的心理现象
需求捕获过程是与人打交道的过程,因此遇到一些阻碍需求捕获活动的心理现象在所难免。如果需求分析人员能够多思考这些心理现象后面的心理动机,就一定能够找到有效的手段来缓解它们所带来的影响。
阻碍需求捕获的五种常见心理现象
**言过其实心理:**通过比较用户代表的表述来识别言过其实,利用差异展现、瓶颈分析法来缓解影响。
**越俎代庖心理:**针对越俎代庖心理现象最有效的方法是识别正确的被访谈者。
**非正事心理:**离开办公室、对访谈进行计划是避免非正事现象的主要手段。
**抗拒心理:**化敌为友是缓解抗拒心态的主要方向,倾听对方抱怨是化敌为友的有效手段之一。
**推卸责任心理:**让被访谈者介绍工作场景,存在什么样的障碍,有什么困难等。
- 不要忽视对变更可能的捕获
需求变更一般发生在下面三个方面:
注:弹性的架构并不意味着修改是无须成本的。把影响架构设计的变更因素写在软件需求规格说明书中,才能够帮助架构师正确地做出决定。
- 需求协商
在需求捕获的过程中经常会遇到需要协商的地方,能否灵活应对这些场景,取决于需求捕获人员的沟通技能。下面从三个方面介绍需求协商的策略。
①揭开解决方案后面的问题
随着人们学识、经历的不断增长,其讲话时就会更偏向于说解决方案,而不会直接说问题。这种心态对于需求捕获会造成障碍。同样是口渴了,我们来看看不同人是怎么说的。
3岁小孩的生活经验、学识都相对比较少,所以经常会直接反映问题;而一位成人则经常会给出一个解决方案,可能会需要多次交流才可能解决问题;而许多领导则经常会给出更加迂回的解决方案,如果听者不是很有经验,或许根本无法满足他。
在需求捕获过程中,“不直接说问题,而是说解决方案”的现象并不少见,那么面对这样的问题,我们应该如何解决呢?其实方法很简单,就是多问为什么。
②共赢性谈判
需求协商也是一种谈判,显然不是你死我活的谈判,而是一种共赢性谈判。而共赢性谈判的技巧在于抛开立场,追求满足大家的利益诉求。而要完成这样的转变,在谈判过程中的核心技巧就在于问出对方的立场。
共赢性谈判的技巧在于抛开立场,追求满足大家的利益诉求。而要完成这样的转变,在谈判过程中的核心技巧就在于问出对方的立场。
- 转换技巧
在需求捕获阶段,特别是基于自有产品作定制开发的团队,应该尽可能将用户的需求转换成已实现的产品解决方案。但除了将未知问题转换成已知解问题之外,转换还有一些其他应用思路。
①相对重要到相对次要
在这个案例中,自动生成实时值班日志功能相对于小李而言是重要的,但相对于告警短信自动发送功能则是次要的。通过这样的转换,成功地判断了需求的优先级。
②关注点转换
事物都具有多面性,都各有优劣;而关注点转换的核心思想就是利用其多面性,引导对方向有利于自己的关注点进行思考,从而为自己赢得机会。
在这个案例中,用户最初的关注点在于速度、性能;而这位客服人员将用户的注意力带到–个更重要的角度,那就是安全性。通过这种关注点的转换,有效地赢得了改进的时间。
③隐喻
隐喻就是打比方,是用对方熟悉领域的事物来解释深奥问题的手段,它也是转换技巧中最精彩的一个。需求捕获人员通常是介于问题域和解决方案域之间,在与人沟通时,隐喻能够起到很好的润滑作用。
二、需求捕获的主要方法
可灵活采用以下六种方法的一种或多种。
- 用户访谈
①优缺点与使用时机
用户访谈的优点是直接有效、形式灵活、交流深入的宽带通信形式(有文字、有声音、有图像)。但它也有一些很明显的缺点:如占用时间长、信息存在片面性等。用户访谈是需求捕获过程中的主体技术,因此只要有可能,就应该尽可能多地进行用户访谈。
②用户访谈的类型
在需求捕获阶段最常见的被访谈者包括高层管理人员、中层管理人员、操作层、技术团队4类 。通常对高层管理人员的访谈结果是访谈中层管理人员时的指导,同样对中层管理人员的访谈结果是访谈操作层时的指导;而对技术团队的访谈则是突发的,是需求捕获人员无法确定技术是否能够实现、实现成本是否过高时进行的。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上Go语言开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
在与人沟通时,隐喻能够起到很好的润滑作用。
二、需求捕获的主要方法
可灵活采用以下六种方法的一种或多种。
- 用户访谈
①优缺点与使用时机
用户访谈的优点是直接有效、形式灵活、交流深入的宽带通信形式(有文字、有声音、有图像)。但它也有一些很明显的缺点:如占用时间长、信息存在片面性等。用户访谈是需求捕获过程中的主体技术,因此只要有可能,就应该尽可能多地进行用户访谈。
②用户访谈的类型
在需求捕获阶段最常见的被访谈者包括高层管理人员、中层管理人员、操作层、技术团队4类 。通常对高层管理人员的访谈结果是访谈中层管理人员时的指导,同样对中层管理人员的访谈结果是访谈操作层时的指导;而对技术团队的访谈则是突发的,是需求捕获人员无法确定技术是否能够实现、实现成本是否过高时进行的。
[外链图片转存中…(img-ZVEkdwMt-1715796578768)]
[外链图片转存中…(img-qR08pYZH-1715796578768)]
[外链图片转存中…(img-FhqMP09y-1715796578768)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上Go语言开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新