Como elicitar casos de uso? Parte 3.

Dando continuidade à sequência de posts sobre casos de uso, vou comentar agora sobre a importância da obtenção de valores agregados ao negócio na elicitação de casos de uso.

Um dos pontos mais críticos em uma gestão de requisitos com casos de uso é a correta elicitação dos casos de uso. Na hipótese disso não ser muito bem feito, trará conseqüências desastrosas à eficácia do projeto.

Um caso de uso pode ser identificado respondendo a seguinte pergunta feita a um usuário: O que você pretende obter usando o sistema? A resposta que ele dará é algo relacionado ao resultado de valor que ele espera obter ao usar o sistema. Na verdade, a modelagem de casos de uso é a arte de identificar valores que o sistema deve agregar ao negócio. Por isso quando estamos elicitando casos de uso, devemos estar muito atentos para que todos esses resultados de valor sejam obtidos. Nossa preocupação é fazer com que o conjunto dos casos de uso que modelarmos, entregue todos esses valores esperados. O escopo de cada caso de uso está fortemente associado à obtenção de valores agregados ao negócio.

Percebo com certa freqüência que alguns analistas de negócio ficam preocupados com o número de transações nos fluxos de eventos dos casos de uso. Alguns dizem que se o caso de uso tiver mais de 10 (dez) transações é necessário quebrar o caso de uso em dois ou mais casos de uso. Isso corresponde a uma decomposição funcional, fato que agride totalmente a intenção do Jacobson quando idealizou a técnica de casos de uso, onde uma das suas características é ser diferente da técnica de DFD, ou seja, não ter decomposição funcional.

Essa preocupação demonstra que o analista não conhece os fundamentos da técnica de modelagem de casos de uso. O que faz elevar o número de transações é o fato do analista de negócio descrever a navegação do usuário ao usar o sistema. Os fluxos de eventos não devem descrever a navegação do usuário, e sim a intenção do usuário ao usar o sistema, a qual é obter o resultado de valor para o negócio.

O valor deve estar fortemente associado (rastreabilidade) com as Necessidades do Negócio. Este será assunto para um outro post que pretendo escrever num futuro próximo.

Então, o que significa o termo “valor para o negócio”? Todo funcionário (colaborador) de uma empresa trabalha gerando valores para o negócio. E que valor é esse?  Um valor é o produto de trabalho, que pode ser concreto ou abstrato. Por exemplo, um pedreiro produz metros quadrado de parede construída. Qual o seu produto de trabalho? Parede. Note que este produto é concreto, passível de medição e de grande importância para o negócio do construtor. Note ainda que se trata de um trabalho manual, ou seja, não usa o sistema de informação para construir uma parede.

O valor pode também ser abstrato. Por exemplo, o que produz um gerente de contas em uma agência de banco?  A resposta indicará os valores que o gerente agrega ao negócio. Por exemplo, um gerente produz empréstimos concedidos, contas correntes abertas, contas de poupança abertas, seguros vendidos, etc. Tudo isso que ele produz agrega valor ao negócio do banco. Antigamente, antes do advento da computação eletrônica, esses produtos eram gerados através de trabalhos manuais. Contudo, atualmente, tudo isso pode ser feito através do uso de um sistema.

Se observarmos com cautela perceberemos também que o valor é sempre um substantivo. Ele pode ser identificado univocamente e possui uma série de características. Com isso, podemos afirmar que o funcionário produz um objeto de negócio. Logo, valores são objetos de negócio. É por isso que dizemos que Modelagem de Casos de Uso pertence ao paradigma de Análise Orientada a Objetos.

O conjunto de valores produzidos pelo sistema constitui o Domínio do Sistema. O Modelo de Domínio reune os objetos de valor para o negócio abordados pelo escopo do projeto.

A questão agora passa ser se esse objeto de negócio é gerado manualmente ou pelo sistema. Se for manualmente (pedreiro produzindo parede), não tem nada a ver com casos de uso de software. Contudo, se esse objeto de negócio for produzido através do sistema (gerente abrindo uma conta corrente), então isso tem tudo a ver com casos de uso. Portanto, a interação entre o usuário e o sistema com a expectativa de produzir objetos que agregam valor para o negócio, corresponde ao caso de uso.

Assim, seria correto dizer que casos de uso modelam expectativas do usuário. Portanto, caso de uso é a resposta obtida do usuário ao perguntar o que ele produz usando o sistema. Só nos resta agora dar um nome adequado a este caso de uso. Isso será assunto para o próximo post.

Com o advento da internet, o cliente passou a ser também um usuário. Logo, o analista de negócio deve estar muito atento, pois o projeto também abrange os valores esperados pelo cliente. Isso é CRM – Customer Relationship Management.

Para concluir, gostaria de salientar que a elicitação de casos de uso é um fator crítico de sucesso para o projeto. O conjunto desses casos de uso deve ser apresentado através do Diagrama de Casos de Uso. É muito comum encontrarmos empresas que não dão a mínima para o Diagrama de Casos de Uso. Concentram-se somente nos documentos de especificação dos casos de uso. Isso é um lamentável equívoco. Este diagrama tem como objetivo oferecer uma visão panorâmica de todo o sistema, permitindo aos stakeholders verificar se o projeto está atendendo à totalidade de suas expectativas. Permite verificar se todos os valores esperados estão ali modelados. É válido salientar ainda que, neste instante do projeto, os stakeholders não estão interessados nas interações usuário X sistema. Seus interesses estão voltados para a eficácia do projeto, ou seja, estão voltados para os valores que o sistema irá agregar ao negócio.

A pergunta que não quer calar: Quem irá definir a navegação e os detalhes das interações entre os usuários e o sistema?  A resposta é: A modelagem da interface do usuário. Jamais os casos de uso.