Capturando Requisitos Arquiteturais_contato_pessoal

GUIA DE DETECTÇÃO REQUISITOS
ARQUITETURAIS
Insira uma imagem relacionada com seu tema
Thiago Moreira
Uma resenha do maravilhoso artigo de Peter Eeles

ÍNDICE
Introdução
Requisitos Arquiteturais - O que são?
Exemplos
FURPS+
Categorias do FURPS+
Detectando Requisitos
1
3
4
5
7
10
Thiago Moreira @ttrmoreira
Guia de detecção de requisitos arquiteturais
Classificação
Mecanismos Arquiteturais
Seja um mestre na detecção de requisitos-
arquiteturais.
11
13
18
Como evitar as falhas mais comuns na detecção de
requisitos arquiteturais?
E na prática? Como é que faz?
Conclusão
22
23
33

INTRODUÇÃO
Para quem serve este
guia?
Gerentes de Projetos de
Software, Arquitetos de
Software Iniciantes ou
até mesmo,
Desenvolvedores que
receberam pela primeira
vez a missão de
especificar uma
arquitetura e não fazem
ideia por onde começar.
O que são requisitos
arquiteturais?
São as condições ou
capacidades que um
sistema deve possuir em
termos de arquitetura
para atender às
demandas funcionais
exigidas na especificação
do sistema.
Sobre o que esse guia
trata?
Ele descreve uma
técnica sistemática
dessa difícil arte de
capturar requisitos
arquiteturais com base
no artigo “Capturing
Architectural
Requirements” de
Peter Eeles
2 3
1
1

O que vou aprender com esse e-book?
Você vai aprender o passo-a-passo da técnica
de extrair requisitos de valor arquitetural
garantindo decisões arquiteturais confiáveis
e fundamentadas.
No que essa tal técnica vai ajudar na
prática?
Ajudará o seu projeto a identificar o
equilíbrio de custo X benefício nas soluções
arquiteturais. A não ser que a palavra
economia não faça parte do seu dicionário.
4
6
O que vou agregar em termos de valor lendo
esse guia?
Você não correrá o risco de tomar decisões
arquiteturais com base em suas paixões ou
achismos.
5
2

Requisitos Arquiteturais
O que são?
• Esses requisitos são como a parte
submersa de um iceberg. Ninguém vê!
Mas acredite! É o que dá sustentação.
• Um requisito arquitetural pode ser
explícito ou implícito. Na maioria das
vezes costumam ser implícitos.
Conhecidos como
requisitos de potencial
valor para a arquitetura
de um sistema.
São informações relevantes
em termos de arquitetura
para a parte funcional de um
sistema
3

Exemplos
• O produto será acessado por outros
países (Internacionalização).
• A persistência será manuseada por
um banco de dados NoSQL
• O banco de dados será MongoDB.
• O sistema deve suportar 24x7
• Uma ajuda on-line será necessária
• A interface do usuário deverá ser
cross-browser. Note que esses requisitos estão
misturados entre funcionais e não-
funcionais, alguns são
independentes de tecnologia e
outros não.
Exemplos de requisitos arquiteturais explícitos
4

O FURPS+ é um sistema de classificação de
conteúdo que foi criado por Robert Grady na
Hewlett Packard. O acrônimo “FURPS”
representa as seguintes categorias:
• Functionality (Funcionalidade)
• Usability (Usabilidade)
• Reliability (Confiabilidade)
• Performance (Execução)
• Supportability (Suportabilidade)
Entendendo o FURPS+
FURPS+ Para que esses requisitos sejam classificados
adequadamente, é preciso um framework
capaz de classificar tais requisitos
arquiteturais e que assegure que declarações
valiosas para o sistema, não sejam
negligenciadas. Esse framework é conhecido
como FURPS+
O acrônimo “+” representa:
• Design Requirements (Requisitos de
Projeto)
• Implementation Requirements
(Requisitos de Implementação)
• Interfaces Requirements (Requisitos
de Interface)
• Physical Requirements (Requisitos
Físicos)
5

