VCAP-DCV Design – Requirements, Assumptions, Constraints and Risks

VCAP-DCV Design – Requirements, Assumptions, Constraints and Risks

Olá pessoal. Estou estudando para o VCAP-DCV Design e, como escrever faz parte do meu processo de aprendizagem, irei escrever vários posts sobre assuntos referentes ao exame (baseado no blueprint).  

Vamos lá, o assunto de hoje será sobre RACR (Requirements, Assumptions, Constraints and Risks).

Requirements (requisitos)

Os requisitos estão divididos entre functional requirements (requisitos funcionais) e non-functional requirements (requisitos não funcionais).

Funcional – Um requisito funcional especifica uma função que um sistema ou componente deve poder executar. São tarefas ou processos que devem ser executados pelo sistema, ou seja, é o que um sistema deve fazer. Por exemplo: “Exibir a frequência cardíaca, pressão arterial e temperatura de um paciente conectado ao monitor do paciente”. No VMware vSphere temos o exemplo: “O sistema precisa inicializar 100 VMs entre as 22:00 e as 23:30” ou “os usuários devem poder criar máquinas virtuais”. Os requisitos funcionais típicos são: regras do negócio, correções de transações, funções administrativas, autenticação, autorização (funções às quais o usuário é delegado a executar), acompanhamento de auditoria, interfaces externas, requisitos de certificação, requisitos de relatório, dados históricos, requisitos legais ou regulamentares.

Não funcional – Um requisito não funcional é uma declaração de como um sistema deve se comportar, é uma restrição ao comportamento do sistema. Os requisitos não funcionais especificam todos os demais requisitos não cobertos pelos requisitos funcionais. Eles especificam critérios que julgam a operação de um sistema, em vez de comportamentos específicos, por exemplo: “A exibição dos sinais vitais do paciente deve responder a uma mudança no status do paciente dentro de 2 segundos”. No VMware vSphere podemos ter o exemplo: “como o sistema deve se comportar para os requisitos de disaster recovery e capacidade”, “o sistema deve equilibrar cargas de trabalho para manter o desempenho distribuído” ou ainda “deve ser criado por um custo total de R$ X”. Requisitos não funcionais são padrões que o sistema deve ter ou cumprir. Os requisitos não funcionais típicos são: desempenho (tempo de resposta, throughput, utilização), escalabilidade, capacidade, disponibilidade, confiabilidade, disaster recovery, facilidade (manutenção e gerenciamento), segurança, regulatório, integridade de dados, usabilidade e interoperabilidade.

Assumptions (suposição / hipótese)

Suposições feitas pelo arquiteto. Basicamente afirmações que foram aceitas como verdade, mas não foram testadas / validadas. Por exemplo: “A temperatura do data center é adequada”, “A infraestrutura básica (Active Directory, DNS, NTP, etc) está instalada e funcionando de forma confiável”, “As licenças serão fornecidas antes do inicio da implementação do projeto” (essa é clássica!) e por aí vai. O arquiteto não tem como garantir que estas afirmações são verdadeiras e por isso, caso não forem validadas, tem potencial para se tornar um risco.

Constraints (restrição / limitação)

É a forma como o design atende aos requisitos. Por exemplo: os equipamentos (servidores, storages, switches, etc) que serão utilizados são pré-definidos pelo cliente, ou seja, a empresa simplesmente decidiu utilizar um fornecedor específico ou o cliente decide que precisa reutilizar alguns equipamentos existentes ou até mesmo limitar o budget. Em outras palavras é o que o cliente diz que precisa e o arquiteto precisa trabalhar com isso. Obviamente que estas restrições podem virar riscos.

Risks (risco)

Quando pode impedir que o projeto seja implementado com sucesso ou atenda aos requisitos planejados. Por exemplo: Budget insuficiente ou não aprovado, dependência de outros projetos, além dos exemplos que falamos acima: “a infraestrutura básica não funciona corretamente” ou “as licenças não estão disponíveis para uso”. Lembre-se de sempre documentar qualquer tipo de risco e compartilhar com quem achar necessário.

Resumão

Os requisitos são divididos em duas partes, sendo um requisito funcional que especifica o que o sistema deve fazer e requisito não funcional que declara como um sistema deve se comportar. Na sequencia temos a suposição e/ou hipótese, onde o arquiteto basicamente assume que a afirmação é verdadeira. Depois vem a restrição e/ou limitação, onde o arquiteto precisa trabalhar com coisas que não foram definidas por ele. E por fim temos o risco, que é qualquer coisa que pode impedir que o projeto/design tenha sucesso. Importante: todos os itens citados podem se tornar riscos para o projeto/design caso não sejam mapeados e tratados corretamente.

É isso aí pessoal, até a próxima! : )

 

Ricardo Conzatti é especialista em TI e apaixonado por Virtualização. É graduado em Sistemas de Informação, pós-graduado em Gestão de TI e acredita muito na teoria da pirâmide de aprendizagem de William Glasser. Ricardo também é blogger, palestrante, podcaster e muito envolvido com comunidades técnicas. Ex-líder do VMUG Paraná e host do vBrownBag Brasil, além de ser VMware vExpert e possuir várias certificações técnicas Microsoft e VMware. Você com certeza irá encontra-lo no twitter @RicardoConzatti.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *