Orientações de Trabalho: Workshop de Caso de Uso
Tópicos
O workshop de caso de uso é uma reunião organizada de brainstorming. Uma ampla gama de necessidades de conhecimentos a ser representada:
- Requisitos do cliente
- Design do sistema
- Design da unidade
- Rational Unified Process
- Teste
Isso significa que o grupo abarcará pessoas com diferentes formações, conhecimentos e experiências. Tente manter o grupo pequeno (menos de dez pessoas). É comum reunir metade do grupo selecionando-se pessoas da equipe de desenvolvimento e a outra metade selecionando-se representantes dos usuários. Incluído no grupo encontra-se o facilitador. Ele deve desempenhar o papel de moderador - um catalisador de todas as idéias e desejos.
As ferramentas necessárias são:
- Dois quadros brancos grandes (um é suficiente, mas dois é melhor)
- Flip charts
- Fita adesiva
- Blocos de anotações autocolantes em duas cores
- Canetas pilot para o quadro branco (várias cores)
- Lápis
- Paredes em que possam ser afixados papéis - preferencialmente em uma "sala estratégica de conferências" que você possa usar e deixar isolada por duas ou três semanas.
Tente identificar quem ou o que usará o sistema. Comece primeiramente com as pessoas reais que usarão o sistema; a maior parte das pessoas tem mais facilidade de concentrar-se no concreto versus o abstrato. À medida que os usuários forem identificados, tente determinar o papel que cada um desempenhará ao interagir com o sistema. Esse papel geralmente indica o nome ideal de um ator.
Ao identificar os atores, certifique-se de escrever uma breve descrição para cada um deles; geralmente a especificação de alguns pontos na captura do papel que o ator desempenhará no sistema e de suas responsabilidade será útil posteriormente quando chegar o momento de determinar o que o ator necessitará do sistema.
Ao definir os atores, não se esqueça dos outros sistemas com os quais o sistema que está sendo projetado interage. O ícone de ator poderá ser enganoso aqui - ele parece implicar "pessoa", mas o conceito de ator engloba sistemas também. No entanto, concentre-se primeiramente em encontrar atores "humanos"; a maior parte dos grupos tem melhores resultados ao concentrar-se no que lhes é familiar primeiramente. Em seguida, pense sobre o que é pouco conhecido.
Não se preocupe com a estrutura do modelo de casos de uso nem com as relações entre os atores; simplesmente capte as pessoas ou os objetos que usarão o sistema. Concentre-se na identificação e se prepare para encontrar muitos atores. Não se preocupe muito em filtrar a lista agora; a identificação dos casos de uso (veja abaixo) fará isso.
Faça a seguinte pergunta: Quais são os papéis na organização que usarão esse sistema? Desenhe um bonequinho para cada papel sugerido e escreva um nome abaixo de cada um deles. Em seguida, liste duas colunas de atores no quadro branco - uma de cada lado da nuvem ou do ícone que você já desenhou. Algumas vezes, poderá ser útil usar a palavra papel ou usuário em vez de ator.
Perguntas a serem feitas:
- Quem usará esse sistema?
- Para que outros sistemas esse sistema enviará informações?
- De que outros sistemas receberemos informações?
- Quem iniciará o sistema?
- Quem manterá as informações dos usuários?
Poderão ser feitas perguntas como, por exemplo, "Por que Tom não é o ator? É sempre ele que faz isso". Será necessário então fazer outras perguntas para compreender melhor qual é o papel de Tom. O nome do ator deverá refletir o papel.
- Qual é o papel de Tom?
- Quem mais também é capaz de desempenhar esse papel?
- Por que Tom tem esse papel?
Muitos atores poderão ser identificados diretamente através de suas posições comuns na organização. Uma posição na organização poderá corresponder a mais de um papel no sistema. Por exemplo, Tom poderá ser um trabalhador comum do depósito e também a pessoa responsável pela reorganização do depósito a fim de criar espaço para novos produtos. Essas duas responsabilidades poderão representar dois atores diferentes para o sistema.
Algumas pessoas desejarão generalizar ao máximo. Elas poderão sugerir um Usuário como ator - e depois sugerir que ele é o único ator necessário. Verdadeiro - mas desinteressante, além de não acrescentar muito para a compreensão do sistema. Tente evitar discutir essa sugestão caso ela surja. Observe o ator Usuário no quadro e depois prossiga e identifique o próximo ator.
- Pergunte a cada pessoa se há algo faltando.
- Apresente algumas sugestões ruins. Dessa maneira, a equipe poderá corrigi-lo e explicar exatamente os papéis do sistema.
- Sempre aceite todas as sugestões - você sempre poderá remover idéias repetidas e falsos atores posteriormente. Criticar as sugestões de alguém simplesmente aniquilará o espírito da reunião.
Geralmente é necessário um período de uma a quatro horas para definir os atores. Nesse momento, muitos atores deverão estar listados no quadro branco, mas certifique-se de que ainda há espaço para adicionar casos de uso. Quando o conjunto de atores parecer estar completo, será o momento de começar com os casos de uso.
Apague a nuvem ou o ícone do quadro branco e comece a identificar casos de uso. Concentre-se em casos de uso concretos - evite discussões sobre relações de inclusão e de extensão. Desenhe uma elipse e escreva o nome de cada sugestão. Desenhe setas apontando para os atores.
Use o fato de não saber nada sobre a aplicação deles como um ponto forte. Os participantes do workshop precisarão informar a você o que o sistema deverá fazer. Faça muitas perguntas sobre o sistema. Quando os participantes fornecerem explicações a você, os casos de uso aparecerão.
Algumas pessoas poderão entender o conceito dos casos de uso imediatamente, o que não ocorrerá com outras pessoas. Para abordar o conceito segundo uma perspectiva mais fácil, faça com que alguém desenhe uma visão do sistema. Essa visão é uma abstração do sistema. Por exemplo, poderá ser um servidor com um banco de dados e uma série de clientes, ou uma série de placas de circuito com suas tarefas especiais marcadas. Geralmente essa visão é fácil de ser ilustrada: um dos participantes usará uma caneta pilot e mostrará, no quadro branco, como o sistema funcionará. A visão do sistema ajudará a fazer com que os casos de uso se estendam de fronteira de sistema para fronteira de sistema e apontará implicitamente uma série de diferentes estados do sistema. Faça perguntas sobre esses estados e aparecerão alguns outros casos de uso. Verifique o que acontecerá quando as diferentes comunicações cessarem - isso o ajudará a identificar fluxos alternativos nos casos de uso.
Se estiver trabalhando com um sistema técnico, a visão do sistema freqüentemente será algo bem conhecido de todos e poderá ser a melhor maneira de encontrar atores. Nesse caso, você poderá deixar que os participantes desenhem a visão do sistema antes de começar a fazer perguntas para identificar atores.
Se estiver trabalhando com um sistema administrativo, é possível que a visão do sistema não seja tão óbvia para todos. Nesse caso, um gráfico que descreva as rotinas manuais poderá ser mais útil. O gráfico poderá descrever como uma entidade de negócios passa de uma pessoa para outra e o que cada uma deverá fazer com ela. Para visualizar o processo de pedido e entrega, o gráfico poderá mostrar uma visão esquemática do escritório do cliente, de nosso escritório, do estoque e do estoque do cliente.
Certifique-se de que tanto o modelo de casos de uso quanto a visão do sistema/da entidade de negócios estejam claramente visíveis para todos. Esse é o tipo de situação ideal para usar dois quadro brancos.
Permita que os casos de uso tenham nomes longos. Um caso de uso identificado recentemente poderá ter um nome tão longo quanto uma sentença - isso será um bom começo para a breve descrição do caso de uso e, posteriormente, o nome será encurtado.
Sempre haverá uma série de casos de uso que parecerão ter partes em comum. Certifique-se de que todos compreendam que isso é aceitável por enquanto. Não há nenhum sentido em iniciar a estruturação nesse momento, já que não sabemos ainda o bastante do conteúdo dos casos de uso. Você deverá aguardar até depois de o fluxo de eventos ter sido descrito para dar início a qualquer discussão sobre relacionamentos de caso de uso.
Quando o grupo concordar que os casos de uso expostos no quadro abrangem a funcionalidade de todo o sistema, faça uma pausa para o almoço.
Após retornar do almoço, revise os resultados da sessão da manhã:
- Examine cada ator: Quais são suas tarefas no sistema? Tarefa pode ser uma palavra melhor do que caso de uso para pessoas que não estejam familiarizadas com a técnica de modelagem de caso de uso.
- Examine cada caso de uso sugerido: Você compreende as vantagens que o usuário obterá com o caso de uso? Se o caso de uso tiver um resultado positivo, o usuário ficará mais inclinado a pô-lo em prática.
- Examine cada caso de uso sugerido: Ele está completo? Ou trata-se apenas de uma pequena parte de algo maior?
Perguntas a serem feitas:
- Cada ator deverá ter pelo menos um caso de uso. Se isso não ocorrer, poderá ser porque o ator é uma cópia (outro ator desempenha o mesmo papel) ou porque o ator realmente não é usuário do sistema. Nesses casos, se uma discussão acerca dos méritos de se manter o ator não suscitar nenhuma razão forte para mantê-lo, ele poderá ser removido.
Trabalhe com os casos de uso um por um e crie um flip chart para cada caso de uso. Desenhe uma elipse e escreva o nome do caso de uso na parte superior do gráfico. Pegue um lápis e peça ao grupo que escreva uma breve descrição do caso de uso. Esse tipo de descrição deve conter uma a três frases. Algumas vezes, é útil desenhar os atores relacionados ao caso de uso. Tente deixar metade do papel vazio para o próximo passo.
Durante esse trabalho, você descobrirá que alguns itens que todos achavam que estavam claros, na verdade, não estão nem um pouco claros. Consulte os requisitos identificados como recursos e necessidades principais dos usuários na Visão e tente descobrir se há quaisquer requisitos referentes a esse caso de uso.
Aparecerão novos casos de uso. Alguns desaparecerão. Afixe os papéis dos casos de uso nas paredes. Tente organizá-los com uma coluna por área funcional. (Não use os quadros brancos para isso - eles são necessários para a visão do sistema, os atores e os casos de uso.) Se não puder resolver as perguntas imediatamente, escreva-as em folhas do bloco de anotações autocolantes e coloque-as no caso de uso apropriado. Use uma cor para perguntas.
Quando todos os casos de uso estiverem representados graficamente em flip charts e apresentarem uma breve descrição, é o momento certo para o próximo modelo. Freqüentemente, é mais sensato reservar um tempo para debater se esses realmente são todos os casos de uso necessários.
O modelo criado até o momento poderá ser documentado no Rational Rose ou no Rational RequisitePro e gerado em um Relatório Sintético de Modelos de Casos de Uso.
A maneira para começar a escrever um caso de uso é estruturar o texto primeiramente. Não há nenhum sentido em sentar-se isoladamente e tentar estruturar o texto sem primeiramente obter informações dos envolvidos.
Trabalhe com os casos de uso um de cada vez. Anote as diferentes ações em ordem. Não tente imaginar como tudo parecerá usando estruturas codificadas, loops, declarações transitórias etc - trabalhe apenas com o fluxo básico de eventos e não se preocupe com as alternativas. Enumere os passos 1, 2, 3, 4, ... Para ajudar o grupo a compreender o nível necessário de detalhes, você poderá dizer que deseja de 5 a 10 passos no fluxo básico.
Após ter chegado a um acordo com o grupo em relação aos passos do fluxo básico de eventos, inspecione-o e identifique passos alternativos. Enumere os fluxos alternativos A1, A2, A3, A4, ...
Durante essa discussão, muitos problemas poderão ser levantados, muitos dos quais só serão resolvidos na fase de Análise e Design. Lembre-se de anotar todos os problemas juntamente com as suposições que precisarem ser feitas ao longo do caminho. Alguns problemas terão que ser resolvidos logo para que o Especificador de Requisitos possa detalhar o fluxo de eventos corretamente, e alguns deles são questões que você precisará certificar-se de que sejam resolvidas antes do início da fase de Análise e Design.
O que, no momento, estiver contido em cada flip chart deverá ser suficiente para que o Especificador de Requisitos possa detalhar o fluxo de eventos do caso de uso.
Durante essa sessão, haverá vários requisitos referentes ao sistema que talvez você não consiga capturar prontamente em um caso de uso. Normalmente, esses requisitos estão relacionados à funcionalidade, usabilidade, confiabilidade, desempenho e suportabilidade geral do sistema. Mantenha um flip chart separado para anotar essas informações. Elas se constituirão em uma base para as Especificações Suplementares.
Inspecione as Solicitações dos Principais Envolvidos mais importantes e cada recurso do documento de Visão e verifique se o modelo de casos de uso os abrange de forma apropriada. Discuta que necessidades ou requisitos dos usuários estão associados a que casos de uso.
Pegue o documento de Visão e leia o primeiro recurso. Escreva sua identificação em uma (ou mais se necessário) folha autocolante (use uma outra cor para facilitar a distinção entre requisitos e problemas). Coloque a anotação nos casos de uso que satisfazem a esse requisito. Posteriormente, você poderá inserir esses itens de rastreabilidade no repositório do RequisitePro.
Sempre há uma série de requisitos que não podem ser relacionados a nenhum caso de uso:
- Podem ser requisitos específicos que tenham que ser adiados até a fase de design - anote-os em um papel (requisitos de design).
- Podem ser requisitos gerais que não podem ser relacionados a nenhum caso de uso - insira-os na lista de Especificações Suplementares.
- Podem ser requisitos que foram esquecidos e que necessitam de novos casos de uso ou de mudanças nos casos de uso existente.
Passe algum tempo examinando a estrutura que foi elaborada: Há casos de uso que não apresentam requisitos? Por quê? Este caso de uso não é necessário? Ou esta funcionalidade foi esquecida pela pessoa que escreveu a especificação do requisito? (Geralmente é isso que ocorre.) Esta situação foi resolvida. Este cliente está ciente das necessidades desta funcionalidade? Ele deseja pagar para tê-la?
Copyright
(c) 1987 - 2001 Rational Software Corporation
| 
