Uma frase comum em empresas de TI é:  “Nós não tempo de especificar os requisitos. Se não começarmos a codificar agora, não iremos entregar o produto a tempo”.

As consequências desta falácia são conhecidas também:

• Aplicações que não performam em produção.
• Aplicações que operam no Internet Explorer mas não funcionam no Mozilla Firefox.
• Aplicaçõe que travam ou requerem boots regulares nas máquinas.
• Sistemas removidos da produção.

O sintoma destas questões remete ao processo de gestão (ou ausência de gestão) de requisitos arquiteturais. “Um requisito pode ser chamado de requisito arquitetural sempre que for significativo para a arquitetura”, Peter Eeles, 2005, no excelente artigo Capturing Architectural Requirements.

Tipos de Requisitos

Diferentemente do senso comum, requisitos arquiteturais não são requisitos não-funcionais. Requisitos arquiteturais são um projeção de qualquer tipo de requisito que possua importância para a arquitetura, tais como requisitos funcionais ou requisitos não-funcionais (desempenho, usabilidade ou manutenibilidade).

Por exemplo, um caso de uso de pagamento de fatura com cartão de crédito pode ser suficientemente complexo para o time do projeto e ser considerado um requisito arquitetural. Em um outro exemplo, um atributo de qualidade (requisito não-funcional) ligado a um tempo de resposta não maior que 3 segundos para as operações de um call-center também pode ser captura pelo arquiteto com um requisito arquitetural.

Técnicas para de Captura de Requisitos Arquiteturais

A captura de requisitos arquiteturais pode ser realizada de várias formas. Algumas técnicas e modelos incluem:

• Requisitos SMART. Em verdade, é uma técnica usada primordialmente para avaliar a qualidade de um requisito. Um requisito SMART é específico (SMART), mensurável (M), atingível (A), realizável (R) e rastreável (T). Como  exemplo, um requisito arquitetural que diga: O sistema deve suportar um grande volume de usuários poderia ser escrito SMART como:  O sistema deve suportar um volume de 100 usuários em período de pico.
• Modelo FURPS+.  O modelo FURPS+ é uma classificação de requisitos proposta por Robert Grady, da Hewlett Packard (HP).  Ele pode auxiliar a identificação dos requisitos de um sistema e na sua organização e classificação na Especificação de Requisitos. As letras FURPS+  significam: Funcionalidade (Functionality), Usabilidade (Usability), Confiabilidade (Reliability), Desempenho (Performance) e Suportabilidade (Supportability). O símbolo “+” é utilizado para representar restrições impostas à solução, como por exemplo o uso de um banco de dados Oracle ou uma linguagem como Java como premissas para a codificação de um sistema. O modelo abrange tanto os requisitos funcionais quanto os não funcionais.
• O modelo ISO/IEC 9126.  A norma ISO/IEC 9126 estabelece um modelo para qualidade de software [ISO 2001]. Ela estabelece atributos de qualidade que permitem avaliar um produto de software. o modelo assemelha-se ao FURPS+, no sentido de classificar os diferentes tipos de
  requisitos que influenciam na avaliação de qualidade do produto. No entanto, a ISO 9126 é mais
  abrangente que o modelo FURPS+ por considerar, além da qualidade interna e externa do produto,
  a sua qualidade em uso.
• Um outro método (criado por Mario Barbacci) e publicado no SEI, é o QAW, que é um workshop que tem por objetivo capturar um conjunto de cenários de qualidade priorizados. Este método foi descrito em nosso site no artigo em anexo.

O Funil do Arquiteto

Pelo funil do arquiteto, devem passar apenas os requisitos de alto impacto e escopo abrangente. Estes requisitos são o foco do trabalho do arquiteto e compõe os requisitos arquiteturais.

As técnicas/modelos  SMART, FURPS+, ISO 9126 e QAW podem ser usadas isoladamente ou em conjunto para apoiar o arquiteto no processo de coleta de requisitos.

Para os maiores interessados, colocamos referências adicionais para este trabalho:

• Norma ISO/IEC 9126
• Método FURPS – Grady, Robert (1992). Practical Software Metrics for Project Management and Process Improvement. Prentice Hall.
• Paper original do SMART.
• Checklist simplificado da ISO 9126.