Pontos importantes na revisão de Casos de Uso
Muitas metodologias são baseadas em casos de uso. Casos de uso são muito eficientes na representação da voz do usuário. Quando estamos desenvolvendo ou revisando Casos de Uso devemos ter certas questões em mente para que o desenvolvimento/revisão ocorra de maneira efetiva.
Vou abordar algumas questões quais eu julgo importantes na revisão de Casos de uso, como já disse antes essas questões são uteis pra o desenvolvimento de requisitos do usuário (Casos de Uso) e para a revisão dos mesmos. Confira as questões que serão abordadas:
Casos de uso são simples, e representam a essência de interação entre usuários e sistemas, além desse poderoso recurso prover uma base para os processos realizarem a rastreabilidade de requisitos.
Modelo 4 + 1 Utilizado no RUP
Como você pode ver na figura acima esse é o modelo do RUP. Aqui nos percebemos que os casos de uso além de agregarem valor através de interação de Atores na perceptiva do usuário os casos de uso agregam mais quatro visões: Lógica, Processo, Física e Desenvolvimento.
Visão Lógica: Mostra o comportamento do requisito e como o sistema é decomposto em um conjunto de abstrações que irão tratar este requisito. Essa visão também poderia ser mostrada através dos diagramas da UML: Classe, Seqüencia e Colaboração. A visão lógica é estática, logo se você deseja ver uma visão dinâmica deve usar os diagramas de Seqüencia ou Colaboração.
Visão Processo: Esta visão mostra descreve como são os processos do sistema e como eles se comunicam. Esta visão é mais utilizada quando existem processamentos em paralelo através de Threads. Na UML essa visão pode ser contemplada com diagramas de Atividades.
Visão Física: Mostra como o sistema será instalado fisicamente bem como a topologia de rede e clusterização se existir. Essa visão é valida para a representação de como requisitos não-funcionais foram tratados. Na UML é possível fazer essa representação através de uma diagrama de Deploy.
Visão Desenvolvimento: Esta visão é utilizada para a descrição dos módulos do sistema. Você descreve essa visão na UML através do diagrama de Pacotes. Módulos, Sub-Sistemas e classes são consideradas nessa visão. Se você utiliza o modelo arquitetural em camadas é nessa visão que ele será especificado.
Agora que já vimos um pouco mais do valor que os Casos de Uso nos proporcionam, vamos ver as questões pertinentes a revisão e desenvolvimento.
Forma de descrição de Casos de Uso
Conforme eu disse nesse post.Casos de uso em forma textual são Ok. Você deve tomar cuidado para não descrever os casos de uso de forma passiva, ou seja, assim: "O sistema deve..." isso parece muito mais com um requisito não funcional do que com um requisito do usuário. O correto é você sempre utilizar a forma ativa.
Descrição e Utilização dos Atores
Você deve ter certeza de que TODOS os atores foram descritos. Uma descrição sucinta de 3 a 5 linhas é o suficiente. Como o caso de uso tem um papel fundamental da contextualização, devem sempre descrever os atores, por mais obvio que isso pareça.
Existe outro porem, devemos lembrar que os casos de uso são a base para os casos de testes, logo uma não descrição dos atores pode gerar problemas na horas de criar os casos de testes.
Nessa questão ainda, não são permitidos atores declarados que não participam do caso de uso. Se você tiver atores que não estão sendo utilizados remova-os. O propósito do caos de uso é agregar valor com as interações.
Se você tem um caso de uso sem atores esse é outro problema. Não podemos deixar casos de uso sem atores, isso pode significar que algum requisitos foi mal elicitado ou até mesmo que existem requisitos que estão faltando.
Termos do Glossário
Todos os termos do negócio que são referenciados no caos de uso devem estar no glossário. A partir de um determinado tempo os analistas de requisitos ficam com o conhecimento do negocio de forma tácita. Devemos lembrar que os desenvolvedores, arquitetos e testadores não possuem o mesmo conhecimento e é fundamental a escrita desses termos no glossário.
Lembre-se de que quando você entende o que está fazendo, no caso construindo, você tem muito mais chances de atender as necessidades do cliente. tendo um glossário com os termos do negócio ajuda esse entendimento. O glossário é uma poderosa ferramenta contra a Ambigüidade e prove um vocabulário comum através dos stakeholders e do time.
Levantamento de cenários alternativos (nenhum ou a falta de)
Todo caso de uso tem um Happy Path, também conhecido como cenário principal ou cenário básico. Como o próprio nome já diz, é o caminho feliz, logo os outros cenários são os caminhos tristes :). De fato os cenários alternativos é que contem as regras mais complicadas de negócio na maioria das vezes.
Com tudo isso fica claro que devemos ter certeza que não esquecemos de mapear nenhum cenário alternativo. Existe uma tendência das pessoas mascararem os cenários de exceção. Foque atento a isso e procure instigar se todos os cenários de exceção foram mapeados.
Atenção: Casos de uso sem cenários são um erro grave. Normalmente quando isso acontece é algum acobertamento de outro caso de uso que ainda não foi mapeado no processo de elicitação.
Reflexo do Domínio
Os casos de uso devem refletir o domínio que estão inseridos. Quando não existe esse link de algum caso de uso com o domínio pode significar que existem algum inconsistência. Normalmente um problema de comunicação ou um caso de uso não mapeado.
É mandatário que os casos de uso usem os termos de negocio. Quanto mais semelhante ao negocio melhor.
Contextualização
O caso de uso é por natureza contextualizador. Mas isso não acontece sozinho, você deve realizar isso através de termos no glossaário, atores bem descritos e
Deve ser avaliado a correlação de casos de uso similares a fim de verificar o particionamento, é possível que esses casos de uso sejam o mesmo. A descrição do caso de uso também pode contribuir nesse processo.
Entender o contexto em que o caso de uso está inserido ajuda a evitar erros de comunicação e mal entendidos na hora de codificar e testar. Um caso de uso bem contextualizado ajuda a arquitetura a entender o sistema e criar sua base arquitetural.
Nível de Abstração
Esta questão tem muito para que se discutir. Vou tentar resumir a questão o máximo possível. Aqui vale a regra do 8 e 80. Não podemos ir tanto aos extremos.
Um caso de uso que descrever o sistema em nível de variáveis e laços de repetições é totalmente inútil. De nada serve programar em português através do MS Word. Além de limitar as capacidades criativas do desenvolvedor isso se torna impossível de se manter através do tempo.
Também não podemos ter um caso de uso tão abstrato que chego ao ponto de não dizer absolutamente nada. Aqui precisamos ter muito bom senso. Existem momentos em que os casos de uso serão mais abstratos e outros que não.
Podemos trabalhar os níveis de abstração em conjunto com a questão da contextualização e com isso tirar mais proveito dos casos de uso. Por exemplo se em uma caso de uso você encontra algo do tipo (imagine o site da Amazon):
"O Web Site irá mostrar as informações do livro"
Isso é péssimo, é tão abstrato que não diz absolutamente nada. Facilmente nos vem a cabeça questões como:
" O sistema de Livro On Line irá mostrar os detalhes do livro selecionado pelo usuário logado. As informações devem ser dispostas em forma de tabela. O sistema deve mostrar apenas o nome do livro, o autor e a editora"
Notaram a diferença?
Assim estamos linkando com o domínio. Estamos contextualizando. Esta questão é fundamental para o uso de práticas mais avanças de design como o DDD.
Utilização de Protótipos
Casos de uso não devem vir sozinho. É uma boa idéias utiliza-los com protótipos, os protótipos podem ser feitos de maneira ágil com uma folha de papel. Eles são uma excelente opção para validar o entendimento do usuário sobre o sistema e descobrir requisitos de usabilidade do sistema.
Use os protótipos e o feedback que eles irão proporcionar para refinar os seus casos de uso.
A Linha tênue do Design com Requisitos
Requisitos e Design são duas disciplinas que andam muito próximas. O projetista deve trabalhar muito próximo do analista de requisitos. Objetos de domínio devem ser refletidos pelos casos de uso. O analista de requisitos e projetista devem se certificar que estão falando a mesma língua. Objetos de domínio que aparecem no Design devem ser referenciados no caso de uso.
Caso isso não aconteça você pode estar com problemas de comunicação e no pior caso o seu design não está refletindo o modelo de analise.
Tamanho dos Casos de Uso (Muitas Páginas)
Atenção. Casos de uso muito extensos. Casos de uso com mais de 4 páginas não são necessários. Além de serem prejudiciais pra a leitura eles podem estar sendo inchados. Muitas vezes pode ser que você está juntando casos de uso que não eram para serem juntados.
Seja pragmático para separar ou juntar casos de uso semelhantes. A descrição dos casos de uso pode ajudar nesta tarefa.
Limitações dos Casos de Uso
Casos de uso não são perfeitos. Basicamente não podemos especificar requisitos não-funcionais com casos de uso. Para isso poderíamos utilizar as especificações suplementares do RUP ou até mesmo uma tabela de evento resposta.
Outro problema que existe é em relação ao nível de abstração/detalhe dependendo do caso de uso esses nível podem variar francamente, isso prejudica a realização de estimativas com use case points ou com técnicas de julgamento em grupo.
Até a próxima, :)
Vou abordar algumas questões quais eu julgo importantes na revisão de Casos de uso, como já disse antes essas questões são uteis pra o desenvolvimento de requisitos do usuário (Casos de Uso) e para a revisão dos mesmos. Confira as questões que serão abordadas:
- Forma de descrição de Casos de Uso
- Descrição e Utilização dos Atores
- Termos do Glossário
- Levantamento de cenários alternativos (nenhum ou a falta de)
- Reflexo do Domínio
- Contextualização
- Nível de Abstração
- Utilização de Protótipos
- A Linha tênue do Design com Requisitos
- Tamanho dos Casos de Uso (Muitas Páginas)
- Limitações dos Casos de Uso
Casos de uso são simples, e representam a essência de interação entre usuários e sistemas, além desse poderoso recurso prover uma base para os processos realizarem a rastreabilidade de requisitos.
Modelo 4 + 1 Utilizado no RUP
Como você pode ver na figura acima esse é o modelo do RUP. Aqui nos percebemos que os casos de uso além de agregarem valor através de interação de Atores na perceptiva do usuário os casos de uso agregam mais quatro visões: Lógica, Processo, Física e Desenvolvimento.
Visão Lógica: Mostra o comportamento do requisito e como o sistema é decomposto em um conjunto de abstrações que irão tratar este requisito. Essa visão também poderia ser mostrada através dos diagramas da UML: Classe, Seqüencia e Colaboração. A visão lógica é estática, logo se você deseja ver uma visão dinâmica deve usar os diagramas de Seqüencia ou Colaboração.
Visão Processo: Esta visão mostra descreve como são os processos do sistema e como eles se comunicam. Esta visão é mais utilizada quando existem processamentos em paralelo através de Threads. Na UML essa visão pode ser contemplada com diagramas de Atividades.
Visão Física: Mostra como o sistema será instalado fisicamente bem como a topologia de rede e clusterização se existir. Essa visão é valida para a representação de como requisitos não-funcionais foram tratados. Na UML é possível fazer essa representação através de uma diagrama de Deploy.
Visão Desenvolvimento: Esta visão é utilizada para a descrição dos módulos do sistema. Você descreve essa visão na UML através do diagrama de Pacotes. Módulos, Sub-Sistemas e classes são consideradas nessa visão. Se você utiliza o modelo arquitetural em camadas é nessa visão que ele será especificado.
Agora que já vimos um pouco mais do valor que os Casos de Uso nos proporcionam, vamos ver as questões pertinentes a revisão e desenvolvimento.
Forma de descrição de Casos de Uso
Conforme eu disse nesse post.Casos de uso em forma textual são Ok. Você deve tomar cuidado para não descrever os casos de uso de forma passiva, ou seja, assim: "O sistema deve..." isso parece muito mais com um requisito não funcional do que com um requisito do usuário. O correto é você sempre utilizar a forma ativa.
Descrição e Utilização dos Atores
Você deve ter certeza de que TODOS os atores foram descritos. Uma descrição sucinta de 3 a 5 linhas é o suficiente. Como o caso de uso tem um papel fundamental da contextualização, devem sempre descrever os atores, por mais obvio que isso pareça.
Existe outro porem, devemos lembrar que os casos de uso são a base para os casos de testes, logo uma não descrição dos atores pode gerar problemas na horas de criar os casos de testes.
Nessa questão ainda, não são permitidos atores declarados que não participam do caso de uso. Se você tiver atores que não estão sendo utilizados remova-os. O propósito do caos de uso é agregar valor com as interações.
Se você tem um caso de uso sem atores esse é outro problema. Não podemos deixar casos de uso sem atores, isso pode significar que algum requisitos foi mal elicitado ou até mesmo que existem requisitos que estão faltando.
Termos do Glossário
Todos os termos do negócio que são referenciados no caos de uso devem estar no glossário. A partir de um determinado tempo os analistas de requisitos ficam com o conhecimento do negocio de forma tácita. Devemos lembrar que os desenvolvedores, arquitetos e testadores não possuem o mesmo conhecimento e é fundamental a escrita desses termos no glossário.
Lembre-se de que quando você entende o que está fazendo, no caso construindo, você tem muito mais chances de atender as necessidades do cliente. tendo um glossário com os termos do negócio ajuda esse entendimento. O glossário é uma poderosa ferramenta contra a Ambigüidade e prove um vocabulário comum através dos stakeholders e do time.
Levantamento de cenários alternativos (nenhum ou a falta de)
Todo caso de uso tem um Happy Path, também conhecido como cenário principal ou cenário básico. Como o próprio nome já diz, é o caminho feliz, logo os outros cenários são os caminhos tristes :). De fato os cenários alternativos é que contem as regras mais complicadas de negócio na maioria das vezes.
Com tudo isso fica claro que devemos ter certeza que não esquecemos de mapear nenhum cenário alternativo. Existe uma tendência das pessoas mascararem os cenários de exceção. Foque atento a isso e procure instigar se todos os cenários de exceção foram mapeados.
Atenção: Casos de uso sem cenários são um erro grave. Normalmente quando isso acontece é algum acobertamento de outro caso de uso que ainda não foi mapeado no processo de elicitação.
Reflexo do Domínio
Os casos de uso devem refletir o domínio que estão inseridos. Quando não existe esse link de algum caso de uso com o domínio pode significar que existem algum inconsistência. Normalmente um problema de comunicação ou um caso de uso não mapeado.
É mandatário que os casos de uso usem os termos de negocio. Quanto mais semelhante ao negocio melhor.
Contextualização
O caso de uso é por natureza contextualizador. Mas isso não acontece sozinho, você deve realizar isso através de termos no glossaário, atores bem descritos e
Deve ser avaliado a correlação de casos de uso similares a fim de verificar o particionamento, é possível que esses casos de uso sejam o mesmo. A descrição do caso de uso também pode contribuir nesse processo.
Entender o contexto em que o caso de uso está inserido ajuda a evitar erros de comunicação e mal entendidos na hora de codificar e testar. Um caso de uso bem contextualizado ajuda a arquitetura a entender o sistema e criar sua base arquitetural.
Nível de Abstração
Esta questão tem muito para que se discutir. Vou tentar resumir a questão o máximo possível. Aqui vale a regra do 8 e 80. Não podemos ir tanto aos extremos.
Um caso de uso que descrever o sistema em nível de variáveis e laços de repetições é totalmente inútil. De nada serve programar em português através do MS Word. Além de limitar as capacidades criativas do desenvolvedor isso se torna impossível de se manter através do tempo.
Também não podemos ter um caso de uso tão abstrato que chego ao ponto de não dizer absolutamente nada. Aqui precisamos ter muito bom senso. Existem momentos em que os casos de uso serão mais abstratos e outros que não.
Podemos trabalhar os níveis de abstração em conjunto com a questão da contextualização e com isso tirar mais proveito dos casos de uso. Por exemplo se em uma caso de uso você encontra algo do tipo (imagine o site da Amazon):
"O Web Site irá mostrar as informações do livro"
Isso é péssimo, é tão abstrato que não diz absolutamente nada. Facilmente nos vem a cabeça questões como:
- Que Web Site?
- Quais Informações?
- De que livro?
- De que maneira?
- Por quanto tempo?
- Para quais usuários?
" O sistema de Livro On Line irá mostrar os detalhes do livro selecionado pelo usuário logado. As informações devem ser dispostas em forma de tabela. O sistema deve mostrar apenas o nome do livro, o autor e a editora"
Notaram a diferença?
Assim estamos linkando com o domínio. Estamos contextualizando. Esta questão é fundamental para o uso de práticas mais avanças de design como o DDD.
Utilização de Protótipos
Casos de uso não devem vir sozinho. É uma boa idéias utiliza-los com protótipos, os protótipos podem ser feitos de maneira ágil com uma folha de papel. Eles são uma excelente opção para validar o entendimento do usuário sobre o sistema e descobrir requisitos de usabilidade do sistema.
Use os protótipos e o feedback que eles irão proporcionar para refinar os seus casos de uso.
A Linha tênue do Design com Requisitos
Requisitos e Design são duas disciplinas que andam muito próximas. O projetista deve trabalhar muito próximo do analista de requisitos. Objetos de domínio devem ser refletidos pelos casos de uso. O analista de requisitos e projetista devem se certificar que estão falando a mesma língua. Objetos de domínio que aparecem no Design devem ser referenciados no caso de uso.
Caso isso não aconteça você pode estar com problemas de comunicação e no pior caso o seu design não está refletindo o modelo de analise.
Tamanho dos Casos de Uso (Muitas Páginas)
Atenção. Casos de uso muito extensos. Casos de uso com mais de 4 páginas não são necessários. Além de serem prejudiciais pra a leitura eles podem estar sendo inchados. Muitas vezes pode ser que você está juntando casos de uso que não eram para serem juntados.
Seja pragmático para separar ou juntar casos de uso semelhantes. A descrição dos casos de uso pode ajudar nesta tarefa.
Limitações dos Casos de Uso
Casos de uso não são perfeitos. Basicamente não podemos especificar requisitos não-funcionais com casos de uso. Para isso poderíamos utilizar as especificações suplementares do RUP ou até mesmo uma tabela de evento resposta.
Outro problema que existe é em relação ao nível de abstração/detalhe dependendo do caso de uso esses nível podem variar francamente, isso prejudica a realização de estimativas com use case points ou com técnicas de julgamento em grupo.
Até a próxima, :)
