Outras abordagens para especificação de requisitos by Ruan Alves

MVP (Minimum Viable Product)

ruanalves2 — 2021-05-26 00:26:49 UTC

MVP é uma sigla em inglês para Produto Mínimo Viável. A ideia é de criar um produto com um conjunto de requisitos mínimos, pois o cenário onde esse produto se encaixa pode não ser favorável ao seu sucesso, então, ao invés de despender anos coletando requisitos ou realizando pesquisas de mercado que podem ficar obsoletas com o passar do tempo, é ideal criar um produto simples e evolui-lo conforme novos requisitos surjam, podendo assim testar a viabilidade de continuar investindo no seu desenvolvimento. Fala-se que o objetivo de um MVP é testar uma hipótese de negócio.

O conceito de MVP foi criado em cima do conceito de lean startup, que por sua vez foi baseado em lean manufacturing, seguindo as seguintes ideias:

Melhoria contínua
Redução de custos
Agilidade na produção

O lean startup propõe um método científico para construção e validação de MVPs. Esse método consiste em três passos: construir, medir e aprender. As descrições dos passos são as seguintes:

Tem-se a ideia de um produto, observa-se que o mercado não é favorável e então é implementado um MVP para serem realizados testes.
O MVP é disponibilizado para uso dos usuários para coleta de dados.
Os dados coletados são analisados e são observados os resultados obtidos através de métricas.

A próxima figura ilustra o fluxo dos passos.

O aprendizado obtido com um MVP pode resultar em três decisões:

Pode-se concluir que ainda são necessários mais testes com o MVP, possivelmente alterando o conjunto de requisitos.
Pode-se concluir que o teste foi bem sucedido, encontrando um mercado para o sistema. Nesse caso, é a hora de investir no desenvolvimento, utilizando um conjunto mais robusto e completo de funcionalidades.
Pode-se concluir que o MVP falhou. Após isso, é possível desistir do projeto, ou utilizar uma ideia semelhante repaginada, e fazer novos testes.

É necessário cuidado ao analisar os resultados de um MVP. Um problema possível é utilizar apenas métricas de vaidade, que são métricas que aparentam ser espetaculares, porém não necessariamente indicam o sucesso do produto. Um exemplo é a quantidade de seguidores na página do produto, coisa que não quer dizer nada se isso for olhado individualmente, apenas esse número não custeia nem a energia de um escritório.

Porém, há métricas importantes que ajudam a tomar decisões sobre o futuro do MVP, uma dos principais tipos é chamado de métrica acionável. Esse tipo de métrica é referente aos dados que são importantes para a avaliação de aceitação de um produto, por exemplo, a quantidade de visitantes de um site de vendas que concluem a compra, valores das compras feitas, entre outras várias coisas. Ao monitorar esse tipo de métrica, pode-se observer que é necessário investir em um sistema de recomendação de produtos melhor, por exemplo.

Casos de Uso

ruanalves2 — 2021-05-26 02:38:00 UTC

Casos de uso são documentos textuais de especificação de requisitos. São descritos na perspectiva de um ator que vai utilizar a atividade descrita. Consiste em um conjunto de passos ou numa descrição textual de uma funcionalidade que um ator realiza em um sistema com um determinado objetivo.

A descrição principal de um caso de uso é chamada de fluxo normal, nele é descrito todas as atividades do que é chamado de cenário "happy day", ou "dia feliz" em português, que representa um fluxo sem erros ou desvios.
Existem também descrições secundárias, essas tem nome de fluxo de extensão. São desvios do fluxo principal, geralmente utilizados para detalhar mais uma atividade do fluxo normal, tratar erros, exceções, entre outras coisas.

Um diagrama deve ser simples e direto, não possuindo grande quantidade de passos ou texto complexo descrevendo a atividade. As vezes é recomendado criar um glossário das palavras utilizadas, e também é recomendado padronizar a escrita nos casos de uso.

Em um caso de uso é necessário conter:

Nome do caso de uso
Quem é o ator que vai realizar a ação
Fluxo normal, descrito em passos ou em texto
Fluxos de extensão, também descrito em passos ou em texto

Também é possível que descrições de casos de uso incluam seções adicionais, como propósito do caso de uso, pré-condições, pós-condições e lista de outros casos de usos relacionados.

A próxima imagem exibe um documento de caso de uso.

