Organização do Workshop

O workshop de casos de uso é uma reunião de brain-storming organizada. É necessário apresentar um grande conhecimento sobre:

• Requisitos do cliente
• Design do sistema
• Design da unidade
• Rational Unified Process
• Teste

Isso significa que o grupo conterá pessoas com conhecimentos e experiências diferentes. Tente manter pequeno o grupo (menos de dez). Uma configuração regular é compilar parte do grupo da equipe de desenvolvimento e a outra parte de representantes do usuário. No meio disso tudo está o facilitador. O facilitador deve desempenhar a função de um moderador - um captador de todas as idéias e desejos.

Ferramentas

Ferramentas necessárias:

• Dois quadros brancos grandes (um é suficiente, mas dois é melhor)
• Gráficos Easel
• Fita adesiva
• Notas adesivas de duas cores
• Canetas para quadro branco (várias cores)
• Lápis
• Paredes nas quais os papéis serão colocados - preferencialmente em uma "sala pouco utilizada" que você pode utilizar e deixar desorganizada por duas ou três semanas.

Definindo Agentes

Tente identificar quem ou o que utilizará o sistema. Comece com pessoas reais que utilizarão o sistema; a maioria das pessoas aproveitam melhor o tempo concentrando-se no concreto versus abstrato. Quando os usuários forem identificados, tente identificar a função que o usuário desempenha durante a interação com o sistema - esse é um bom nome para um Agente.

Ao identificar agentes, certifique-se de gravar uma curta descrição para cada agente; normalmente poucos indicadores capturando a função que o agente desempenha com relação ao sistema e as responsabilidade do agente ajudarão posteriormente, quando for o momento de determinar o que o agente precisa do sistema.

Ao definir os agentes, não se esqueça dos outros sistemas com os quais o sistema deve interagir. O ícone para um agente é enganador aqui - ele parece implicar 'pessoa', mas o conceito de agente inclui também os sistemas. Concentre-se primeiro em localizar os agentes 'humanos'; a maioria dos grupos fará melhor quando estiverem concentrados no que for familiar primeiro, e depois irão considerar o que for mais estranho.

Não se preocupe com a estrutura do Modelo de Casos de Uso ou com os relacionamentos entre os agentes; simplesmente determine as pessoas ou as coisas que utilizarão o sistema. Concentre-se na identificação e esteja preparado para localizar muitos agentes. Não se preocupe muito com a filtragem da lista agora; a identificação dos casos de uso (veja abaixo) fará isso.

Um Sistema Administrativo

Faça esta pergunta: Quais são as funções na organização que utilizarão esse sistema? Desenhe um homem para cada função sugerida e escreva um nome abaixo dele. Em seguida, liste duas colunas de agentes no quadro branco - um em cada lado do desenho que acabou de fazer. Às vezes, pode ser útil usar a palavra função ou usuário em vez de agente.

Faça as perguntas:

• Quem utilizará este sistema?
• Que outros sistemas receberão informações deste sistema?
• De que outros sistemas receberemos informações?
• Quem inicia o sistema?
• Quem manterá as informações do usuário?

Instância ou Classe?

Você pode receber perguntas como "Por que Tom não é o agente? É sempre o Tom que faz isso". Será necessário fazer mais perguntas para compreender qual é a função de Tom. O nome do agente deve refletir a função.

• Qual é a função de Tom?
• Quem mais pode desempenhar essa função?
• Por que Tom desempenha essa função?

Muitos agentes podem ser identificados diretamente por meio de posições regulares na organização. Uma posição na organização pode corresponder a mais de uma função para o sistema. Por exemplo, Tom pode ser um funcionário regular do depósito, bem como a pessoa responsável pela reorganização do depósito para criar espaço para novos produtos. Essas duas responsabilidades podem ser dois diferentes agentes para o sistema.

Algumas pessoas desejarão generalizar ao extremo. Elas podem sugerir um Usuário como agente - e sugerir que precisam apenas desse agente. Verdade - mas muito chato e não acrescenta muito à compreensão do sistema. Tente evitar a discussão dessa sugestão se ela surgir. Anote o agente Usuário no quadro e passe para o próximo agente.

Sugestões de Comércio

• Pergunte a todos se falta alguma coisa.
• Faça algumas sugestões inválidas. Dessa forma, a equipe pode corrigir você e explicar as funções exatas do sistema.
• Sempre aceite todas as sugestões - será possível remover as duplicatas e os não-agentes mais tarde. Criticar a sugestão de alguém estragará o espírito da reunião.

Definir os agentes normalmente leva de 1 a 4 horas. O quadro branco não deve listar muitos agentes, pois ainda deve haver espaço para incluir os casos de uso. Quando o conjunto de agentes estiver completo, inicie a anotação dos casos de uso.

Definir Casos de Uso

Apague o desenho do quadro branco e comece a identificar os casos de uso. Concentre-se nos casos de uso concretos - evite discussões sobre relações de inclusão e extensão. Desenhe uma elipse e escreva o nome de cada sugestão. Desenhe setas para os agentes.

Utilize o fato de que você não saber nada sobre a aplicação, como a duração. Os participantes do workshop precisam dizer a você o que o sistema deve fazer. Você deve fazer muitas perguntas sobre o sistema. Quando os participantes fornecerem uma explicação, os casos de uso aparecerão.

Algumas pessoas podem entender o conceito de casos de uso da forma correta, mas algumas pessoas não. Para colocar o conceito em uma perspectiva mais fácil, peça a alguém para desenhar a visualização de um sistema. Uma visualização do sistema é uma abstração do sistema. Por exemplo, ele pode ser um servidor com um banco de dados e um número de clientes ou um número de placas de circuito com suas tarefas especiais marcadas. Essa visualização é normalmente fácil de ilustrar: um dos participantes vai até o quadro branco e mostra como o sistema trabalhará. A visualização do sistema ajudará a estender os casos de uso de um lado a outro do sistema e apontará implicitamente para um número de estados diferentes do sistema. Faça perguntas sobre esses estados para que mais casos de uso surjam. Verifique o que acontece quando comunicações diferentes são perdidas - isso pode ajudar a identificar fluxos alternativos nos casos de uso.

Se você estiver trabalhando com um sistema técnico, a visualização do sistema é normalmente algo bem conhecido por alguém e pode ser a melhor forma de localizar agentes. Nesse caso, você pode permitir que desenhem a visualização do sistema antes de começar a perguntar sobre os agentes.

Se você estiver trabalhando com um sistema administrativo, a visualização do sistema pode não ser óbvia para todos. Nesse casso, um gráfico descrevendo as rotinas manuais pode ser mais útil. O gráfico pode descrever como uma entidade de negócios é movida de uma pessoa para outra e o que elas devem fazer com ele. Para visualizar o processo de pedido e entrega, o gráfico pode mostrar uma visualização esquemática do escritório do cliente e do nosso escritório, o armazenamento e o armazenamento do cliente.

Certifique-se de que o modelo de casos de uso e a visualização do sistema/entidade dos negócios estejam claramente visíveis para todos. Esse é o motivo pelo qual é bom ter dois quadros brancos.

Permita que os casos de uso tenham nomes longos. Um caso de uso identificado recentemente pode ter um nome tão longo quanto uma sentença - esse será um bom começo na descrição breve do caso de uso, e depois o nome pode ser abreviado.

Haverá sempre um número de casos de uso que parecem ter partes em comum. Certifique-se de que todos entendam que isso é aceitável nesse momento. Ainda não há nenhum ponto na estrutura, pois não sabemos o suficiente sobre o conteúdo dos casos de uso. Você deve aguardar até que o fluxo de eventos seja descrito antes que surjam quaisquer discussões sobre os relacionamentos do caso de uso.

Quando o grupo concordar que os casos de uso no quadro cobrem a funcionalidade de todo o sistema, faça uma pausa para o almoço.

Após o almoço, revise os resultados das atividades da manhã:

• Analise cada Agente: Quais são suas atividades nesse sistema? Tarefa pode ser uma palavra melhor do que caso de usos para pessoas que não estão familiarizadas com as técnicas de modelagem de casos de uso.
• Analise cada Caso de Uso sugerido: Você entende o valor que o usuário alcançará com o caso de uso? Se o caso de uso tiver um resultado positivo, o usuário terá mais vontade de executar o caso de uso.
• Analise cada caso de uso sugerido: O caso de uso está completo? Ou esta é apenas uma pequena parte de algo bem maior?

Faça as perguntas:

• Cada agente deve ter apenas um caso de uso. Caso contrário, isso pode ocorrer porque o agente está duplicado (outro agente desempenha a mesma função) ou porque o agente não é realmente um usuário direto do sistema. Nesses casos, se uma discussão com relação a manter o agente for iniciada e não houver nenhum motivo relevante para mantê-lo, o agente deve ser removido.

Escreva uma Breve Descrição para cada Caso de Uso

Trabalhe com os casos de uso um por um e crie um gráfico easel para cada caso de uso. Desenhe uma elipse e escreva o nome do caso de uso na parte superior do gráfico. Peça ao grupo para ajudá-lo a escrever uma breve descrição do caso de uso. Uma breve descrição deve ter de 1 a 3 sentenças. Às vezes, é útil desejar os agentes conectados aos casos de uso. Tente deixar metade do papel vazio para a próxima etapa.

