Caso de uso

O processo de identificação de requisitos na engenharia de software tem uma função fundamental no correto desenvolvimento do projeto, pode-se no entanto facilmente tornar num processo extenso e trabalhoso. Durante o desenvolvimento da área de Engenharia da computação iniciada em meados da década de 80, vários autores sugeriram diversas técnicas para um processo mais rápido e eficiente de levantamento e validação de requisitos de sistemas de software. Uma das técnicas mais populares é a utilização de Casos de Uso para descrever claramente todos os requisitos de um dado sistema, esta técnica foi proposta por Ivar Jacobson em sua metodologia de desenvolvimento de sistemas orientados a objetos OOSE, visando identificar os requisitos de um sistema. Foi aprimorada por várias outras personalidades do campo, como por exemplo, Alistair Cockburn. Posteriormente foi incorporado à linguagem UML, que define um diagrama para representar graficamente os casos de uso e seus relacionamentos (Diagrama de caso de uso).

O foco deste artigo é a utilização de casos de uso na engenharia de requisitos. Cada um chamado caso de uso descreve um cenário de possível interação com um utilizador ou um outro sistema. Devem ser os mais claros possíveis para que todos os eventuais leitores de diferentes campos e backgrounds possam entendê-los de igual modo, devendo-se assim evitar termos técnicos ou obscuros que possam dificultar a compreensão inequívoca da funcionalidade descrita. Cada caso de uso deve descrever somente uma funcionalidade ou objectivo do sistema. É então comum, para sistemas minimamente complexos, serem necessários muitos casos de uso para uma correta e completa descrição de todas as funcionalidades requeridas pelo sistema. Os casos de uso devem ser identificados através de nomes curtos que identifiquem a sua actividade inequivocamente, para tal são usualmente utilizadas as formas verbais activas. Para facilitar a visão geral do sistema é usual agregar casos de uso similares em pacotes e criar diagramas que ilustrem essa agregação e qual a iteração com outros sistemas ou utilizadores do sistema.

Cada caso de uso foca-se numa característica do sistema. Para a maioria dos projetos de software isto significa que múltiplos, talvez dezenas, de casos de uso são necessários para especificar completamente um novo sistema. O grau de conformidade de um projeto de software em particular pode influenciar o nível de detalhe requerido em cada caso de uso. É geralmente aceito que cada caso de uso seja curto o suficiente para ser implementado por um desenvolvedor de software num lançamento. A engenharia de requisitos consiste num processo onde são identificados todos os diferentes requisitos que um sistema de software deverá satisfazer quando se encontrar funcional. Este processo recorre a diferentes técnicas, algumas delas complementares entre si. O objetivo final é obter todos os requisitos idealizados para o sistema, possivelmente classificados por ordem de importância, descritos o mais claramente possível e devidamente validados pelos interessados ou stakeholders do sistema.

Há alguns cuidados a ter para ter a certeza que um caso de uso está correctamente compreendido. Habitualmente é adoptado um standard que requer o preenchimento de alguns campos relativos ao caso de uso de modo a facilitar o trabalho em grupo e a clareza do relacionamento entre vários casos de uso, e do caso de uso em relação aos actores e ao próprio sistema. Algumas das secções habitualmente utilizadas incluem:

A utilização de casos de uso é uma técnica relativamente recente, mais flexível, apoiada num formato novo e mais ágil para capturar requisitos de software que contrasta com a documentação extensiva e "monolítica" que tenta, mas falha em registrar todos os requisitos possíveis de um sistema antes deste começar a ser construído. Os casos de uso podem ser facilmente adicionados e removidos do projeto de software assim que as prioridades mudam. Os casos de uso podem também servir como base para estimar, escalonar e validar esforços. Uma razão porque os casos de uso se tornaram populares é que são fáceis de entender por pessoas da área de negócio, e assim provaram ser uma excelente ponte entre quem desenvolve o software e os usuários finais. Entre as vantagens da utilização no processo de engenharia de requisitos incluem-se:

No mínimo, cada caso de uso deveria ter um "cenário principal", ou o curso típico de eventos. O cenário principal é normalmente um conjunto de passos, por exemplo: O caso de uso representa uma atividade genérica que define um escopo (limite) de uma declaração de problema (texto que explica o que o sistema necessita). Exemplo: pagar faturas.

Os casos de uso podem conter cenários alternativos ou secundários que contêm variações do tema principal. Exceções, ou o que acontece quando as coisas não correm bem, podem também ser descritas.

Há também outros formatos, ou templates para documentos de casos de uso. Normalmente, os casos de uso têm uma secção de "sumário" que pode ser escrita preliminarmente durante o projeto de software para capturar a essência do cenário antes do corpo principal estar completo. Uma secção de "precondições" pode ser usada para conter as condições iniciais que foram assumidas antes do cenário ter começado.

Além destes atributos ainda podemos definir: prioridade, estado, pré-condições, pontos de extensão, identificador único, casos de uso usados, diagrama de atividade, diagrama de sequência, casos de uso subordinados, diagrama de colaboração e outros requerimentos.