Na Engenharia de Software, um caso de uso (do inglês use case) é um tipo de classificador representando uma unidade funcional coerente provida pelo sistema, subsistema, ou classe manifestada por sequências de mensagens intercambiáveis entre os sistemas e um ou mais atores.
Especificações de casos de uso são narrativas em texto, descrevendo a unidade funcional, e são amplamente utilizados para representar requisitos funcionais nos sistemas. Os diagramas de Casos de Uso são representações gráficas dos Casos de Uso e seus relacionamentos com outros casos de uso e atores. Neste diagrama um caso de uso é representado por uma elipse contendo, internamente, o nome do caso de uso e um ator é representado por um boneco palito. Opcionalmente o diagrama pode ter uma fronteira, que delimita o sistema, no qual os casos de usos estarão representados dentro da fronteira e os atores fora da mesma.
O apelo visual dessa ferramenta permite literalmente desenhar o processo de execução do negócio e visualizar a responsabilidade de cada participante, quando ele entrará em cena, qual será sua interação, a amplitude e a sequência em que o seu trabalho precisa ser realizado em relação às responsabilidades e tarefas dos demais integrantes do processo.
Um caso de uso representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema. Um caso de uso é uma unidade de um trabalho significante. Por exemplo: o "login para o sistema", "registrar no sistema" e "criar pedidos" são todos casos de uso. Cada caso de uso tem uma descrição da funcionalidade que será construída no sistema proposto. Um caso de uso pode "incluir" outra funcionalidade de caso de uso ou "estender" outro caso de uso com seu próprio comportamento.
Casos de uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho.
É importante notar que não descreve como o software deverá ser construído, mas sim como ele deverá se comportar quando estiver pronto. Um software frequentemente é um produto complexo, e sua descrição envolve a identificação e documentação de vários casos de uso, cada um deles descrevendo uma "fatia" do que o software ou uma de suas partes deverá oferecer.
Normalmente evitam o uso de termos técnicos, preferindo a linguagem do utilizador final, são empregados tanto por quem desenvolve o software quanto pelos utilizadores do software.
Origem 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).
Definição 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.
Os casos de uso nestes diagramas são usualmente representados por ovais com setas a indicar quais os utilizadores ou sistemas externos que interagem com eles.
A criação destes diagramas deve ser feita de uma maneira completamente fechada, ou seja, assumindo que o actor não tem conhecimento sobre o estado interno do sistema quando acessa uma dada funcionalidade, devendo as iterações ser descritas do ponto de vista externo. Esta forma de encarar a descrição de iteração simplifica a descrição dos requisitos e evita falsas assumpções sobre como a funcionalidade será implementada no sistema.
O procedimento mais seguido para a elaboração de diagramas de caso de uso, também habitualmente referidos como modelos de caso de uso, é o introduzido pelo UML. Embora sendo este o procedimento mais comum, é de notar que existem alternativas e que na prática o procedimento utilizado é o definido pelo manual de qualidade do projecto em curso que habitualmente deve ser previamente definido de acordo com as necessidades previstas do projecto, podendo vir a ser redefinido consoante alterações lógicas encontradas durante o processo.
O nível de detalhe da descrição do caso de uso dependerá sempre do nível de formalidade exigido pelo projecto e do estado actual de desenvolvimento. Em níveis iniciais pode-se assumir uma descrição mais breve e sucinta, em estados mais avançados será de esperar um maior detalhe e cuidado.
É de referir que um caso de uso bem elaborado não inclui somente um diagrama correcto e uma descrição clara. É habitual um caso de uso conter mais secções que ajudem na eficiência do processo de levantamento de requisitos, no próprio workflow de trabalho e na facilidade de imediata compreensão e rápida leitura do caso de uso por elementos estranhos à sua criação.
Também importante para garantir a usabilidade específica do caso de uso é o instrumento entre os diversos casos de uso do projecto. É imperativo elaborar casos de uso que tanto facilitem o acesso à vista global do sistema, como explicitem completamente todos os pormenores de todas as funcionalidades requisitadas.
Área do Caso de Uso 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.
A clareza com que os requisitos são descritos e a sua abrangência que é idealizada pelos stakeholders é a máxima prioridade do processo tendo em vista não só a necessidade de transição do conhecimento dos requisitos do sistema tanto para os programadores que o irão implementar quanto para os utilizadores que dele farão uso, mas também para garantir que todo o conteúdo pretendido esteja identificado antes do processo de implementação começar, de modo a facilitar a arquitetura e planejamento de implementação da solução, evitando retrabalho.
Entre as várias técnicas auxiliares à tarefa de levantamento de requisitos, as mais reconhecidas e aconselhadas são:
Identificação de stakeholders: Determinação clara de quem irá usar o sistema e de quem o projetou, discernindo quais os objetivos iniciais por trás da ideia, de modo a poder entender o que esperam que o sistema cumpra. Entrevistas com stakeholders do sistema: Consiste em efetuar entrevistas com os utilizadores e visionários do sistema tentando obter uma ideia das várias necessidades que o sistema deve satisfazer. Workshops de requisitos: Sessões de grupo com os utilizadores e visionários do sistema promovendo o debate e discussão de ideias sobre o sistema a desenvolver. Listagem contratual de requisitos: Consiste em elaborar uma listagem contendo todas as necessidades que o sistema deverá satisfazer. Prototipagem: Criação, apresentação e debate de modelos de interação não funcionais que ajudem a ilustrar como o sistema deverá se comportar, permitindo assim obter feedback mais detalhado dos stakeholders sobre o sistema. Diagrama de Caso de Uso: Descreve a funcionalidade proposta para o novo sistema. Expansão de Diagrama de Casos de uso: Consiste na explicitação de todas as diferentes funcionalidades do sistema, que permitirá inferir e identificar mais claramente outras necessidades.
Diagramas de casos de uso
Muitas pessoas introduziram os casos de uso via UML, que define uma notação gráfica para representar os casos de uso. O UML não define padrões para o formato escrito objetivando descrever casos de uso, e assim muitas pessoas compreendem erroneamente que a notação gráfica define a natureza do caso de uso; contudo a notação gráfica pode dar a visão geral mais simples de um caso de uso ou de um conjunto destes casos.
O diagrama de casos de uso fornece um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível da funcionalidade.
Seções habituais nos Casos de Uso 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:
Nome: Identificador inequívoco do caso de uso, deve ser escrito em formato de verbo/substantivo e ser suficiente para o utilizador perceber a que se refere o caso de uso. Iteração ou estado de desenvolvimento: Descrição do estado actual do caso de uso à medida que este vai evoluindo. Sumário: Curto resumo do caso de uso. Pré-condições: Listagem das condições que se devem verificar quando o utilizador inicia este caso de uso. Não incluem triggers. Triggers: Eventos que ocorrem dando início ao caso de uso. Podem ser externos, temporais ou internos. Linha de Eventos: Esta secção descreve o curso de eventos ou cenário que se realiza. Usualmente é descrito através de uma sequência de eventos numerados. Percursos Alternativos: Descrição de percursos alternativos à linha de eventos básica. Pós-condições: Descrição do estado do sistema após a execução do caso de uso Regras de negócio: Secção reservada para informação adicional relativa à política da empresa ou restrições impostas pelo tipo de negócio. Notas: Informação adicional relativamente ao caso de uso, não coberta pelas secções anteriores. Autor e data: Listagem dos autores e datas das várias versões revistas.
Benefícios e Vantagens do Caso de Uso