Resumo Cap 6 do Livro UML for the IT Business Analyst (Storyboarding the User’s Experience)

Requisitos de Software

---

Resumo Cap 6 do Livro UML for the IT™ Business Analyst (Storyboarding the User’s Experience)

A fase de descoberta do projeto é uma das tarefas que mais exige do time de análise de negócio. O objetivo de analisar os requisitos, os quais têm seu auge nessa fase, é de descobrir e documentar os requisitos do sistema proposto.

A fase de descobertas envolve alguns passos:

• Descoberta;

• Executar análise comportamental;

• Descrever casos de uso do sistema (modelo de descrição de casos de uso); [Foco deste capítulo].
• Descrever estados de comportamento (diagrama de máquina de estado);

• Executar análise estrutural (diagrama de classes, modelos de dados e objetos);
• Especificar testes (plano de testes, tabelas de decisão);
• Especificar plano de implementação (plano de implementação);
• Definir baseline para o desenvolvimento (BRD/Descoberta).

Ao descrever os casos de uso do sistema, caso haja alguma primeira mudança,  deve-se revisar a lista dos casos de uso do sistema e se necessidades forem mudadas ou surge alguma nova informação, é preciso atualizar o diagrama de casos de uso e relatar o texto no BRD (Business Requirement Document). Uma vez estabelecida uma lista com os casos de uso do sistema, o próximo passo é investigar e documentar cada uma completamente.

Descrever os casos de uso gera alguns entregáveis:

• O template do BRD contém uma seção para casos de uso do sistema,

que será atualizada.

• O BRD tem uma seção chamada Descrição dos casos de uso do sistema. Para cada caso de uso que aparece no diagrama de casos de uso do  sistema, uma descrição é adicionada que inclui um modelo completo de diagramas de casos de uso. O texto do documento pode ser aumentado com os seguintes:

• Diagrama de atividades;
• Tabelas de decisão;
• Árvores de decisão;
• Outros artefatos relacionados que contenham documentação suplementar.

O template de casos de uso proposto é bastante geral e com regras que podem ser úteis ou não, de modo que ao se decidir usar um template, deve-se adequá-lo à sua própria realidade ou empresa. O princípio por trás do modelo apresentado neste capítulo é descrever o fluxo de trabalho usando um estilo narrativo simples que evita lógica complexa.

O truque para manter as coisas simples é lidar com variações em uma área separada do documento ao invés de em uma seção abrangente. Primeiro, você documenta uma interação normal e típica em uma seção chamada "Fluxo Básico". Em seguida, descreve cenários de sucesso alternativos em uma seção "Fluxos Alternativos". Finalmente, você descreve o tratamento de erros em uma seção "Fluxos excepcionais".

Documentando o Fluxo Básico: O fluxo básico descreve a maneira mais comum que o caso de uso é executado com êxito. (Algumas pessoas o chamam de "cenário feliz.") Ele lê como uma narrativa direta: "O usuário faz ...; O sistema faz ... "Como regra geral, o fluxo básico não deve listar nenhuma condição, já que as seções subsequentes tratam de todos os erros e alternativas. Para manter a documentação consistente, use uma diretriz de estilo em toda a sua empresa para escrever requisitos de casos de uso.

Documentando fluxos alternativos: Documente cada cenário não coberto no fluxo básico como um fluxo alternativo ou como um fluxo de exceção. Um fluxo alternativo é uma variação que não leva ao abandono do objetivo do usuário; Um fluxo de exceção envolve um erro não recuperável. Se sua equipe tiver problemas para decidir se deve listar um cenário na seção "Fluxo Alternativo" ou "Fluxo de Exceção", mescle as duas seções em uma e liste ambos os tipos de fluxo nela.

Documentando fluxos de exceção: Liste cada condição de erro que leva ao abandono do objetivo do usuário na seção "Fluxos de exceção". Fluxos de exceção típicos incluem o cancelamento de uma transação pelo usuário e erros do sistema que forçam uma transação a ser cancelada. As regras de documentação são as mesmas que para os fluxos alternativos, exceto que muitas vezes não há ponto de convergência, uma vez que a meta é abandonada. Nesse caso, a última linha do fluxo deve ler, "O caso de uso termina em falha."

Diagrama de atividades para casos de uso do sistema: Caso os fluxos se conectem de uma maneira complexa, é interessante adicionar um diagrama de atividades como complemento das descrições de casos de uso para assim deixar claro como todos os fluxos se encaixam. O modelo contém um número de seções que apontam o leitor para outros artefatos relacionados com casos de uso, o qual esses artefatos que irão ter os detalhes. Com isso, se ocorrer alguma mudança, só será necessário mudar a documentação em um lugar. São exemplos de artefatos que complementam os casos de uso:

• Tabelas de decisão: descreve as respostas do sistema em um número de fatores inter-relacionados, mas se cada fator pode ser olhado separadamente é melhor não a usar. Para complementá-la, temos os conceitos subjacentes, onde ao invés de explicar a lógica que está sob uma decisão, é melhor listar todas as situações possíveis e documentar como os sistemas a tratam.
• Árvores de decisão: é uma alternativa a tabela de decisão, mas ao invés de uma tabela, utiliza-se uma imagem para representar o comportamento do sistema. Para criar uma árvore de decisão, siga os seguintes passos:

• Listar as condições desde o topo;
• Listar ações para o lado direito do desenho;
• Desenhar um ponto de origem no canto esquerdo do meio da página;
• A partir desse ponto, desenhar um galho para cada valor na primeira condição;
• A partir de cada um desses pontos, desenhar um galho para cada valor da próxima condição;
• Continuar até chegar na última condição;
• Conectar cada ponta final na ação apropriada;
• Para evitar que muitas linhas se cruzem, é interessante listar as mesmas ações separadamente para cada vez que elas são necessárias.

Caso uma condição de entrada que contribua para uma decisão possa ser calculada uma por uma, é melhor utilizar uma tabela de condição/resposta ao invés de uma tabela ou árvore de decisão.

Regras de negócio fora dessas expressadas nas tabelas representam outro tipo de documentação que deve ser puxada a partir de casos de uso próprios e referenciados em uma seção dedicada. Regras de negócio são regras da área dos negócios que restringem o processo do negócio e essas regras são documentadas separadamente, pois elas se confundem com o fluxo dos casos de uso e às vezes é aplicado a mais de um caso de uso do sistema.