Há também uma representação gráfica de um caso de uso, chamado de diagrama de caso de uso. No geral, há a figura do retângulo que representa o fluxo, elipses que representam ações e que estão dentro do retângulo, setas ligando as ações, dando a ideia de um fluxo, e os atores do fluxo do lado de fora do retângulo.

O documento de um caso de uso é mais importante que seu diagrama, pois o mesmo fornece mais detalhes de como o fluxo deve ser feito, enquanto que o diagrama abstrai parte disso.

Histórias de Usuários (User Stories)

mauriciomonte — 2021-05-26 10:43:21 UTC

Histórias de Usuários é uma forma de se fazer especificações de requisitos que surgiu da necessidade de corrigir erros presentes nos métodos de especificar requisitos que existiam na época. Nestes métodos, se fazia longos textos corridos que tentavam descrever detalhadamente todas os requisitos de uma aplicação. O problema dessas abordagens antigas era que:

Estes longos documentos de especificação que ficavam obsoletos quando ocorria alguma mudança nos requisitos;
Descrição dos requisitos que ficam ambíguas devido ao uso de linguagem natural escrita;
Os riscos quando não são feitas conversas intermediárias com o cliente eram muito altos.

Uma história de usuário é composta de três partes (formando a sigla CCC):

Cartão, usado pelos clientes para escrever, de forma breve, uma funcionalidade que esperam ver implementada no sistema;
Conversas entre clientes e desenvolvedores, por meio das quais os clientes explicam e detalham o que escreveram em cada cartão;
Confirmação, que consiste em um teste de alto nível que o cliente usa para confirmar a implementação de uma história. Eles devem ser escritos o quanto antes, preferencialmente no início de uma sprint.

A forma de se utilizar cada parte da uma história de usuário é a seguinte: a história que se escreve no cartão é um lembrete do representante dos clientes para os desenvolvedores. Por meio dele, o representante dos clientes declara que gostaria de ver um determinado requisito funcional implementado na próxima iteração (ou sprint). Além disso, durante toda a sprint o representante se compromete a estar disponível para refinar a história e explicá-la para os desenvolvedores. Por fim, ele também se compromete a considerar a história como implementada, desde que ela satisfaça os testes de confirmação que ele mesmo especificou.

Em relação ao métodos antigo de especificação de requisitos, as histórias de usuário trocam um documento de requisitos com centenas de páginas por conversas frequentes, nas quais o representante dos clientes explica os requisitos para os desenvolvedores da equipe. Ademais, histórias de usuários favorecem comunicação verbal, em vez de comunicação escrita.

Boas histórias devem possuir as seguintes características (cujas iniciais em inglês dão origem ao acrônimo INVEST):

Histórias devem ser independentes:dadas duas histórias X e Y, deve ser possível, idealmente, implementá-las em qualquer ordem.
Histórias devem ser abertas para negociação. Os desenvolvedores devem estar abertos para implementar detalhes que não estão expressos ou que não cabem nos cartões da história. E os clientes devem aceitar argumentos técnicos vindos dos desenvolvedores, por exemplo sobre a inviabilidade de implementar algum detalhe da história conforme inicialmente vislumbrado.
Histórias devem agregar valor para o negócio dos clientes. Histórias são propostas, escritas e priorizadas pelos clientes e de acordo com o valor que elas agregam ao seu negócio. Por isso, não existe a figura de uma história técnica, como a seguinte: o sistema deve ser implementado em JavaScript, usando React no front-end e Node.js no backend.
Deve ser viável estimar o tamanho de uma história. Normalmente, isso requer que a história seja pequena e que os desenvolvedores tenham experiência na área do sistema.
Histórias devem ser sucintas. Na verdade, até se admite histórias complexas e grandes, as quais são chamadas de épicos. Porém, elas ficam posicionadas no final do backlog, o que significa que ainda não se tem previsão de quando elas serão implementadas.
Histórias devem ser testáveis, isto é, elas devem ter critérios de aceitação objetivos.

Antes de começar a escrever histórias, recomenda-se listar os principais usuários que vão interagir com o sistema. Assim, evita-se que as histórias fiquem enviesadas e atendam às necessidades de apenas certos usuários. Definidos esses papéis de usuários (user roles), costuma-se escrever as histórias no seguinte formato:

Como um [papel de usuário], eu gostaria de [realizar algo com o sistema]

