Três Eixos na Análise de Requisitos de Negócios - Análise Detalhada

Estou participando do "Programa Nuggets · Sailing"

Depois de analisar o valor do negócio, os casos de uso de negócios e os processos, a próxima etapa é realizar uma análise detalhada do negócio. Sabemos que o próprio programa é uma máquina de estados. Agora usamos um programa para descrever um requisito, ou seja, para descrever um requisito com uma máquina de estados. Naturalmente, um requisito de negócios também é uma máquina de estados. Portanto, analisar requisitos é, na verdade, analisar como expressar esse requisito com uma máquina de estado. Nos requisitos de negócios, os objetos de negócios são frequentemente usados ​​para representar o status dos requisitos de negócios. Portanto, nesta etapa de análise detalhada, precisamos fazer apenas duas etapas, identificar o objeto da entidade de negócios e analisar o objeto da entidade de negócios.

Identificar objetos de entidade de negócios

Como identificar objetos de entidade de negócios a partir de requisitos de negócios

• Método verbo-substantivo: De um modo geral, quando discutimos requisitos, sempre podemos descrever alguns cenários de demanda. Por exemplo, o usuário A reservou uma reunião; o usuário A entrou em uma videoconferência; e assim por diante, neste momento, obviamente Obtenha alguns objetos de entidade comercial e o comportamento desses objetos: a videoconferência é um objeto de entidade comercial, os usuários podem ingressar na videoconferência, o que significa que o objeto de videoconferência precisa fornecer o comportamento de ingresso
• Método de análise do processo do usuário: Através do processo de negócio obtido pela análise do processo principal, podemos ver quais processos os usuários devem passar ao usar nossos produtos. Esses processos devem corresponder a um ou mais objetos de negócios, então nesses processos de negócios No processo , usando o método verbo noun para descrever o cenário de uso do usuário, o objeto de entidade comercial correspondente pode ser extraído.

Como determinar se um objeto de entidade comercial foi encontrado

O objeto de entidade de negócios corresponde ao objeto de entidade em DDD e possui várias características óbvias:

• O objeto de entidade é identificado por um id exclusivo, e o id geralmente pode ser dividido em um id comercial e um id de chave primária. O id comercial é encontrado na análise de demanda. A característica do id comercial é que ele tem significado comercial e os usuários podem entender o significado desse id. Por exemplo, quando criamos o banco de dados, uma videoconferência será identificada por um ID de chave primária de banco de dados. Essa chave primária de banco de dados não tem significado comercial e não pode ser compreendida pelos usuários, mas o número da reunião de uma videoconferência tem significado comercial e os usuários sabe disso. Há apenas uma videoconferência por trás desse número de conferência. E nosso objetivo nesta etapa é encontrar o número da conferência, o id comercial que identifica exclusivamente a videoconferência e, naturalmente, obter o objeto da entidade comercial da videoconferência.
• Existe um ciclo de vida. Um objeto de entidade de negócios passará por vários ciclos de vida de criação, uso e destruição, e outros ciclos de vida podem ser derivados de acordo com os requisitos de negócios. Portanto, para determinar se o objeto encontrado é um objeto de entidade comercial, você pode ver se ele tem um ciclo de vida.

Em resumo, podemos resumir o seguinte:

Analisar objetos de entidade de negócios

Após identificar o objeto de negócios, a próxima pergunta que encontramos é: qual é o conteúdo do objeto de entidade de negócios a ser analisado? Em geral, os objetos de negócios precisam ser analisados ​​para o seguinte:

Analisar o ciclo de vida de um objeto

O ciclo de vida de um objeto deve começar a partir da demanda real.A partir do processo de análise de demanda, analisamos o processo de negócio e, correspondentemente, precisamos extrair do processo de negócio o ciclo de vida do objeto.

Por exemplo, haverá uma função de gravação em uma videoconferência, então podemos extrair o objeto entidade de Record. Correspondentemente, existem dois estados de gravação em uma videoconferência, a gravação não foi iniciada e a gravação foi iniciada, e os comportamentos correspondentes são iniciar a gravação e finalizar a gravação. Assim, registrando este objeto de entidade, o ciclo de vida correspondente pode ser conforme mostrado na figura:

Analise o comportamento dos objetos

• Comportamento simétrico: O comportamento deve ser simétrico e, se ocorrer operação assimétrica, os motivos específicos devem ser explicados.