Vamos analisar
com mais
profundidade
essas categorias?
Guia de detecção de requisitos arquiteturais 6

Insira um gráfico aqui
Functionality (Fucionalidade)
A categoria de funcionalidades representa os principais requisitos funcionais de um
produto. Entretanto nem todos os requisitos tem alguma importância arquitetural.
Ex. Prover acesso à aplicação via smartphone é mais significativo do que controlar
estoque.
Categorias do FURPS+
Função Descrição
Internacionalização Prover facilidades para suportar múltiplas línguas.
Segurança Prover serviços para proteger informações e acesso.
Impressão Prover facilidades para impressão.
Posso ajudar Online Prover capacidades de ajuda online.
Cross browsing Prover capacidade de acesso por múltiplos browsers.
E-mail Prover serviços de envio e recebimento de e-mail.
Workflow Prover suporte à trâmite de documentos e ciclos de aprovação.
Exemplos de Requisitos arquiteturalmente significativos
7

FURPS+
Usability
(Usabilidade)
A usabilidade é interessada
em aspectos estéticos e
interatividade na interface
com o usuário. Acredite, essa
é uma categoria que pode
determinar o sucesso ou o
fracasso de um projeto.
Muitas vezes por questões de
prazo e verba é colocada em
segundo plano.
Essa categoria é
interessada em aspectos
voltados para
disponibilidade, precisão
do sistema em realizar
suas funções e a
habilidade para se
recuperar de falhas
Essa categoria é
interessada no
rendimento da aplicação
em termos de tempo de
resposta, tempo de
recuperação de falhas,
tempo de inicialização e
tempo de encerramento.
Reliability
(Confiabilidade)
Performance
(Execução)
As categorias URPS, descrevem requisitos que são em sua
maioria arquiteturalmente significativos.
8

• Requisitos de projeto – Categoria
reservada a restrições de projeto
• Requisitos de implementação –
Categoria reservada a restrições de
código ou construção de sistemas
• Requisitos de interface – Categoria
reservada a interações com
elementos externos ao sistema.
• Requisitos físicos – Categoria
reservada as restrições impostas por
hardware, de qualquer ordem.
FURPS+
• Essa categoria é interessada nos
aspectos de testabilidade do
sistema, adaptabilidade,
manutenabilidade, compatibilidade,
configurabilidade, instabilidade, e
localizabilidade. Esses termos são
aportuguesados. Talvez, não
encontrados nos dicionários
“+”
• O acrônimo “+” é reservado a
identificação de novas categorias
que normalmente possuem
significado arquitetural
Supportability
(Suportabilidade)
9

Espaços vazios
ajudam a dar um
descanso na leitura
Como percebê-los?
Em conformidade com as
descrições anteriores é fácil
perceber que a maioria dos
requisitos funcionais e a maior
parte dos requisitos pertencentes à
outras categorias do FURPS+ são
arquiteturalmente significativos.
Vamos tentar
identificar as
categorias de alguns
requisitos utilizando a
classificação do
FURPS+ e atribuí-las
aos mesmos.
Detectando
Requisitos
10

1. “O site será internacionalizado (suporte a múltiplas línguas)”
é um requisito de suportabilidade.
2. “A persistência dos dados será feita em um banco de dados
NoSQL” trata-se de um requisito de projeto.
3. “O banco de dados será o MongoBD 2.4” isso é um requisito
de implementação.
4. “O sistema deve rodar em 24x7” esse é um requisito de
confiabilidade.
5. “Os usuários do site devem contar com uma ajuda on-line”
esse é um requisito funcional.
Classificação
Exemplos

• Percebendo os requisitos e
sabendo classifica-los, você
saberá fazer as perguntas
certas aos stakeholders.
• Existe um outro aspecto
importante que é a relação
entre as categorias dos
requisitos. O que a princípio
parece meio sem sentido,
pode ser obtido considerando
mecanismos arquiteturais
Fique atento!
12

