QAW (Quality Attribute Workshop) é um dos métodos centrados em arquitetura desenvolvido pelo SEI. Seu propósito é engajar os stakeholders em revelar requisitos não-funcionais relacionados a uma sistema antes da arquitetura ser desenhada. O QAW pode ser usado em aderência a outros métodos como ao complementar o ATAM ou integrar com o ADD.

Em geral, sem o uso de um método para captura dos requisitos de qualidade, há uma lacuna entre a exposição das necessidades de negócio e a identificação dos requisitos arquiteturais.

Fonte: Quality Attribute Workshops (QAWs), Third Edition – Barbacci et al

De fato, muitos sistemas funcionam bem e tiveram boas arquiteturas desenhadas sem ajuda do QAW. Isso, muitas vezes, é proporcionado pela experiência de arquitetos e analistas (um tanto acostumados em tentar adivinhar as necessidades do usuário) que identificam os requisitos de qualidade artesanalmente ou com base em experiências místicas. Entretanto, sistemas muito complexos necessitam de maior precisão na obtenção de tais atributos de qualidade. O QAW pode facilitar a vida até mesmo de arquitetos experientes. 

Além de endereçar uma precisão do requisitos, o QAW também facilita sua priorização. Muitos requisitos de qualidade conflitam entre si e tentam se equilibrar como que numa complexa balança. Por exemplo: confiabilidade pode implicar em menor performance; segurança pode afetar a usabilidade; etc.

A idéia é envolver os stakeholders em um evento de um dia objetivando identificar um conjunto de cenários com os atributos de qualidade categorizados, priorizados e refinados. Recomenda-se um número entre 5 e 30 stakeholders para contribuir na oficina de requisitos de qualidade e as discussões devem ser limitadas a um dia.

O QAW envolve os seguintes passos:

1. Apresentação do método QAW pelo moderador acrescida das devidas introduções.
2. Apresentação das diretrizes de negócio/missão, mostrando os interesses envolvidos, contexto do sistema, requisitos funcionais de alto-nível, restrições, etc.
3. Apresentação de um plano arquitetural. Embora a arquitetura em si ainda não exista, é possível demonstrar uma estrutura candidata para solução do problema, diagramas de contexto, restrições chave (ex: SGBD, SO, middleware, padrões), etc.
4. Identificação das diretrizes arquiteturais. Aproveitando um intervalo de 15 minutos entre os passos 3 e 4, os facilitadores consolidam suas notas sobre capturam os requisitos e objetivos identificados nos passos anteriores. 
5. Brainstorming de cenários. Seguindo uma cerimônia no estilo round-robin, procura-se identificar com os stakeholders os cenários relevantes. O facilitador deve ajudar o stakeholder a obter cenários bem formados, isto é, com estímulo, ambiente e resposta. Exemplo de cenário: “um usuário remoto submete um formulário via web durante o período de pico e recebe uma resposta em até seis segundos”.
6. Consolidação de cenários, fundindo cenários parecidos. Além de reduzir as informações a serem tratadas, a consolidação evita a dispersão de votos do passo 7.
7. Priorização de cenários, usando um esquema baseado em votação.
8. Refinamento dos cenários mais prioritários, garantindo que cada cenário prioritário seja descrito, entre outras coisas, pelos seis elementos (vide figura) e apresente atributos de qualidade associados a ele.

 

Fonte: Software Architecture in Practice, 2n Edition – Bass, Clements, Kazman

Os resultado de uma sessão de QAW incluem:

• lista de diretrizes arquiteturais;
• cenários “crus”
• lista priorizada de cenários
• cenários mais importantes refinados

Com requisitos de qualidade mais refinados e devidamente balanceados por vários stakeholder, a equipe de arquitetura terá como insumo uma fonte extremamente valiosa. Em seu próximo projeto de software, sugiro que avalie a possibilidade de usar o QAW. Possivelmente, os riscos envolvidos serão bem menores.

Mais informações: Relatório Técnico sobre o QAW, 3a Edição