Home
Qui
28
Ago

Requisitos, Casos de Uso e Desenvolvimento

Atenção, abrir em uma nova janela. PDFImprimirE-mail

Motivação

 

Claro que ninguém sai implementando um sistema sem fazer um levantamento da sua necessidade e aplicação, mas – diferentemente das ferramentas de programação – tendemos a investir pouco tempo neste levantamento, a empregar pouca ou nenhuma metodologia na captação, manutenção e na análise dos mesmos.  

 

Existe certa pressa em passar logo por esta etapa de entendimento do problema e começar logo a etapa de implementação.  De uma forma geral, o conceito é que o sistema se resolve no código e se os usuários e patrocinadores não começam a ver telas e coisas utilizáveis, nada está sendo feito.

 

Por outro lado, a indústria de IDEs, linguagens e frameworks sempre passa a mensagem de que suas ferramentas por si só permitirão que você resolva complexos problemas empresariais.  Os exemplos de soluções “drang-and-drop” ou “no code” suportados por estas ferramentas são muitos e bonitos, mas o fato é que jamais vi um problema do mundo real ser resolvido pela sua simples aplicação!

 

O fato é que, sem perceber, temos uma tendência a subestimar a importância do requisito no desenvolvimento de software.  

 

 

A Importância do Requisito

 

Não creio que haja dúvidas quanto à importância do requisito no desenvolvimento do que quer que seja, mas – sempre vale a pena lembrar, o Glossário de Terminologia da Engenharia de Software do IEEE define qualidade de software como sendo:

 

 

“O grau em que um sistema, componente ou processo atinge:

1) A Especificação de Requisitos;

2) As necessidades e expectativas dos clientes ou usuários”

 

 

Necessidades e expectativas dos clientes ou usuários nada mais são do que os requisitos em estado bruto, ou seja, na cabeça dos usuários.  Já a especificação de requisitos é o documento que torna objetivos e lapidados estes requisitos que muitas vezes são implícitos, ocultos e subjetivos.

 

Este é o principal fator crítico de sucesso de qualquer projeto: A capacidade de converter necessidades ocultas, implícitas e subjetivas em requisitos estabelecidos e documentados.

 

 

A Especificação de Requisitos

 

Muitas técnicas podem ser usadas no processo de levantamento (entrevistas, questionários, leituras de manuais, estágios, etc), e – naturalmente – cada analista deve ter a dimensão do que e quanto precisa para o que falta entender e passar para a próxima fase, mas a verdade é que o levantamento não contribuirá muito se não produzir uma lista de requisitos consistentes.  Melhor dizendo, se não produzir a lista dos requisitos consistentes que endereçam o problema!

 

O documento de Especificação de Requisitos é o documento que apontamos como possuindo esta lista.  Normalmente é um documento textual em que se procura transmitir o entendimento do problema e das necessidades para que possam ser validados e/ou autorizados por membros específicos da equipe de negócio.

 

Existem muitos formatos para uma especificação de requisitos, mas – em geral – ainda usamos textos corridos em linguagem comercial, o que nos leva a sofrer com as ambigüidades das  linguagens naturais, seja coloquial, culta ou comercial - especialmente porque projetos de software são sempre projetos com equipes multidisciplinares (pelo menos uma equipe de TI e uma do negócio), o que nos faz sucumbir pelos diferentes contextos culturais.

 

 

Especificação de Requisitos é um Processo

 

 

Especificação de requisitos é um processo que tem de ser vivido.  Não é apenas tirar dúvidas e escrever um documento, mas um processo de descoberta, entendimento, modelagem, validação e aprovação de cada necessidade.

 

Normalmente não vivemos isto como um processo, mas como uma tarefa pela qual passamos rapidamente para poder iniciar o desenho e codificação dos programas.  

 

Sempre, na melhor das intenções, a equipe de TI julga entender o que está sendo pedido enquanto que do lado da equipe de negócios, também na melhor das intenções, se julga ter dito todo o necessário para a realização da tarefa.  

 

Estes diferentes contextos culturais sempre vão gerar aquelas situações onde o óbvio de um se torna a surpresa do outro.  O fato é que a equipe de negócios vive o negócio e a de TI vive TI e – se o negócio não for TI – provavelmente isto não resultará no cumprimento das expectativas de ambos os lados.

 

Este é um engano que tem se repetido ao longo dos anos em muitos ambientes.  Sendo construtivo, não vamos falar em culpa, mas sem sombra de dúvidas a responsabilidade por esta situação é da TI.  Isto porque cabe à TI lidar com os problemas inerentes à sua atividade profissional, e este é um deles.  

 

A melhor forma de minimizar este problema é conhecida de longa data e consiste em garantir que a especificação de requisitos seja vivida como um processo, que tenha a participação ativa da equipe de negócios e que se apliquem ferramentas e metodologias apropriadas para sua execução.

 

 

Casos de Uso

 

 

Neste contexto, a Especificação por Casos de Uso é uma ferramenta para driblar as dificuldades de captação, identificação, descoberta, registro, validação e manutenção de requisitos de software.

 

Casos de Uso só o são quando elaborados em conformidade com um pequeno conjunto de conceitos.  Isto permite ao Caso de Uso se tornar um documento estruturado, sem – no entanto, se tornar um documento restrito à audiência técnica.  

 

Um caso de uso deve especificar as expectativas de comportamento de um sistema, quando este apóia uma e somente uma transação do negócio.

 

Essas expectativas de comportamento são divididas em cenários. Partindo do cenário principal de sucesso, que é aquele em que tudo transcorre conforme o esperado e deve corresponder à grande maioria das transações, chegando a cada cenário em que alguma barreira ou dificuldade pode provocar comportamentos específicos no sistema ou até mesmo impedir a realização da transação iniciada.

 

Desta forma, um caso de uso, a partir da modelagem do comportamento esperado do sistema, facilita a identificação de:

 

- Condições de exceção;

- Condições de erro;

- Regras de Negócio;

- Requisitos Funcionais;

- Requisitos não funcionais;

- Impactos em outras transações de negócio (outros casos de uso);

 

Agrupar toda esta informação com base em transações de negócio, que são claramente reconhecíveis e validáveis por parte dos membros da equipe de negócios, facilitar o acompanhamento da evolução das mesmas, durante todo o ciclo de vida do projeto e do sistema, são as principais características desta forma de elaborar e documentar requisitos de software.  

 

Com isso, os ambientes de desenvolvimento passam a contar com uma ferramenta que lhes confere memória sobre os requisitos que implementam.  Passam a poder acompanhar, ao longo do tempo, sua evolução e seus relacionamentos.

 

Do ponto de vista da programação, a UML oferece ferramentas que permitem derivar modelos arquiteturais do comportamento e da estrutura do sistema a partir das descrições contidas em um caso de uso, levando até ao projeto das classes, (que especificam a programação).  

 

Como as transações de negócio são especificadas, modeladas e programadas usando uma única unidade funcional – o caso de uso – está estabelecida a base para a rastreabilidade entre todas as etapas do projeto de desenvolvimento e – futuramente – da manutenção do sistema, o que por si só, é um grande fator de qualidade.

 

 

Utilização da Especificação por Casos de Uso

 

 

O conceito de “Caso de Uso” foi criado por Ivar Jacobson (um dos “três amigos” - como se chama o grupo que formulou a UML e o Processo Unificado), focando principalmente no Diagrama de Casos de Uso, muito útil para se obter uma visão geral do escopo do projeto, através do relacionamento dos Casos de Uso entre si e com seus Atores (participantes do mesmo).

 

Entretanto, a contribuição de Alistair Cockburn, foi a mais significativa, no sentido de se criar uma “Especificação por Casos de Uso”, uma vez que ele conseguiu estabelecer um padrão de escrita e formulação de casos de uso que englobam várias características, como regras de negócio, requisitos não-funcionais, etc, na forma de um acessível documento texto.

 

Dadas suas características, casos de uso são documentos que podem ter diferentes aplicações ao longo de todo o processo de desenvolvimento e manutenção de software, podendo ser úteis em diferentes contextos:

 

