Capturando requisitos funcionais com casos de uso e histórias de usuários

O primeiro passo na definição de um novo produto, serviço, processo ou sistema é definir os requisitos, ou seja, requisitos funcionais ou não funcionais específicos.

• Os requisitos funcionais descrevem como o produto ou serviço atende às necessidades do cliente. Isso inclui recursos e funcionalidades em casos de uso que documentam como os usuários irão interagir com o produto ou serviço.
• Requisitos não funcionais são atributos operacionais e de produto que às vezes não são óbvios para o usuário, incluindo desempenho, usabilidade, durabilidade, segurança e financeiro (preço e custo).

EDITE ESTA ILUSTRAÇÃO – REQUISITOS FUNCIONAIS VERSUS REQUISITOS NÃO FUNCIONAIS

Os requisitos funcionais podem ser pensados ​​como o que o produto precisa fazer para o cliente, enquanto os requisitos não funcionais podem ser vistos como restrições que o produto ou serviço precisa ser projetado para atender.

Os requisitos funcionais capturam o comportamento pretendido do sistema. Esse comportamento pode ser expresso como serviços, tarefas ou funções que o sistema deve executar. Na indústria de desenvolvimento de software, a abordagem de caso de uso rapidamente se tornou uma prática difundida para capturar requisitos funcionais. Isso é especialmente verdadeiro na comunidade orientada a objetos e UML onde eles se originaram, mas sua aplicabilidade não se limita a sistemas orientados a objetos.

Quais técnicas para capturar os requisitos funcionais?

Os requisitos funcionais geralmente são capturados na forma de casos de uso ou cenários de usuário. Esses termos às vezes são usados ​​​​de forma intercambiável, mas na verdade significam coisas ligeiramente diferentes.

• Os casos de uso se concentram mais no sistema e no que ele deve fazer para atender às necessidades dos usuários.
• As histórias de usuários , por outro lado, mostram a funcionalidade do produto do ponto de vista do usuário, especificando as funções do usuário e os objetivos específicos que eles desejam alcançar.

Capturando o requisito funcional usando histórias de usuário

As histórias de usuário são um método leve para capturar rapidamente o “quem”, “o quê” e “por que” dos requisitos de um produto. Simplificando, histórias de usuários são ideias que expressam as necessidades que os usuários desejam. As histórias de usuários são curtas e cada elemento geralmente contém menos de 10 ou 15 palavras. As histórias de usuários são listas de “tarefas” que ajudam a identificar as etapas ao longo do caminho do projeto. Eles ajudam a garantir que seu processo e o produto resultante atendam aos seus requisitos.

Modelo de história de usuário

As histórias de usuários capturam apenas os elementos essenciais de um requisito:

• Para quem é?
• O que espera do sistema?
• Por que é importante (opcional?)?

Aqui está um formato simples de história de usuário usado por 70% dos profissionais:

Função  – O usuário deve ser um humano real que interage com o sistema.

• Seja o mais específico possível
• A equipe de desenvolvimento NÃO é um usuário

Ação  – O comportamento do sistema deve ser escrito como uma ação.

• Geralmente exclusivo para cada história de usuário
• O “sistema” está implícito e não é escrito na história
• Voz ativa, não voz passiva (“Posso ser notificado”)

Benefícios  – O benefício deve ser um resultado do mundo real que não seja funcional ou externo ao sistema.

• Muitas histórias podem compartilhar a mesma declaração de benefício.
• O benefício pode ser para outros usuários ou clientes, não apenas para o usuário da história.

Como identificar os requisitos funcionais com o caso de uso?

Para entender completamente os requisitos funcionais do sistema, você deve saber para quem é o sistema, ou seja, quem usará o sistema?

A resposta a esta pergunta é: o ator na análise de casos de uso

Casos de uso ou histórias de usuários capturam requisitos funcionais cujo comportamento pode ser expresso como serviços, tarefas ou funções que o sistema deve executar. Os casos de uso definem a interação entre o usuário e o serviço do sistema que pode ajudar a definir os requisitos funcionais do sistema em desenvolvimento. Ou, em outras palavras, o que o produto ou serviço precisa fazer para satisfazer as necessidades e desejos do cliente.

Um caso de uso começa com um “ator” ou “quem”, um usuário específico do produto ou serviço.

Um ator é uma pessoa ou um sistema externo que desempenha um papel na interação com o sistema. Instâncias de atores podem ser indivíduos ou sistemas externos; no entanto, cada ator fornece uma perspectiva única e importante do sistema, uma perspectiva que é comum a cada instância (pessoa/usuário real) do ator.

Usuário real x ator de caso de uso

Para entender completamente o propósito do sistema, é preciso saber para quem é o sistema, ou seja, quem o utilizará. Os diferentes tipos de usuário são representados como Ator (funções).

A diferença entre uma função e um usuário individual é que uma função representa uma classe específica de usuários, em vez de um usuário real. Diferentes usuários podem desempenhar o mesmo papel, caso em que cada usuário constitui uma instância de um ator.

Essa distinção entre atores e instâncias de atores é ilustrada a seguir:

A Figura abaixo mostra um caso em que Mary e John são clientes de uma máquina de venda automática. Quando eles usam a máquina de venda automática, cada um é representado por uma instância de um ator chamado cliente que espera ter acesso a determinadas funções do sistema (neste caso a impressão de comprar comida).

EDITE ESTA ILUSTRAÇÃO DE MÁQUINA DE VENDA AUTOMÁTICA

Por outro lado, o mesmo usuário pode desempenhar vários papéis (ou seja, a mesma pessoa pode desempenhar papéis diferentes).

Por exemplo, o Dr. Gates, que é membro do comitê da Computer Society. Ele é responsável por gerenciar o sistema de gerenciamento de membros, como adicionar e remover contas de usuários. Quando ele faz isso, ele desempenha um papel chamado Administrador (Ator). No entanto, o mesmo Dr. Gates também pode ser membro da Computer Society. Neste caso, ele também desempenharia um papel chamado “Membro” (Ator)

Como obter os requisitos funcionais identificando os casos de uso do sistema

Um caso de uso pode ser identificado perguntando aos interessados ​​os seguintes tipos de perguntas (às quais eles devem responder do ponto de vista dos atores):

• O que os usuários nesta função estão tentando realizar?
• Para cumprir esse papel, o que os usuários precisam ser capazes de fazer?
• Quais são as principais tarefas dos usuários nessa função?
• Quais informações os usuários nessa função precisam examinar, criar ou alterar?
• O que os usuários nessa função precisam ser informados pelo sistema?
• O que os usuários nessa função precisam informar ao sistema?

Observe que:

Os casos de uso são frequentemente usados ​​como um meio de descobrir e representar requisitos funcionais e de sistema, pois um caso de uso define as interações e tarefas necessárias para executar para cumprir uma meta de negócios específica. No entanto, eles geralmente não são uma boa maneira de definir requisitos não funcionais, como desempenho e qualidade do sistema.

Referências

• História de usuário versus caso de uso para desenvolvimento de software ágil
• O que é história de usuário?
• O que é Mapeamento de História de Usuário?
• Identifique os requisitos do usuário com diagramas de caso de uso
• Como usar wireframes com histórias de usuários?
• Abordagem Orientada a Casos de Uso para Desenvolvimento Ágil
• O que é Especificação de Caso de Uso?