Durante esse trabalho, você descobrirá que há alguns itens que pensava estar claros e que, na verdade, não estão. Consulte os requisitos identificados como necessidades e recursos principais do usuário em Visão e tente saber se há alguns Requisitos nesse caso de uso.

Novos casos de uso aparecerão. Alguns casos de uso desaparecerão. Coloque os papéis de casos de uso na parede. Tente organizá-los com uma coluna por área funcional. (Não utilize os quadros brancos para isso - eles serão necessários para a visualização do sistema, os agentes e os casos de uso.) Se você puder resolver as questões imediatamente, anote-as em uma nota adesiva e coloque-as no caso de uso apropriado. Utilize uma cor para as questões.

Quando todos os casos de uso tiverem um gráfico easel e uma breve descrição, é o momento de passar para o próximo modo. É importante destinar algum tempo para discussões sobre se esses são realmente os casos de uso necessários.

O modelo criado pode ser documentado em Rational Rose ou Rational RequisitePro e gerado no relatório Sintético de Modelos de Casos de Uso.

Descrição Etapa por Etapa do Fluxo de Eventos para cada Caso de Uso

O modo de iniciar as anotações de um caso de uso é estruturar o texto primeiro. Não é aconselhável sentar-se sozinho e tentar estruturar o texto sem primeiro obter idéias dos investidores.

Trabalhe com os casos de uso um por um. Anote as diferentes ações em ordem. Não tente descobrir como as coisas serão em estruturas de códigos, loops, instruções de momento, etc. - trabalhe apenas com o fluxo básico de eventos e não se preocupe com as alternativas. Enumere as etapas 1, 2, 3, 4. Para ajudar o grupo a entender o nível de detalhes exigido, você pode dizer que precisa de 5 a 10 etapas no fluxo básico.

Depois de concordarem com as etapas no fluxo básico de eventos, navegue por elas e identifique etapas alternativas. Enumere os fluxos alternativos A1, A2, A3, A4,

Durante essa discussão, surgirão muitos problemas, muitos que não serão resolvidos até chegar à etapa Análise & Design. Lembre-se de anotar todos os problemas, juntos com as premissas que serão feitas ao longo do processo. Alguns dos problemas devem ser resolvidos logo, para que o Especificador de Requisitos possa detalhar o fluxo de eventos corretamente; alguns deles são itens que precisam ser resolvidos antes do início da etapa Análise & Design.

O que você tem em cada gráfico easel deve ser suficientes para que as Especificações de Requisitos detalhem o fluxo de eventos do caso de uso.

Capturar Especificações Suplementares

Durante essa sessão, haverá vários Requisitos no sistema que talvez você não possa capturar prontamente em um caso de uso. Normalmente, essas instruções se relacionam a funcionalidade, utilidade, confiabilidade, desempenho e capacidade de suporte do sistema. Mantenha um gráfico easel separado para anotar essas instruções. Eles formarão uma base para as Especificações Suplementares.

Requisitos de Rastreio para Casos de Uso

Navegue pelos principais Pedidos dos Investidores e cada recurso no documento Visão e verifique se o modelo de caso de uso os abrange de modo apropriado. Discuta quais as necessidades ou os requisitos dos usuários que são rastreados para quais casos de uso.

Pegue o documento Visão e leia o primeiro recurso. Anote sua identidade em uma (ou mais, se necessário) nota adesiva (utilize uma segunda cor para facilitar a distinção entre requisitos e problemas). Coloque a nota nos casos de uso que atenderem a esse requisito. Posteriormente, você pode inserir essas rastreabilidades no repositório RequisitePro.

Há sempre um número de Requisitos que não podem ser conectados a nenhum caso de uso:

• Eles podem ser requisitos específicos que devem ser adiados para o design - coloque esses requisitos em um papel (requisitos de design).
• Eles podem ser requisitos gerais que não podem ser conectados a nenhum caso de uso - coloque-os na lista de Especificações Suplementares.
• Eles podem ser requisitos que foram esquecidos e exigem novos casos de uso ou alterações nos casos de uso existentes.

Dedique algum tempo para revisar a estrutura da sala: Há casos de uso sem nenhum requisito? Por quê? Esse caso de uso não é exigido? Ou essa funcionalidade foi esquecida pela pessoa que escreve a especificação de de requisito? (Esse é normalmente o caso.) Essa situação deve ser resolvida. O cliente está consciente de que precisa dessa funcionalidade? Ele pretende pagar por isso?