Por fim, é possível escrever histórias para requisitos não funcionais, mas não faz sentido alocá-las para uma iteração, pois ela deve ser uma preocupação durante todas as iterações do projeto. Por isso, a melhor solução é pedir ao dono do produto para escrever histórias sobre requisitos não-funcionais, mas usá-las principalmente para reforçar os critérios de conclusão de histórias.

Testes A/B (Split Tests)

mauriciomonte — 2021-05-26 11:38:33 UTC

Testes A/B (ou split tests) são usados para escolher, dentre duas versões de um sistema, aquela que desperta maior interesse dos usuários. As duas versões são idênticas, exceto que uma implementa um requisito A e outra implementa um requisito B, sendo que A e B são mutuamente exclusivos.
Ao final do teste, decide-se qual versão despertou maior interesse desses usuários. O requisito vencedor será mantido no sistema e a versão com o requisito perdedor será descartada.

Aplicações:

Testes A/B podem ser usados, por exemplo, quando se constrói um MVP (com requisitos A) e, depois de um ciclo construir-medir-aprender pretende-se testar um novo MVP (com requisitos B);
Também se fazem testes A/B para se decidir entre qual interface de uma aplicação deve ser usada. Por exemplo, dados dois leiautes da página de entrada de um site, um teste A/B pode ser usado para decidir qual resulta em maior engajamento por parte dos usuários.

Para aplicar testes A/B, precisamos de duas versões de um sistema: a versão de controle (sistema original, com os requisitos A) e a versão de tratamento (sistema com novos requisitos B).

Para rodar testes A/B, precisamos de uma métrica para medir os ganhos obtidos com a versão de tratamento. Essa métrica é genericamente chamada de taxa de conversão.

Como exemplo, considere uma situação em que a versão de controle consiste de um sistema de comércio eletrônico que faz uso de um algoritmo de recomendação tradicional e a versão de tratamento consiste do mesmo sistema, mas com um algoritmo de recomendação supostamente mais eficaz. Logo, nesse caso, o teste A/B terá como objetivo definir se o novo algoritmo de recomendação é realmente melhor e, portanto, deve ser incorporado ao sistema.

Neste exemplo, podemos assumir que a taxa de conversão é o percentual de visitas que se convertem em compras por meio de links recomendados. A expectativa é que o novo algoritmo de recomendação aumente esse percentual.

Também é necessário fazer com que metade dos clientes use a versão de controle e a outra metade use a versão de tratamento. É importante que essa seleção seja aleatória. No exemplo de site de compras, é possível automatizar essa divisão dos clientes ao adicionar o seguinte trecho de código dentro do código da página principal:

version = Math.Random(); // número aleatório entre 0 e 1
if (version < 0.5)
   "execute a versão de controle"
else                                                 
   "execute a versão de tratamento"

Após um certo número de acessos, o teste é encerrado e verificamos se a versão de tratamento, de fato, aumentou a taxa de conversão de usuários. Se sim, passaremos a usá-la em todos os clientes. Se não, continuaremos com a versão de controle.

Uma questão fundamental em testes A/B é a determinação do tamanho da amostra. Em outras palavras, quantos clientes deveremos testar com cada uma das versões. Existem vários cálculos estatísticos que envolvem a definição de quantos clientes devem ser utilizados, mas já existem calculadoras de tamanho de amostras de testes A/B disponíveis na Web.

No entanto, é importante destacar que os testes podem demandar um número extremamente elevado de clientes, que somente estão ao alcance de sistemas populares, como grandes lojas de comércio eletrônico, serviços de busca, redes sociais, portais de notícias, etc.

A metodologia dos testes A/B podem ser aplicadas com mais de duas versões de um sistema. Basta dividir os acessos em três grupos aleatórios, por exemplo, se quiser testar três versões de um sistema. Esses testes, com mais de um tratamento, são chamados de Testes A/B/n.

Também é importante deixar um alerta para um erro frequente e grave que acontece ao se aplicar testes A/B: querer prolongar ou encerrar o teste mais cedo. Por exemplo, se o tamanho da amostra for de 200 mil usuários, o teste somente pode ser encerrado quando alcançarmos exatamente esse número de usuários. Ele não deve terminar antes, com menos usuários, nem depois, com mais usuários. Um possível erro de desenvolvedores quando começam a usar testes A/B consiste em encerrar o teste no primeiro dia em que o ganho mínimo esperado for alcançado, sem testar o resto da amostra.