Uso de cenários para especificação de requisitos de qualidade e avaliação de arquitetura

A Engenharia de Software está divida em fases comuns a todos os processos de software. Durante a especificação do sistema, as necessidades do cliente são identificadas e classificadas por meio de requisitos. Os requisitos não funcionais - ou de qualidade - estão relacionados diretamente aos atributos de qualidade, os quais possuem diversas classificações e definições e, também, impactam diretamente na arquitetura do sistema. Uma poderosa ferramenta para descrição de requisitos de qualidade é por meio de cenários - que são sequências de eventos que ocorrem durante uma utilização particular do sistema. A partir dos cenários, há diversos métodos utilizados para avaliar o atendimento dos requisitos pelo sistema. Dentre eles, destaca-se o ATAM (Architecture Tradeoff Analysis Method), que realiza avaliações arquiteturais de sistemas já existentes ou auxilia na definição arquitetural de um novo sistema. O ATAM é utilizado quando há tradeoff entre atributos de qualidade conflitantes como, por exemplo, segurança e usabilidade.

Neste contexto, este artigo apresenta conceitos e classificações de requisitos e mostra o relacionamento destes com a arquitetura de um sistema. Ainda, mostra a utilização de cenários para a definição e priorização de requisitos de qualidade e como o atendimento desses cenários pelo sistema pode ser avaliado utilizando o ATAM.

Classificação de Requisitos

O SWEBOK (Software Engineering Body of Knowledge) define requisito de software como uma propriedade que deve ser exibida com o propósito de solucionar algum problema no mundo real. Assim, cabe à Engenharia de Requisitos identificar, verificar e avaliar as necessidades do cliente, resultando no conjunto de requisitos do software. O desafio básico desta atividade é encontrar, comunicar e registrar o que é realmente necessário, explicitando de forma clara para o cliente e os membros da equipe de desenvolvimento. Vale salientar que falhas durante a elicitação de requisitos, geralmente, serão refletidas em todo o projeto, podendo causar desde pequenos atrasos no cronograma até o cancelamento do projeto.

Uma discussão levantada por Davis (1993) revela dois níveis de abstração para o documento de requisitos. No primeiro nível, segundo o autor, “o cliente define suas necessidades de maneira suficientemente abstrata para que uma solução não seja predefinida”. Desta forma, os possíveis fornecedores podem propor soluções diferentes com base na especificação fornecida. Uma vez selecionado o fornecedor, este definirá, de forma detalhada, o sistema para que seja possível a avaliação por parte do cliente - constituindo assim, o segundo nível. Essas duas especificações definem dois tipos de requisitos:

1. requisitos de usuário, quando definidos pelo cliente;
2. requisitos de sistema, quando definidos pelo fornecedor.

Os requisitos de usuário descrevem, em linguagem natural e com o auxílio de diagramas, quais serviços e funcionalidades são esperados do sistema e quais as restrições em que ele deve operar. Já os requisitos de sistema definem, detalhadamente, as funcionalidades, os serviços providos e as restrições do sistema.

Além desta, há diversas outras classificações de requisitos. Aquela cujo conceito é mais abrangente, relaciona os requisitos em: funcionais (RFs) e não funcionais (RNFs) - também chamados de requisitos de qualidade. Enquanto os RFs descrevem as funcionalidades do sistema – ou seja, os serviços que o sistema deve fornecer, como deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações –, os RNFs descrevem os aspectos subjetivos do sistema, como, por exemplo, segurança, usabilidade ou disponibilidade. Os requisitos de qualidade são classificados e descritos de acordo com atributos de qualidade correspondentes. Tomando como exemplo o atributo usabilidade, o fato de o sistema ser utilizável por pessoas com baixo grau de instrução é um possível requisito de qualidade. São esses requisitos que atuam como guia para a definição da arquitetura do sistema.