- Membros da Equipe de Negócios (patrocinadores, Stackeholders e Usuários): Os utilizam para validar a compreensão da equipe de TI, determinar prioridades e se certificarem do progresso do desenvolvimento do projeto;

 

- Gerentes de Projeto: Os utilizam como unidades funcionais para o planejamento de etapas, entregas e negociações, para monitorar e apropriar o esforço despendido, bem como para a gestão da mudança durante o projeto;

 

- Desenvolvedores: Os utilizam como especificação do comportamento que deve ser implementado no sistema;

 

- Analistas de Negócio e de Sistemas: Os utilizam como ferramenta para captação, análise, cognição e negociação, no processo de levantamento e especificação de requisitos;

 

- Analistas de Teste e Áreas de Qualidade: Os usam para elaborar os planos de teste e homologação do projeto;

 

- Equipes de Suporte e Manutenção: Os utilizam para efetuar a gestão da mudança durante as manutenções corretivas e evolutivas, durante o ciclo de vida do produto;

 

 

O processo unificado é orientado por casos de uso, o que quer dizer que caso de uso é a principal unidade de trabalho do processo.  As metodologias ágeis também se baseiam em casos de uso ou em alguma variação destes, fazendo deles também sua unidade fundamental de trabalho. 

 

Lembrando que cada caso de uso se refere a uma única transação de negócio, a gestão de projetos de software por casos de uso busca garantir o alinhamento do projeto ao negócio e às reais necessidades do usuário.  É também uma linguagem comum entre equipe de negócios e equipe de TI para avaliar o progresso do projeto.

 

 

Finalizado

 

No campo das idéias, ferramentas cognitivas são aquelas que nos ajudam na busca por conhecimento, na análise e na descoberta de novas informações e idéias.  Embora seja neste campo que a “batalha” do desenvolvimento de um software é travada, dá-se pouco enfoque às ferramentas cognitivas como instrumento na mitigação das dificuldades típicas deste empreendimento.

 

Neste cenário, apresentamos uma ferramenta de rara importância e mostramos os diversos papéis que ela pode assumir, apoiando a atividade de desenvolvimento de software.  E os problemas que podem ser resolvidos pela sua adoção.

 

Como este é um artigo introdutório sobre um assunto inesgotável, futuros artigos irão detalhar melhor as características e a forma de elaboração de um caso de uso.

 

De qualquer maneira, aqueles que desejem um guia para começar a especificar por casos de uso os seus projetos, o têm na forma do livro “Escrevendo Casos de Uso Eficazes”, de Alistair Cockburn, onde ele desenvolve toda a sua contribuição para esta metodologia, contribuição esta que já foi reconhecida publicamente pelos “três amigos”, nas edições mais recentes de seus livros sobre UML.

 

 

Sobre o Autor

 

Júlio Oliveira
Júlio Oliveira é Analista de Sistemas com Pós-graduação em Gerência de Projetos de Software pela PUC/Rio. Têm 20 anos de experiência em desenvolvimento de software corporativo, dos quais 10 anos, em seguradoras de médio e grande porte, atualmente, trabalha com consultoria de TI e desenvolvimento de web sites.
 

 

 



Adicionar este artigo ao seu site de favoritos ?
Digg! Reddit! Del.icio.us! Google! Live! Facebook! Technorati! StumbleUpon! MySpace! Netvouz! Mister-Wong! Diigo! Faves! Ask! DZone! Swik! Twitter! LinkedIn!

Comentários (1)
1 Seg, 14 de Setembro de 2009 13:37
celso bispo
adorei
pode mandar-me seu email
um abraco
Resposta do Administrador
Ter, 15 de Setembro de 2009 01:13
Administrator
Valeu pelo retorno, Celso.

Como o SMTP é bloqueado na minha hospedagem, não tenho uma página de contato. Mas se você quiser trocar e-mails, basta postar o seu em um comentário no site.

Não se preocupe, os posts não são publicados automaticamente, assim, caso seu post possua o seu e-mail, eu o removerei antes de publicar!

Abraço.

Adicionar comentário

Seu apelido/nome:
Comentário:

Menu Principal

Editar traduo para English (United Kingdom) Editar traduo para Português (Brasil)
Blog Sistemas e Cia