A disciplina de Requisitos

O foco desta disciplina do Processo Unificado é trabalhar para construir o sistema certo. No inicio do primeiro ciclo de um projeto, ainda não se sabe exatamente qual o sistema a ser construído. O domínio é obscuro e a descrição dos requisitos pelos clientes pode vir acompanhada de ambigüidades, contradições e redundâncias.

A Engenharia de Requisitos, um dos braços da Engenharia de Software, é uma ciência destinada exclusivamente à compreensão das metas e das necessidades dos clientes em um projeto de desenvolvimento de software. As práticas, técnicas e ferramentas providas por esta ciência são grandes aliadas para um bom trabalho nesta disciplina.

Grupos como “The Requirements Engineering Specialist Group”, conferências internacionais e periódicos acadêmicos nos dão idéia da amplitude da Engenharia de Requisitos. Neste artigo vamos nos reter a discutir as atividades básicas executadas na disciplina. Em artigos futuros poderemos nos aprofundar neste tema tão complexo.

Um ponto interessante é perceber que ciências sociais, ciência cognitiva e relacionamento interpessoal são características importantes em um Engenheiro de Requisitos. Neste momento do processo, existe uma forte interação deste profissional com o cliente e é preciso preparo para identificar as ambigüidades, as contradições e as redundâncias que eventualmente aparecem.

Quatro artefatos são produzidos durante esta disciplina. São eles:

• Modelo de Domínio:


Este modelo é responsável por exibir os conceitos principais do domínio em que o software está inserido e como estes se relacionam.

É frequentemente representado por diagramas de classes conceituais da UML, ou seja, não são classes de projeto. Alguns conceitos são mantidos e tornam-se classes de projeto na elaboração da arquitetura em iterações futuras, porém, é comum que algumas classes sejam apenas conceituais e não participem do software efetivamente.

Este modelo nos permite compreender com mais clareza o cenário em que os clientes estão envolvidos. Também é utilizado como fonte de inspiração para a nomenclatura de classes em iterações futuras.


• Modelo de Casos de Uso:


Deve ser visto como uma guia para todo o processo de desenvolvimento, representa a força condutora. A idéia principal é identificar os requisitos funcionais do sistema.

Uma vez que um dos princípios fundamentais do Processo Unificado é ser dirigido por casos de uso, temos idéia do quão fundamental é este modelo.

É formado por pacotes de casos de uso, representando, cada um deles, um agrupamento lógico de diagramas de casos de uso da UML. Complementando o modelo, existem descrições textuais estruturadas para cada caso de uso. As descrições devem possuir, pelo menos, as seguintes informações: nome do caso de uso, ator principal, pré-condições, pós-condições, fluxo básico e fluxos alternativos de execução.


• Requisitos Não-Funcionais:


Em 1992, Robert Grady listou cinco grupos de categorização de requisitos. A lista foi denominada FURPS, acrônimo com o seguinte significado, conforme o original em inglês:


• Functionality: Requisitos funcionais.


• Usability: Requisitos de usabilidade, como recursos de ajuda e acessibilidade.


• Reliability: Requisitos de confiabilidade, como capacidade de recuperação após falha.


• Performance: Requisitos de desempenho, como tempo de resposta e disponibilidade.


• Supportability: Requisitos de suporte, como facilidade de manutenção/configuração e internacionalização.


Como os requisitos funcionais já são cobertos pelo Modelo de Casos de Uso, o documento de requisitos não-funcionais deve conter apenas os quatro grupos restantes, ou seja, uma lista URPS.


• Referências:


Este documento é apenas uma sugestão e pode ser formado por três seções: Glossário, Premissas e Referências bibliográficas e eletrônicas.

O Glossário descreve os principais termos a serem utilizados no sistema. Cria um padrão de nomenclatura a ser utilizado pela equipe de desenvolvimento nos diálogos e na elaboração dos diversos artefatos durante o projeto. Frequentemente é uma derivação do Modelo de Domínio.

As Premissas são considerações que justificam algumas características do sistema. A idéia é fornecer um histórico dos pensamentos e das discussões ocorridas durante o desenvolvimento. Esta seção deve auxiliar na manutenção do sistema.

As Referências biográficas apontam quais os livros que auxiliaram no desenvolvimento pela sua teoria. Analogamente, as Referências eletrônicas apontam as páginas da Internet que foram utilizadas em eventuais pesquisas.