如果《用户故事地图》可以解决大部分PO和BA可以进行需求分析,“看树,看林”,《需求设计》实际写入BA和SA。
在我最近谈到阅读几本书之前,我基本上习惯于解决“看树而不看森林”的问题。
今天,与大家分享第二本书《需求设计》。
如果《用户故事地图》可以解决大部分PO和BA可以进行需求分析,“看树,看林”,《需求设计》实际写入BA和SA。
如果使用得当,我们可以使用用户故事地图来收集和组织需求,并使用需求设计中提到的上下文驱动设计来概念化和设计。
我以前一直与一些设计师联系,而不是软件。
你知道汽车或飞机是如何设计的吗?
一般来说,客户会给出需求。例如,我要求汽车能够在1吨内运输货物。满载时,车速可达80码,油气混合等,符合国家标准; …
然后整体设计师分析他的需求,即指标的分解。
例如,为了能够在1吨以内运输货物,可能存在对车身设计和动力设计的相应需求。
整个设计部门将按功能划分,将有车身结构设计部门,电力设计部门,电子设备设计部门。
客户的需求可能涉及多个设计部门,相同的多个要求可能会对同一设计部门的一个指标产生影响。
例如,结构设计部门发现,如果要装载1吨货物,则必须具有一定的强度支撑,这将增加汽车的重量。
然而,增加的体重会影响汽车的速度。
这很复杂,也不清楚。
曾几何时,各个设计部门也是独立的,只关注自己的指标,不管对其他设计的影响如何。
最后,当物理机现场测试联合调试时,会出现各种问题,造成很大的损失。
好吧,你可以想象一架飞机在进入风洞实验时发现了问题……
这次损失后会有多少个零?
我不清楚……
这都是因为“只看树,看不到森林”。
随着技术的发展和概念的更新,在工程设计过程中,总体领先将用于分析和设计要求,然后设计部门将进行设计。
而且由于计算机技术的发展,越来越多的测试和调试不是物理的,不是物理机的调试,而是大量的仿真和模拟手段。
确保在早期阶段消除大量问题,避免无法弥补的无数零损失。
《需求设计》提出的软件设计可以借鉴工程设计。
作者提出了一个六盒设计模型:
而今天我们想要解决的问题更接近第一层,即情境设计。
回顾上一篇文章,您如何询问汽车的需求?
用户请求需求的大部分时间都是上下文化的。
在这种情况下,我们如何处理它。
在那种情况下,我们有什么样的流程?
是的,我们有一些特殊情况。
对于如此众多的复杂信息,在分析需求时,您将不可避免地迷失方向。
我们需要避免一些常见问题,缺少要求和相互冲突的要求。
需求损失
需求的减少通常是由于我们在收集需求时自我假设的事实:
用户肯定会告诉我所有要求都非常清楚。
用户说的是一致的,没有矛盾。
我能够联系所有利益相关者并获取信息。
最后,我设计的解决方案将由客户审查,他们可以清楚地指出问题。
鹤鹤哒……
我相信用于新年的BA不会那么简单,因为这些假设所产生的坑和盆的数量尚不清楚。
当我在UAT时,用户说:“不,我们有这样一个场景……你像这样交付,我们无法签名。
你会非常委屈,因为你觉得客户在研究之前没有提到这样的需求。
并且整个团队可能会责怪你,责怪你没有“认真”收集并与客户确认。
这是收集和确认的问题吗?
在许多情况下,事实并非如此。
遗漏需求可能是因为您没有执行要求验证。
两天前,我在BABOK分享了需求验证。
实际上,需求验证也是提前测试要求的工作,以确保要求的完整性。
您如何验证要求?
需求设计
《需求设计》的作者提出了一种方法,即情境设计。
通过设计任务,用户组,数据表和任务间消息来减少需求验证。
任务
首先,您可以分析通过情况涉及的任务,最好将它们分解为原子任务。
对于BA,您可以将任务理解为活动。
但对于SA,任务可能或可能是比活动更精细的元素。
例如,在地面挖洞是BA眼中的一项任务。
SA将其分成领导者,命令团队开始挖洞并挖洞以结束这两项任务。
请BA来品尝两者之间的差异。
这就是BA和SA在思想上的不同之处。
用户组
对于用户组,我们需要定义它。
这个比较简单。当我们绘制泳道地图或用例图时,这将涉及用户组的识别。
实际上,我们可以在识别任务时识别相关的用户组。
哪些用户组合在一起,主要与任务相关。
通常,我们会将执行相同类型任务(甚至相同任务)的用户分配给用户组。
数据表
我不知道有多少BA会在设计过程中考虑数据表。
但SA或DBA肯定会考虑这个问题。
BA需要注意,您在此任务中使用的对象属性可用于其他任务。
是否有数据之间的转移等。
业务设计数据库不是您的责任,但您有责任清楚地指出数据的关系。
任务之间的消息
在BA中,任务之间的关系只不过是触发另一个任务的用户任务的变化。
对于SA,范围更广。
在我粗略阅读了Activitii的相关书籍之后,我发现这个新闻在工作流程方面无处不在。
但毫无例外,新闻是根据情况生成的。
也就是说,在什么样的情况下,谁会向谁发送信息,会发生什么。
话虽如此,我们可以知道基于情况的需求设计主要是验证任务的四个要素,用户组,数据表和任务之间的消息,以确保要求的完整性,减少遗漏。
如果我们在需求分析和设计的早期阶段这样做,我们可以识别出相当多的缺失部分。
如果有机会,可以尝试一下。
矛盾的需求
有两种情况可能存在冲突的要求。
在描述过程时,同一用户使用规则A.例如,当快门敲门时,必须在关闭水龙头后关闭门。
当他描述另一个过程时,可能需要几个月才能使用规则B.例如,当女朋友敲门时,首先打开门然后关掉水龙头。
如果您只是设计关闭水龙头然后打开门,或打开门,然后关闭水龙头,这是不合适的。
此时您需要做的是分析这两种情况并找出矛盾和解决方案选项。
不同的用户,在描述相同的过程时会有矛盾。
这可以理解,因为每个人的角色不同,事物的视角也不一样,很可能会出现矛盾的规则。
此时,您必须确定问题的原因并根据项目或产品目标指导它以达成协议。
好的,问题来了。
我们如何发现需求是矛盾的?
如果需求是一个列表,或者是一个很长的Backlog,很难找到。
如果您在情境设计中使用这四个元素,则很容易分析。
在识别出任务后,可以快速获取用户组与任务之间的消息分析,因为参与的用户组不同,任务之间的消息触发机制也不同。
事实上,这可以相应地识别替代解决方案
全球
当我们提到“我看到树木,没有森林”时,我不得不提到需求的整体问题。
在工程设计方面,有一个名为“总务部”的部门,其主要职责是协调各专业设计部门对要求的分析,设计,实施和测试。
他们接收客户的背景化需求,分析并设计,然后将需求分成单独的设计指标,并将其发送给专业设计部门。
例如,结构设计部门,您需要多少强度要求。
电力设计部,你想在这里支持多少。
显然,在分析这些需求时,它会从整体上看,因为有些指标是相互制约的。例如,如果你的力量非常大,那么你的体重可能很重,你的力量需求会很高。
借鉴这一理念,在使用情境设计时,您还需要考虑这种全局性。
在进行需求分析和设计时,我们必须不时退一步看看四层关系和总体目标。确保不会偏离路线。
《需求设计》这本书,我会推荐BA阅读偏向于背景设计,特别是投诉和程序猿通讯无法读取BA。
该计划不止一次地提醒我:“你有计划与客户联系,当然没问题。但我们需要在设计过程中考虑更多细节。”
如果我们能够在需求分析和设计的早期阶段通过情境设计验证要求,然后确保解决方案的整体效果,那么它就是解决“看树,不看森林”问题的方法之一。
肖燕是一名高级商业分析师(BA),他走在实践的道路上。如果你想和我一起走,请关注我!