Estava fazendo análise de um sistema e escolhi utilizar o mingle da ThroughWorks como gerenciador para um projeto que será feito com Scrum. Achei muito prático e funcional, vou utilizá-lo e ao final do projeto falo mais informações sobre a experiência que tive com ele.
Mostrando postagens com marcador requisitos. Mostrar todas as postagens
Mostrando postagens com marcador requisitos. Mostrar todas as postagens
domingo, março 23, 2014
domingo, abril 27, 2008
Como obter requisitos arquiteturais - parte 2
Mecanismos arquiteturais
Em termos simples, um mecanismo arquitetural representa uma solução comum para um problema encontrado com freqüência. Mecanismos arquiteturais são utilizados com freqüência para perceber requisitos arquiteturais.
A tabela abaixo mostra três categorias de mecanismos arquiteturais e mostra como esse mecanismos são expressos em cada uma dessas categorias.
Um mecanismo de análise representa uma implementação independente de solução.
Um mecanismo de design(projeto) é um refinamento de um mecanismo de análise. E um mecanismo de implementação é um refinamento de um mecanismo de design, e especifica a exata aplicação do mecanismo.
A figura abaixo resume a relação entre os requisitos e mecanismos, mostrando refinamentos do FURPS.

A abordagem proposta para obter requisitos arquiteturais com FURPS é a seguinte:
1. “Mantenha uma lista completa de requisitos arquiteturais, sem levar em
consideração se os itens listados são relevantes ou não para um projeto
particular”;
2. “Para cada requisito arquitetural, formule uma ou mais questões que
possam ajudar no processo de especificação. Tenha certeza de que todos os
envolvidos no projeto possam entender essas questões”;
3. “Ajude os envolvidos no projeto mostrando a eles o impacto potencial
de responder uma questão de uma forma ou de outra”;
4. “Capture as respostas dadas a cada uma das questões”;
5. “Ajude o arquiteto assegurando que os envolvidos no projeto (em adição
às respostas das questões) atribuam uma prioridade ou um peso a cada requisito
arquitetural. Esse peso atribuído ajudará o arquiteto a fazer escolhas entre os
requisitos”.
A tabela abaixo exemplifica um questionário desse tipo, que inclui também exemplos de respostas:
Fonte/referencias:
Em termos simples, um mecanismo arquitetural representa uma solução comum para um problema encontrado com freqüência. Mecanismos arquiteturais são utilizados com freqüência para perceber requisitos arquiteturais.
A tabela abaixo mostra três categorias de mecanismos arquiteturais e mostra como esse mecanismos são expressos em cada uma dessas categorias.
| Mecanismo de Análise | Mecanismo de Design | Mecanismo de implementação |
| Persistência | RDBMS | Oracle |
| Ingres | ||
| OODBMS | ObjectStore | |
| Comunicação | Object request broker Objeto pedido corretor | Orbix |
| VisiBroker | ||
| Message queue Mensagem fila | MSMQ | |
| MQSeries |
Um mecanismo de análise representa uma implementação independente de solução.
Um mecanismo de design(projeto) é um refinamento de um mecanismo de análise. E um mecanismo de implementação é um refinamento de um mecanismo de design, e especifica a exata aplicação do mecanismo.
A figura abaixo resume a relação entre os requisitos e mecanismos, mostrando refinamentos do FURPS.
A abordagem proposta para obter requisitos arquiteturais com FURPS é a seguinte:
1. “Mantenha uma lista completa de requisitos arquiteturais, sem levar em
consideração se os itens listados são relevantes ou não para um projeto
particular”;
2. “Para cada requisito arquitetural, formule uma ou mais questões que
possam ajudar no processo de especificação. Tenha certeza de que todos os
envolvidos no projeto possam entender essas questões”;
3. “Ajude os envolvidos no projeto mostrando a eles o impacto potencial
de responder uma questão de uma forma ou de outra”;
4. “Capture as respostas dadas a cada uma das questões”;
5. “Ajude o arquiteto assegurando que os envolvidos no projeto (em adição
às respostas das questões) atribuam uma prioridade ou um peso a cada requisito
arquitetural. Esse peso atribuído ajudará o arquiteto a fazer escolhas entre os
requisitos”.
A tabela abaixo exemplifica um questionário desse tipo, que inclui também exemplos de respostas:
| Requisito | Questões | Impacto | Respostas |
|---|---|---|---|
Licenças (prioridade: Média) | O sistema, ou parte dele será licenciado? Existem muitas restrições no mecanismo utilizado para prover capacidade de licenciamento? | Quanto maior a sofisticação do mecanismo de licenciamento, maior o tempo para realização da comercialização e maior o custo de manutenção. | O módulo de controle de estoque será comercializado como um componente separado do sistema e irá requerer licença. A ferramenta FlexLM é utilizada por toda nossa organização para prover capacidade de licenciamento. |
| Disponibilidade (prioridade: alta) | Existe algum requisito a respeito do tempo médio entre falhas do sistema (MTBF)? | Quanto maior a disponibilidade, maior o grau de comercialização do sistema. | Disponibilidade é uma característica chave do produto. O produto deve ter um MTBF de 60 dias |
| Suporte a plataformas (prioridade: alta) | Que plataformas o sistema deve suportar? | O desenvolvimento para uma única plataforma pode reduzir o potencial de comercialização do produto.Também pode permitir uma integração com as características das plataformas. | O produto deve ser implementado para rodar nas seguintes plataformas UNIX: Sun Solaris IBM AIX HPUX |
Fonte/referencias:
Peter Eeles, Senior TI arquitecto, IBM
quinta-feira, março 20, 2008
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:
FURPS + sistema de classificação de requisitos
Para auxiliar a categorização utilizamos o modelo FURPS+ [GRA92] que descreve as principais categorias de requisitos:
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:
Fonte/referencias:
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.
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
- 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
Assinar:
Postagens (Atom)