MECANISMOS
Arquiteturais
Os mecanismos arquiteturais, são
uma solução para o problema de
relação entre as categorias de
requisitos arquiteturais.
Talvez você esteja se
perguntando. Mas que relação é
essa?
Eu explico! Na maioria das vezes os
requisitos influenciam fortemente
outros e é importante detectá-los
antes.
13

Podemos utilizar como exemplo um requisito de segurança que pode influenciar
um de desempenho por conta de validações e autenticações exigidas.
Os mecanismos arquiteturais auxiliarão você a descobrir como um influencia o
outro.
100 metros em
9,77 segundos.
Essa é minha
meta!
Sem chance! A
velocidade
máxima
permitida aqui é
de 9km/h.
14

Sem levar em conta a influência do requisito de segurança em cima do requisito de
desempenho, você pode decidir por uma solução que não atenda ao desempenho
ou segurança esperados.
Utilizando essa técnica você garante que as soluções escolhidas estão
sendo influenciadas por todos os requisitos detectados.
Mecanismo de Análise Mecanismos de Projeto Mecanismo de Implementação
Persistência
SGBD
MySql
Postgree
NoSql MongoDB
Usabilidade
RIA
JQuery
GWT
Tradicional JSF
Para mais exemplos de
mecanismos de análise
acesse o link
http://goo.gl/thCks6
A tabela abaixo mostra três categorias de mecanismos arquiteturais.
15

Mecanismos de
análise
Os mecanismos de
análise representam uma
implementação
independente de
solução. No exemplo
anterior temos
“usabilidade” mas não
citamos o tipo e a
solução específica.
Os mecanismos de
projetos já são um
refinamento dos
mecanismos de análise,
neles nós podemos
encontrar aspectos de
implementação mas não
a solução definitiva.
Os mecanismos de
implementação são um
refinamento dos de
projeto, e esses já
declaram soluções
definitivas que já sofrem
a influência dos
requisitos não funcionais.
Mecanismos de
projetos
Mecanismos de
implementação
Com essa técnica é possível detectar as relações entre os requisitos e como eles influenciam na
escolha das soluções. No exemplo citado anteriormente sobre segurança e desempenho,
poderíamos dizer que a influência que a segurança causa no desempenho nos levou a escolher
como banco de dados o MongoDB, por se tratar de uma solução distribuída e que equilibraria um
forte esquema de segurança com um tempo de resposta aceitável.
16

A tabela abaixo mostra a relação entre requisitos e mecanismos.
Requisitos
Mecanismos de
Análise
Mecanismos de
Projeto
Mecanismo de
Implementação
Requisitos
FURPS
Mecanismos
de análise
Mecanismos
de Projeto
Mecanismos
de
Implantação
Requisitos
de Projeto
Requisitos de
Implementação
influenciam
influenciam
influenciam
são refinados em
são refinados em
17

Peter Eeles em seu artigo “Capturing Architectural Requirements” ensina passos
simples para você captutar requisitos arquiteturais.
Seja um mestre na detecção de
requisitos arquiteturais

“mantenha uma lista completa de
requisitos arquiteturais. Mesmo
que todos os itens não sejam
relevantes para o projeto.”
“para cada requisito
arquitetural, formule uma ou
mais questões que podem
ajudar no processo de
especificação. Assegure que
todos os stakeholders do projeto
possam entender as questões.”
“ajude os stakeholders,
mostrando-lhes os
impactos em potencial se
eles responderem de uma
forma ou de outra.”
“capture as respostas
de seus stakeholders
para cada uma das
questões.”
1
2
3
4
“auxilie o arquiteto, garantindo que as
partes, além de responderem a estas
perguntas também atribuam uma
prioridade ou ponderação para cada
exigência arquitetônica. Essa
ponderação vai permitir ao arquiteto
fazer compensações entre os
requisitos.”
5
Acesse o link
http://goo.gl/r18OXv
para ter acesso a uma
amostra.
19

