Do que trata o artigo

O objetivo deste artigo é apresentar a ferramenta Modelo de Caso de Uso, utilizada para a especificação de Requisitos Funcionais em sistemas diversos. Com base no Modelo de Caso de Uso, é apresentada a metodologia de estimativa de tempo e custo de desenvolvimento de software Pontos de Caso de Uso.

Para que serve

O processo de levantamento e análise de requisitos é fundamental para o sucesso de um projeto de desenvolvimento de software. De uma forma geral, é utilizada para que o gerente de projeto e sua equipe possam levantar as estimativas necessárias para definição de custo e cronograma de desenvolvimento.

Em que situação o tema é útil

Este artigo oferece subsídio para equipes de desenvolvimento que estejam protelando adotar Especificação de Casos de Uso como ferramenta para análise de Requisitos Funcionais, ou para aquelas equipes que já utilizam Especificação de Casos de Uso, mas não utilizam algum método de estimativa de custo e cronograma de desenvolvimento de software.

Resumo do DevMan

Um sistema é composto por tarefas a serem desenvolvidas e tarefas que venham suprir as necessidades de um cliente. Como identificar tais tarefas? Como estimar em quanto tempo uma, senão todas, tarefas serão entregues? Através da utilização de Casos de Usos é possível especificar requisitos, que são as tarefas a serem executadas, que um ator define. Esse ator é mais do que nosso cliente, é um conceito que envolve todos envolvidos na tarefa especificada. Neste artigo veremos como aplicar a técnica de Análise de Ponto de Casos de Uso para estimar o custo/prazo de um determinado caso de uso. Vamos conhecer os cálculos de apoio e variáveis envolvidas. A estimativa de prazo é um passo importante no desenvolvimento de software, pois só conseguimos gerenciar aquilo que é mensurado.

A fase de Levantamento e Análise de Requisitos pode ser considerada como sendo a pedra angular do processo de desenvolvimento de software, dada sua relevância, enquanto subsídio para as demais fases relacionadas às tarefas específicas de desenvolvimento (Análise e Design, Implementação, Teste, e principalmente Gerência de Projetos).

O processo de Levantamento e Análise de Requisitos tem como principais objetivos:

• Oferecer aos desenvolvedores do sistema uma melhor compreensão das necessidades dos Stakeholders;

• Definir os limites do sistema (escopo do sistema);

• Fornecer uma base para planejar o conteúdo técnico das etapas de desenvolvimento;

• Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema;

• Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários;

• Estabelecer e manter concordância com os clientes e outros Stakeholders sobre o que o sistema deve fazer.

Para atingir essas metas, é importante, antes de tudo, entender a definição e o escopo do problema a resolver com a solução a ser proposta. Os Stakeholders são identificados e os Requisitos dos Stakeholders são identificados, reunidos e analisados.

Nota do DevMan

Stakeholders são todos os envolvidos diretamente com o projeto, considerando aí desde os usuários finais até os responsáveis por aprovar ou não o desenvolvimento do projeto. Alguns autores incluem ainda como Stakeholders todas as pessoas envolvidas diretamente com a equipe de desenvolvimento.

Os requisitos de um sistema podem ser classificados como Funcionais e Não Funcionais. Requisitos Funcionais são aqueles que descrevem o comportamento do sistema e como o mesmo interage com os usuários ou mesmo com outros sistemas. Os Requisitos Não Funcionais são aqueles que descrevem as demais restrições do sistema a ser desenvolvido. De forma geral, podemos classificar os requisitos pelas seguintes categorias:t

Nota: Os termos em inglês foram mantidos pois os mesmos formam o acrônimo FURPS, muito utilizado por autores diversos para designar as categorias de requisitos.

Uma das ferramentas mais utilizadas hoje para especificar os Requisitos Funcionais de um sistema é o Modelo de Caso de Uso. Um Modelo de Caso de Uso é composto por dois tipos de documentos: o Diagrama de Caso de Uso e as Especificações de Caso de Uso.

O propósito principal desse artigo é apresentar os principais conceitos da especificação de requisitos com Casos de Uso e o uso de métricas de estimativa de projetos através de Análise de Pontos de Caso de Uso (Use Case Points – UCP).

Modelo de Caso de Uso

Um Caso de Uso define uma sequência de ações que uma funcionalidade do sistema desempenha, produzindo um resultado de valor observável e significativo para um Ator. Um Ator representa um usuário ou outro sistema que interage com o sistema em questão.

A especificação de requisitos com Casos de Uso muda o foco do processo de análise da função do sistema para a importância que o sistema tem para cada um dos Stakeholders envolvidos com o processo de desenvolvimento do software, representando o comportamento do sistema sem se preocupar com detalhes de implementação.

Cada Caso de Uso representa uma unidade coerente de uma funcionalidade provida por um sistema, descrevendo sequências de ações que o sistema realiza para apresentar um resultado de valor para um ator. Um Caso de Uso modela o diálogo entre o sistema e um ator em particular, descrevendo um fluxo de eventos completo e significativo do ponto de vista do ator. Contextualiza os requisitos encontrados disponibilizando os requisitos funcionais em sequências lógicas, ilustrando a real necessidade do sistema, além de ajudar a equipe de desenvolvimento e os Stakeholders a definir se todos os Requisitos Funcionais foram identificados e corretamente especificados.

Em geral, a especificação de um Caso de Uso deve ser de fácil compreensão por não utilizar terminologias tecnicistas, aplicando um linguajar que os Stakeholders compreendam e que esteja devidamente relacionado com o processo de negócio analisado. Uma especificação de Caso de Uso conta uma história concreta, representando um diálogo entre o sistema e o usuário final.

Identificando Atores e Casos de Uso

A correta definição e especificação dos casos de uso é de extrema importância para todo o projeto de desenvolvimento de software. A especificação dos requisitos (funcionais e não funcionais) está diretamente relacionada a todas as demais atividades do processo de desenvolvimento de software.

Observe na Tabela 1 como que os artefatos de requisitos estão vinculados às demais atividades de desenvolvimento de software.

Etapas do Ciclo de Vida

Relacionamento

Arquitetura

As atividades de requisitos oferecem como resultados artefatos que servem de subsídio para a especificação inicial da Arquitetura do sistema, bem como, para o refino e implementação da Arquitetura proposta;

...
Quer ler esse conteúdo completo? Tenha acesso completo