发布时间：2020-3-6 分类： 电商动态
如果《用户故事地图》可以解决大部分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），他走在实践的道路上。如果你想和我一起走，请关注我！