De uma maneira macro, todos os
requisitos de arquitetura de software
são finitos, e isso torna possível o uso
dessa abordagem. Peter Eeles cita que:
Você também pode aplicar esta
abordagem para coleta de
requisitos em domínios de
problemas particulares que
também são finitos, bem definidos
e tenham um conjunto de
considerações. Para um sistema
financeiro, por exemplo, haveria
um imperativo de colocar algumas
questões relacionados a finanças.
“
“
20

Peter Eeles em seu artigo, demonstra com um simples exemplo como podem ser
definidos esses questionários.
Como é feito um questionário para
detectar requisitos arquiteturais?
Requisito Questões Impacto Respostas Prioridade
Disponibilidade Existem requisitos do sistema referentes a
“up-time”? Isto pode ser especificado em
termos de tempo médio entre as falhas
(MTBF)?
Quanto maior a
disponibilidade, maior o
time-to-market.
Disponibilidade é o
requisito chave do
produto. O produto deve
ter um MTBF de 60 dias
Alta
Usabilidade Existem requisitos do sistema que devem
empregar recursos especiais de interface
com o usuário para que o mesmo possa
realizar tarefas?
Quanto mais rico for o grau
de usabilidade, mais deve-
se contar em termos de
tecnologia com o lado
cliente para processar os
recursos (fat-client).
A usabilidade do sistema
pode manter as
estruturas já utilizadas
dentro da organização e
que seguem o manual de
usabilidade XPTO.
Média
Uma vez completado esse questionário, ele
influenciará na definição dos mais importantes
artefatos do processo de desenvolvimento. Ex. Modelo
de caso de uso, Diagrama de classes de projeto, etc.
Para mais exemplos de
questionários de
requisitos arquiteturais
acesse o link
http://goo.gl/QkZrN
21

Como evitar as falhas mais comuns na
detecção de requisitos arquiteturais?
1. Mentalidade carrinho de compras – Quando o analista passa para o stakeholder o sentimento de que especificar
é como sair para fazer compras.
2. A atitude “Isto é muito técnico para mim” – Alguns stakeholders costumam se desviar dos requisitos
arquiteturais quando os mesmos não pertencem a sua área de negócio.
3. A falácia “Todos os requisitos são iguais” – Isto acontece quando a mesma prioridade é dada a todos os
requisitos.
4. O problema “coloque isto na pilha” – Isto acontece quando os stakeholders não percebem o valor e a
criticidade da definição dos requisitos arquiteturais e acabam deixando eles empoeirarem em algum canto por
aí.
5. A síndrome “nem todos os requisitos são mensuráveis” – Todos os requisitos devem ser mensuráveis e
desambíguos. Um requisito “estado da arte das interfaces” é muito subjetivo e não pode ser mensurável.
6. A queixa “não temos tempo para isso” – Você já leu até aqui, já deve ter percebido o impacto dos requisitos
não funcionais em um sistema.
7. O problema da “falta de prioridade” – O questionário deve transmitir ao stakeholder um entendimento
adequado sobre o requisito para que ele possa priorizá-lo. Assegure que o questionário não seja tão técnico.
8. O equívoco “todos os stakeholders são iguais” – Enderece as perguntas certas para as pessoas certas. Acredite,
as pessoas são diferentes.
9. A tendência do “Tão genérico” – Assegure foco e especificidade no questionário, mesmo que seja necessário
ilustrar uma situação que coloque o stakeholder como protagonista.
Aplicávelaqualquertipo
derequisito

E na prática
como é que
faz
23Guia de detecção de requisitos arquiteturais

REQUISITOS
1
Bem, vamos trabalhar com a ideia de
requisitos e fatores fictícios que vão
influenciar na tomada de decisão .
Imagine que você detectou os seguintes requisitos
do sistema acadêmico Web da Universidade XYZ
•Suportar o crescimento do número de alunos. A meta é atingir 60 mil alunos até 2015.
•Facilitar o acesso dos usuários disponibilizando o sistema na Web.
•O sistema acadêmico deverá emitir diariamente as listas de presença dos alunos para
que os professores possam fazer apuração de frequência.

CLASSIFICAÇÃO DOS REQUISITOS
2
Vamos fazer a detecção de requisitos
arquiteturais em cima de cada um deles com
base em nossos conhecimentos prévios sobre
arquitetura.
Com base nessas classificações você vai criar um
questionário voltado para os requisitos relacionados
que você identificou como importantes.
•Suportar o crescimento do número de alunos. A meta é atingir 60 mil alunos até 2015.
• Classificação FURPS+ - Suportabilidade
•Facilitar o acesso dos usuários disponibilizando o sistema na Web.
• Classificação FURPS+ - Usabilidade
•O sistema acadêmico deverá emitir diariamente as listas de presença dos alunos para
que os professores possam fazer apuração de frequência.
• Classificação FURPS+ - (Funcionalidade) Serviço de Impressão

QUESTIONÁRIO DOS REQUISITOS ARQUITETURAIS
3a
Vamos escolher um requisito e trabalhar a
detecção de requisitos arquiteturais em cima
dele para que o exemplo não se torne extenso
demais.
Para efeitos didáticos vamos colocar apenas uma
categoria do FURPS+ para o requisito.
Para saber quais são as subcategorias de uma
categoria acesse o link.
SUPORTABILIDADE
Requisito Questões Impacto Resposta do Stakeholder Prioridade
Escalabilidade
Qual o volume de
usuários simultâneos
que acessarão o
sistema
Quanto maior for a capacidade
de escalabilidade do sistema,
maior será o time-to-market.
O volume máximo de usuários simultâneos é
previsto para 2 mil atualmente, podendo
chegar a 6 mil em 2015.
Alta
Requisito de
projeto
Existem restrições
sobre o mecanismo
utilizado para suportar
o crescimento de
acesso dos alunos a
aplicação?
Restrições desse tipo podem
impedir que se alcance o
número esperado de acessos
simultâneos
Sim, existe uma limitação de verba para a
compra de servidores, por isso a Universidade
utilizará sua parceria com a empresa X para
obter servidores de 2ª linha.
Para cada requisito você irá formular uma ou
mais questões que podem auxiliar no processo
de especificação. Você deve garantir que
todos os stakeholders possam entender as
perguntas.
Para cada requisito arquitetural identificado,
podem existir mecanismos de projeto,
implementação ou físicos que influenciam
diretamente o mesmo. Assegure que você não está
deixando nada de fora em seu questionário.

demais.
USABILIDADE
Estética
Existem requisitos
especiais sobre a
aparência do sistema?
Quanto maior for o apelo
estético do sistema, maior será
o Time-to-Market e custo.
Sim, nossa empresa já possui um guia de design
de telas e relatórios que deve ser respeitado.
Média
Requisito de
implementação
relacionadas a
implementação que
devem ser respeitadas
sobre o mecanismo
utilizado para estética
de telas e relatórios?
Se o time de desenvolvimento
não estiver familiarizado com
tal restrição, isso poderá gerar
uma curva de aprendizado que
aumentará custos e o Time-to-
Market.
Sim, as telas do sistema devem ser ricas em
termos de recursos de acordo com o guia de
design.
3b

demais.
FUNCIONALIDADE
Impressão
Impressão de relatórios
em grande escala é uma
capacidade requerida? Quanto mais sofisticado for o
mecanismo de impressão, maior
será o Time-to-Market e o custo.
Sim, o sistema acadêmico deverá enviar
para impressão diariamente as listas de
presença dos alunos para que os
professores possam fazer apuração de
frequência. Esse procedimento deverá
ser automatizado sem intervenção
humana.
Alta
Requisito de
projeto
Existem restrições sobre o
mecanismo utilizado para
impressão?
Não, a impressora já é preparada para
altas demandas de impressão e já
funciona em rede.
Requisito de
implementação
Existem restrições de
código que devem ser
respeitadas sobre o
mecanismo utilizado para
impressão?
Se o time de desenvolvimento
não estiver familiarizado com tal
restrição, isso poderá gerar uma
curva de aprendizado que
aumentará custos e o Time-to-
Market.
Sim, o fornecedor da impressora possui
uma API para integração com outros
sistemas e a universidade ainda não fez a
aquisição da mesma.
Requisito Físico
impostas sobre o
hardware de impressão ou
a rede com a qual ele se
conecta?
Restrições desse tipo
normalmente implicam na
contratação de profissionais
especializados, o que aumenta os
custos e Time-to-Market?
Não
3c