Por exemplo, a ativação do mudo deve ser acompanhada da ativação do som, e esse comportamento é simétrico. No entanto, nem todos os mudos acompanham necessariamente todos os desativação do som, porque é quase impossível que todos liguem o microfone ao mesmo tempo em uma videoconferência. A prioridade de cancelar toda a função mudo não é tão alto, então você pode fazê-lo primeiro. Portanto, o comportamento neste momento pode ser assimétrico.

Para outro exemplo, tomando como exemplo o objeto de gravação, se houver uma operação para iniciar a gravação, deve haver uma operação para encerrar a gravação.

• Comportamento repetido: Como lidar com a execução repetida do mesmo comportamento no mesmo estado.

Por exemplo, A agora está silenciado e, em seguida, o mesmo host ou hosts diferentes executam várias operações de silenciamento em A. Quando tal situação ocorre, como o host e A devem se comportar?

Para outro exemplo, para o comportamento de iniciar a gravação, no estado em que a gravação já foi iniciada, o que devo fazer se a gravação inicial for executada novamente? Neste momento, será descoberto que o comportamento de iniciar a gravação precisa satisfazer a idempotência.

• Comportamento conflitante: Refere-se ao que fazer quando diferentes comportamentos são executados no mesmo valor de estado, resultando em resultados diferentes.

Por exemplo, A e B são os moderadores e C é um participante comum. Neste momento, A solicita ligar o microfone de C, e B quer silenciar o todo, então para C, ambos os comportamentos são válidos, e o dois comportamentos entram em conflito Agora, o que devemos fazer neste momento?

• 并发的行为：同一时间使用创建同一资源时，存在并发操作的场景，此时应该怎么处理。

比如，如果视频会议被设计成有人加入则创建，没人加入则不创建，那么当A和B同时使用同一个会议号加入会议时，就会存在并发操作，此时视频会议肯定不能创建多个，否则就会违背了一个会议号同一时间只能有一场视频会议的规则。对于这个场景，就需要使用分布式锁等措施来对并发操作进行处理。

又比如，视频会议中有A、B两个主持人，他们同时开始录制，那么此时我们的预期是同一时间一场视频会议只能存在一场录制。那开始录制的行为需要满足唯一性的约束。

分析对象之间的关系

对象的关系主要分析数量关系和依赖关系。其中，依赖关系尤为重要。

• 数量关系。数量关系比较容易识别，一般分为三种，一对一（1: 1）、一对多 (1:n)、多对多 (m: n)。识别对象之间的数量关系，有助于我们对数据库进行设计，通过对象可以映射到数据库表中，对象与对象之间要如何关联。

• 依赖关系。若两个对象之间存在依赖关系，意味着一个对象的创建需要依赖另一个对象存在，一个对象的销毁也可能影响到另一个对象，那么在分析时就要同时关注两个对象之间要怎么配合。

  比如，我们分析出来视频会议和视频会议成员两种对象，那么视频会议成员必须在视频会议创建之后才会被创建出来，而在视频会议结束的时候，视频会议成员也必须跟着销毁。这涉及数据一致性的问题，理清这其中的依赖关系可以让我们知道对象之间应该如何保持数据一致性。

分析对象中的属性（状态值）

对象的属性，其实都是状态值。根据属性是否可变，分为两种，不可变属性和可变属性。

• 如果属性自对象诞生，直到对象消亡，都不会改变，这种叫不可变属性，比如对象id、创建时间、业务上的唯一标识（如身份证等）。这种不可变属性的要识别出来比较简单，而且因为其在对象生命周期不会变化，因此对业务流程的影响不大。
• 如果属性自对象诞生之后可以变化，则称为可变属性。对这种属性进行分析会比较麻烦，因为属性的变化往往带来一系列的变化，详情可以参照下面的状态值分析。

业务实体对象状态值分析

在业务需求开发中，对象的状态往往需要记录到数据库，或者其他的存储介质中。对于状态值的处理如果不当，会产生相当多的bug和技术债，更严重的甚至会导致用户数据丢失，引起丢单。因此，业务实体对象的状态值分析，是整个设计重中之重，值得多花一点时间来仔细梳理。

识别对象的状态

做过业务需求分析的同学都知道，要找齐对象状态并不容易，而且都会有如下几个问题：

• 什么是状态？

根据需求、交互和梳理出来的主流程，识别出哪些内容需要记录。所有用户设置的选项、客户端显示出来的值等等都是状态。注意，我们只需要将精力花在可变属性上即可，对于不可变属性，由于对业务的影响不大，在精力分配上可以不用过多关注。不过前提是你已经确认这个属性是不可变的。

