Na maioria das vezes, não faz muito sentido identificar requisitos fora do contexto de um projeto. Sendo assim, geralmente o QAW é empregado como uma atividade (ou conjunto de atividades) de um processo responsável por todo o ciclo de vida de desenvolvimento do software como o RUP (Rational Unified Process) ou o XP (eXtreme Programming). Neste texto, descrevemos uma possível combinação do QAW com esses processos.

QAW e o ciclo de vida do RUP
O QAW deve ser empregado antes de se modelar a arquitetura. A atividade de arquitetura do RUP mais relacionada ao contexto do QAW é “Desenvolver Especificações Suplementares” (Develop Supplementary Specifications) que deve ser realizada no início do desenvolvimento, isto é, nas fases de Iniciação (ou Concepção) e Elaboração. Conforme o gabarito do RUP, os requisitos não-funcionais podem ser enquadrados como especificações suplementares nos casos de uso.

Algumas tarefas do RUP que também podem ser influenciadas pelo método do QAW são a “Análise Arquitetural” (Architectural Analysis) e “Priorizar Casos de Uso” (Prioritize Use Cases), respectivamente associadas às disciplinas de “Análise e Desenho” e “Requisitos”.

Maiores informações podem ser encontradas no relatório técnico “Integrating Software-Architecture-Centric Methods into the Rational Unified Process”. Ponto de atenção: neste post, adaptei a nomenclatura para ficar coerente com o RUP 7.

QAW e o ciclo de vida do XP
Apesar do XP dar muito pouca ênfase à arquitetura de software (por confiar no valor da “coragem” para uma possível refatoração arquitetural, se necessário), geralmente a arquitetura é capturada na “Metáfora do Sistema” (System Metaphor).

Ao contrário do RUP, o XP originalmente não contempla um gabarito formal que inclua requisitos suplementares. Mas sugere-se suplementar as “Estórias de Usuário” (User Stories) com os requisitos de qualidade (representados com os seis tradicionais atributos). A primeira iteração do projeto é o momento perfeito para o evento de QAW, quando seriam capturados os requisitos de qualidade que devem nortear a metáfora sistêmica. A prática “Cliente presente” facilita o acontecimento do evento.

Outra prática que também contribui para o emprego do QAW é “Jogo de Planejamento” (Planning Game), pois a priorização dos requisitos de qualidade pode auxiliar na escolha das estórias de cada iteração.

Além disto, a prática “Desenvolvimento Guiado por Testes” (Test Driven Development) que potencialmente é favorecida pela identificação dos cenários no evento de QAW. Neste caso, os cenários podem ser usados posteriormente para avaliar o desenho e fornecer insumos para análise dos testes.

Maiores informações podem ser encontradas no relatório técnico “Integrating Software-Architecture-Centric Methods into Extreme Programming”.

QAW e outros processos de desenvolvimento de software
Mesmo que você não use diretamente o RUP ou o XP, possivelmente emprega alguma variante do RUP (ex: EUP, EssUP, OpenUP, etc) ou alguma metodologia ágil (ex: SCRUM, FDD, Crystal Clear). Ou ainda uma combinação de ambos como o AUP e a “dobradinha” RUP + Scrum. Assim poderá aplicar facilamente os fundamentos aqui expostos em qualquer método.

Outras referências:

1. Quality Attribute Workshops (QAWs), Third Edition
2. IBM Rational Unified Process
3. Integrating Architecture Methods: The Case of Extreme Programming
4. RUP in the dialogue with Scrum

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

• QAW (Quality Attribute Workshop)- Método para coleta de requisitos arquiteturais e atributos de qualidade de um sistema. Exemplos de atributos de qualidade incluem desempenho, usabilidade ou segurança.
• ADD (Attribute Driven Design) – Método para desenho arquitetônico a partir da valoração e priorização dos atributos de qualidade de um sistema no contexto de um projeto.
• ATAM (Architecture Tradeoff Analysis Method) – Método para avaliação de uma arquitetura a partir de seus atributos de qualidade.
• V&B (Views and Beyond) - Método para documentação de arquiteturas baseado na idéia de múltiplas visões.
• CBAM (Cost Based Analysis Method) – Método para definição e evolução de uma arquitetura baseado em critérios econômicos e financeiros.
• ARID (Active Reviews for Intermediate Designs) – Método para refinamento sucessivo de uma arquitetura ao longo das iterações de um projeto.

Para quem conhece o RUP, um excelente relatório técnico do SEI foi publicado para correlacionar o fluxo de arquitetura do RUP e os métodos do SEI.

Uma fonte mais formal de conhecimento são os livros publicados pelo grupo de arquitetura do SEI. Um resumo sobre os principais livros que descrevem estes métodos pode ser encontrado aqui.

Estes “legos” podem ser usados por analistas de requisitos (QAW), arquitetos (ATAM, V&B), projetistas (ARID) e até mesmo gerentes técnicos (CBAM) e constituem-se de práticas valiosas para a montagem de sistemas complexos.