IDENTIFICANDO A RELAÇÃO ENTRE REQUISISTOS E
MECANISMOS ARQUITETURAIS4a
Depois de obtidas as respostas, vamos
identificar os mecanismos de projeto
Mecanismos de Análise Mecanismos de Projeto Mecanismo de Implementação
Suportabilidade
(Escalabilidade)
Escalabilidade Horizontal
Servidor X Clusterizados (Cloud
Plan)
Servidores X Clusterizados
(Local Infra)
Influência do Requisto de Projeto
O Stakeholder respondeu no questionário que por
questões de verba os servidores seriam da 2ª linha do
fornecedor X. Múltiplos computadores independentes
são mais eficientes em termos de escalabilidade do
que um único dessa marca com mais capacidade de
processamento. Portanto a escalabilidade horizontal é
a mais adequada decisão arquitetural, influenciada
pelo requisito de projeto.

MECANISMOS ARQUITETURAIS4b
Usabilidade (Estética)
RIA (Rich Internet
Application)
GWT (Google Web Tool Kit)
JQuery
Influência do Requisto de Implementação
O Stakeholder respondeu no questionário que existe
um guia de design da empresa que deve ser seguido.
Esses são os mecanismos de implementação que
permitirão que as telas do sistema possam ser ricas em
termos de recursos de acordo com o guia de design.

MECANISMOS ARQUITETURAIS4c
Funcionalidade(Impressão)
Impressora de alta
performance
API Java XPTO
Influência do Requisto de
Implementação
O Stakeholder respondeu no
questionário que existe uma
API para integração com outros
sistemas. De acordo com um
processo de mitigação de riscos
foi identificado que esse é o
único mecanismo de
implantação que propicia
interfaceamento com a
impressora

ATRIBUIR PESOS E PRIORIDADES AOS REQUISITOS
ARQUITETURAIS5
demais.
Depois que todas essas etapas foram
cumpridas, você entrará na fase de atribuição
de pesos e prioridades aos requisitos. Essa
definição serve como um trade-off para os
mecanismos de implementação.
Essa etapa deve ser realizada com os stakeholders e
arquitetos. Existe uma técnica conhecida como QAW
(Quality Atribute Workshop) que pode auxiliar
bastante na definição desses pesos e prioridades.
Para mais informações
sobre QAW acesse o link
http://goo.gl/rfuMf7

CONCLUSÃO
• Os requisitos arquiteturais, podem ser
determinantes para o sucesso de um
projeto de software. Você deve ter
percebido que não é uma tarefa tão fácil
assim. Ainda existem possibilidades de
falhas no processo fazendo com que os
mesmos sejam negligenciados.
• Utilizando essa técnica pragmática, como
um verdadeiro esquema de classificação
de requisitos não-funcionais, pode fazer
toda a diferença em seu projeto.
• Se você já utiliza um processo que cobre
todas a fase de detecção de requisitos
não-funcionais, faça uma comparação e
veja se o método apresentado não é mais
eficiente.

LINKS
úteis
Esses links direcionam
para os apêndices
disponibilizados no
artigo de Peter Eeles
“Capturing
Architectural
Requirements”
Acesse os links
• Mecanismos de Análise
• Requisitos não-funcionais
• Amostra de questionário de requisitos
não-funcionais

Se você gostou, compartilhe e ajude a
divulgar!
COMPARTILHE
SIGA
Siga para ter acesso a mais conteúdos
relevantes.
ttrmoreira@gmail.com
CONTATO
Leia o post sobre como
criar os botões de
compartilhamento

Capturando Requisitos Arquiteturais_contato_pessoal

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Capturando Requisitos Arquiteturais_contato_pessoal