• 还没进行系统设计，在实现时需要的状态值没找出来怎么办？

不需要找出系统设计时的状态值，那是系统设计要关心的事情，我们只需要找到需求中提到的状态即可

• 需求分析上提到的状态还是找不全怎么办？

不需要担心，显而易见的状态肯定能找到，其他没那么明显的状态，我们可以通过后续的几种技巧把它们找出来

• 如果发现有些状态没有依附在对象上怎么办？

这是不可能的，如果真的有这样的状态，那肯定是缺少了对业务实体对象的抽象，说明这里需要提炼出一个业务实体对象。

分析对象的状态

对于找到的状态值，逐个分析清楚：

• 初始状态值是什么
• 状态发生变化的判定条件：
  • 谁能改变状态值（只有主持人才能静音别人）
  • 在什么情况下不能改变状态值（主持人不能被静音、视频会议开始了不能修改等）
• 状态可以如何改变
  • 改变状态有几种入口？（预约详情页能修改，视频会议界面中也能修改）
  • 状态值如何发生转移？（假设一共有A、B、C三种状态，只能从A -> B -> C这样转移，现在是A状态，在经过什么操作之后会变成B状态，什么情况下不能从C状态变成B状态）
  • 状态值可以是什么？
    • 是否破坏了业务唯一性：状态发生变更后是否破坏了业务上的约束条件（比如 视频会议要求会议号唯一，如果支持人为修改会议号的话，修改后的会议号不能和已有的会议号重复，否则就会破坏了业务上要求会议号唯一的约束）
    • 状态的边界值是什么：对状态的取值尝试拓宽它的极限，看它的极限值在什么地方。不止是产品经理，甚至是研发往往都会在这个地方缺乏考虑
      • 数值型的最大最小值
      • 字符串型的长度限制
      • 字符串型的内容限制：如果是文本内容，输入一些违规词汇能否正确处理？如果是url、邮箱等有固定格式的内容，输入一些不符合格式的字符串是否符合需求？
      • 时间型的时长极限值（比如视频会议的时长能否到达100年？）、时间最值（比如预约了一个100年后的视频会议？）、时间间隔的粒度等等（比如间隔1ms的时间开始一次录制？）
      • 列表类型的极值，这可能是最容易被忽略的属性了，比如一次性传入一个长度是100w的列表？ 这明显不合理，那么当你想要对这个列表长度做限制的时候，自然就会发现这部分需要产品定义边界值，或者分批处理
• 状态变更后的生效时机
  • 更改了状态值，是对当前视频会议立即生效，还是对下场视频会议才生效？
• 状态生效后，会对哪些模块有影响
• 状态变更失败时，需要执行什么回退操作
  • 比如，有人入会失败了，要通知xxx

需要注意的是，虽然上面列出了很多分析的维度，但并不是每个属性都会有这些维度。上面列出的只是一些可供参考的范围，只是提供了一些分析的方向，肯定不会是最全面的，在分析时还是要结合业务需求来分析。

这么分析有什么优劣？

优势

• 这套方法在我实际工作中运用了有两年多了，按这套方法执行下来，基本能做到需求的核心场景不遗漏，边界场景少遗漏，对后续的开发、测试环节都比较容易达成共识。
• 方便形成测试用例。作为研发也需要设计测试用例，不然你怎么知道你写的代码是不是已经满足了要求？
• É conveniente abstrair objetos de domínio. Os objetos de domínio são a base do design do sistema.Com os objetos de domínio, você pode unificar facilmente a terminologia e discutir com todas as partes relevantes. Incluindo, mas não limitado a back-end, front-end, lado do cliente, testes, gerentes de produto e outros colegas.
• para armazenamento posterior. Suponha que você reveja o requisito em alguns meses ou até mesmo um ano. Apenas olhar para algumas páginas dos requisitos do gerente de produto não revela rapidamente as regras de negócios do requisito. Mas olhando para sua análise de necessidades pode-se entender as necessidades naquele momento em pouco tempo. Claro, também é muito amigável com outros recém-chegados que querem assumir essa demanda.

desvantagem

• Requer um certo grau de cuidado e paciência dos alunos de P&D.
• É necessário ter comunicação suficiente com gerentes de produto ou usuários reais.
• A análise de requisitos demorada será um pouco mais longa do que antes, mas para o processo de P&D de acompanhamento, definitivamente vale mais a pena gastar tempo na análise de requisitos guiada por métodos do que descobrir os erros e omissões de requisitos nas etapas a seguir. -up processo e levar ao retrabalho.