Como obter requisitos arquiteturais - parte 1

O que é um requisito arquitetural?

Trata-se de qualquer requisito que é arquiteturalmente significante, onde o nível de significância pode estar implícito ou explícito. Requisitos arquiteturais implícitos são aqueles
que possuem atributos particulares. Por exemplo, qualquer requisito de alto risco,
alta prioridade ou baixa estabilidade pode ser considerado arquiteturalmente significante.
Entretanto o artigo foca primeiramente nos requisitos explícitos, segue alguns exemplos de requisitos arquiteturais explícitos:

• O sistema deve ter apoio a múltiplas linguagens humana;
• A persistência será feita através de um banco de dados relacional;
• A base de dados será Oracle 8i;
• O sistema irá correr sete dias por semana, vinte e quatro horas por dia;
• Um sistema de ajuda on-line é necessário;
• Toda apresentação lógica será feita em Flex.
  

Como você pode perceber, estes requisitos são muito diferentes e estão misturados. Alguns são funcionais, outros não-funcionais; alguns são independentes dos mecanismos técnicos, e outros não. O que nós precisamos é de uma abordagem sistemática que proveja um framework para classificação das exigências arquiteturais, garantindo que essas valiosas declarações como as que estão listadas acima não sejam esquecidas.

FURPS + sistema de classificação de requisitos

Para auxiliar a categorização utilizamos o modelo FURPS+ [GRA92] que descreve as principais categorias de requisitos:

• Funcionalidade
• Usabilidade
• Confiabilidade (Reliability)
• Desempenho (Performance)
• Suportabilidade

O "+" na FURPS + também nos ajuda a lembrar preocupações como:

• Requisitos de design
• Requisitos de implementação
• Requisitos de interface
• Exigências físicas

Vamos analisar em pormenor cada categoria.


Requisitos funcionais

Requisitos funcionais geralmente representam as principais funcionalidades do produto. Em um armazém pedido, talvez tivéssemos requisitos relativos à ordem processamento ou estoque controle. No entanto, requisitos funcionais nem sempre são específicos do domínio. Proporcionar impressão capacidade funcional é um requisito de particular importância para arquitetura.

Requisitos não-funcionais

Os restantes "URPS" categorias descrever requisitos não-funcionais que são geralmente arquiteturalmente significativos.

• Usabilidade: interesse em características como estética e coerência na interface do utilizador.
  
  
• Confiabilidade (Reliability): interesse em características como a disponibilidade, a exatidão do sistema de cálculos, bem como a capacidade do sistema de recuperação de falhas.
  
  
• Desempenho (Performance): interesse em características como a velocidade do tempo de resposta, o tempo de recuperação, tempo do start-up , e tempo do shutdown .
  
  
• Suportabilidade (Supportability): interesse em características como testabilidade, adaptabilidade, durabilidade, a compatibilidade, configurabilidade, instalabilidade, escalabilidade e localizabilidade.

O "+" no FURPS + sigla é usada para identificar outras categorias que geralmente representam restrições.

• Um requisito de design, muitas vezes chamado de restrição de design, especifica ou restringe as opções para projetar um sistema. Por exemplo, se você especificar que uma base relacional é necessária, isto é uma restrição de design.
  
  
• Um requisito de implementação especifica ou restringe a codificação ou a construção de um sistema. Exemplos podem incluir normas exigidas, as liguagens de execução, dos recursos e limites.
  
  
• Um requisito de interface especifica um meio externo com o qual um sistema deve interagir, ou restringe algum formato ou outros fatores utilizados dentro dessa interação.
  
  
• A exigência física especifica uma limitação física imposta ao hardware utilizado para abrigar o sistema - forma, tamanho ou peso, por exemplo.

Identificando os requisitos

A partir da descrição acima, podemos ver facilmente que algumas exigências funcionais, e mais exigências no FURPS+ de outras categorias, são arquiteturalmente significativas. Agora vamos analisar como poderíamos classificar os requisitos arquiteturais que aparentemente não estão relacionados enumerados anteriormente. Usando o FURPS + na classificação podemos ver:

• “O sistema deve ter apoio a múltiplas linguagens humana” é um requisito de suportabilidade.
  
  
• “A persistência será feita através de um banco de dados relacional" é um requisito de design.
  
  
• " A base de dados será Oracle 8i" é um requisito de implementação.
  
  
• “O sistema irá correr sete dias por semana, vinte e quatro horas por dia" é um requisito confiabilidade.
  
  
• "Um sistema de ajuda on-line é necessária" é um requisito funcional.
  
  
• " Toda apresentação lógica será feita em Flex" é um requisito de implementação.

Fonte/referencias:

Peter Eeles, Senior TI arquitecto, IBM

[GRA92] Robert Grady 1992. Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall.