Documento de Visao de Softwarewilliam/Disciplinas 2016-2/BSI-GSI030... · Web viewO digrama de caso de uso a seguir mostra os casos de uso gerais do sistema e suas iterações. Requisitos

DOCUMENTO DE REQUISITOS DE SOFTWARE

PROJETO [NOME DO PROJETO]

Documento de Requisitos de Software Data: 13/5/2023Página 2 de 36

Versão: 1.0

Conteúdo

1 INTRODUÇÃO........................................................................................................5

2 OBJETIVO E ESCOPO..............................................................................................5

3 REQUISITOS NÃO-FUNCIONAIS RELACIONADOS.......................................................7

4 ARQUITETURA E SISTEMAS RELACIONADOS............................................................8

4.1 ARQUITETURA DA APLICAÇÃO......................................................................................................84.2 TECNOLOGIAS DE HARDWARE E SOFTWARE UTILIZADAS..................................................................10

5 PREMISSAS E RESTRIÇÕES...................................................................................11

6 ESPECIFICAÇÃO FUNCIONAL.................................................................................13

6.1 RF0001 – AUTENTICAÇÃO E AUTORIZAÇÃO.................................................................................136.2 RF0002 – MANUTENÇÃO DE USUÁRIOS E GRUPOS.......................................................................136.3 RF0003 – CONFIGURAÇÃO DO SISTEMA.....................................................................................146.4 RF0004 – PROJETO – CRIAR PROJETO.......................................................................................146.5 RF0005 – PROJETO – REMOVER PROJETO..................................................................................166.6 RF0006 – PROJETO – ALTERAR PROJETO...................................................................................166.7 RF0007 – PROJETO – LISTAR PROJETOS.....................................................................................166.8 RF0008 - PROJETO – GERAR RELATÓRIO DE PROJETOS.................................................................186.9 RF0009 – FARM – CRIAR FARM...............................................................................................186.10 RF0010 – FARM – REMOVER FARM..........................................................................................206.11 RF0011 – FARM – ALTERAR FARM............................................................................................206.12 RF0012 – POOL – CRIAR POOL................................................................................................206.13 RF0013 – POOL – REMOVER POOL...........................................................................................216.14 RF0014 – POOL – ADICIONAR HOST AO POOL.............................................................................216.15 RF0015 – POOL – REMOVER HOST DO POOL..............................................................................216.16 RF0016 – POOL – ASSOCIAR POOL A PROJETO............................................................................226.17 RF0017 – POOL – REMOVER ASSOCIAÇÃO ENTRE POOL E PROJETO..................................................226.18 RF0018 – VM – CRIAR VM....................................................................................................226.19 RF0019 – VM – REMOVER VM................................................................................................226.20 RF0020 – VM – INICIALIZAR VM.............................................................................................226.21 RF0021 – VM – PARAR VM....................................................................................................226.22 RF0022 – TEMPLATE – GERENCIAR TEMPLATES...........................................................................236.23 RF0023 – HOST – COLOCAR HOST EM MANUTENÇÃO...................................................................236.24 RF0024 – HOST – REMOVER HOST DE MANUTENÇÃO...................................................................236.25 RF0025 – VISUALIZAÇÃO DO LOG DE ACESSO E OPERAÇÕES..........................................................236.26 RF0026 – CONSOLE REMOTA..................................................................................................236.27 RASTREABILIDADE ENTRE OS REQUISITOS FUNCIONAIS....................................................................246.28 REQUISITOS DE DOCUMENTAÇÃO...............................................................................................256.29 NÃO REQUISITOS (NÃO ESCOPO)...............................................................................................25

7 RISCOS IDENTIFICADOS.......................................................................................26

Página 2 de 22


Versão: 1.0

1 IntroduçãoEste documento de especificação funcional apresenta as características em termo das funcionalidades do software a ser construído. O presente documento é um compromisso entre o CTI e o solicitante.Após a validação deste documento pelos envolvidos, qualquer alteração no seu escopo implicará em uma análise de impacto e re-planejamento de esforços, caso necessário.

2 Objetivo e escopo

O projeto em questão se destina a desenvolver um front-end web para administração da infra-estrutura de virtualização de servidores adotada pela cliente. O sistema deverá integrar as rotinas de administração presentes na infra-estrutura. Esta integração será realizada por um back-end que será desenvolvido neste projeto.O processo de virtualização está inserido no contexto do processo de orquestração da infra-estrutura. Não se trata apenas de instanciar novas maquinas virtuais, aborda também um trabalho envolvendo diversas equipes para parametrização e alocação de recursos de infra-estrutura.A proposta para o sistema em questão surgiu da necessidade de integração de sistemas e novas interfaces que visam automatizar tarefas hoje realizadas manualmente.O digrama de caso de uso a seguir mostra os casos de uso gerais do sistema e suas iterações.

Página 3 de 22


Versão: 1.0

Página 4 de 22

uc Orquestração de Virtualização

XSVirtualizationManager

Manipulação de Projetos

Manipulação de Farms

Manipulação de Pools

Manipulação de Templates

Manipulação de VMs

Manutencao de Usuarios e Grupos

Manipulação de Hosts

Administrador VM

Gerente VM

Gerente de Pools

Administrador de Projetos

Administrador Pools

Administrador de Recursos de Rede

Administrador de Templates

Administrador de Sistemas

Configuracao Sistema

NetworkAPI

CentralServ icos

Visualizacao do Log de Acesso e Operacoes

XenServerAPI


Versão: 1.0

3 Requisitos não-funcionais relacionados

Requisitos não-funcionais que fazem parte do sistema e que deverão ser considerados para elaboração de sua arquitetura:

Escalabilidade: A solução proposta deverá ser capaz de prover escalabilidade horizontal através do aumento do número de servidores da interface de gerência caso haja um aumento de carga de utilização pelos usuários.

Segurança de acesso: Apenas usuários corporativos da cliente poderão ter acesso ao sistema de gerência. Todas as conexões deverão ter identificação positivas da plataforma de autenticação CADUN. As permissões de usuário deverão ser verificadas pela própria aplicação.

Disponibilidade: o uso do daemon Heartbeart (http://www.linux-ha.org/) proverá a tolerância a falhas necessária para manter a aplicação disponível sem interrupções.

Balanceamento de carga: o balanceamento de máquinas virtuais entre pools e hosts deverá ser feito utilizando uma estratégia simples de round-robin.

Página 5 de 22

http://www.linux-ha.org/


Versão: 1.0

4 Arquitetura e sistemas relacionados

4.1 Arquitetura da aplicação

A figura abaixo mostra a arquitetura proposta para a solução:

Figura 1 - Arquitetura da solução

O front-end de gerenciamento fará uso de banco de dados MySQL para persistência das informações do sistema. O XenServer é uma solução de virtualização que permite o gerenciamento de máquinas virtuais, gerenciamento de pools e utilização de storages. O XenServer suporta pools com até 16 hosts (na figura, os VM Hosts).

Página 6 de 22


Versão: 1.0

O servidor de configurações de rede é o elemento da arquitetura que controla a alocação de endereços IP para as máquinas virtuais. Para integração do front-end com este servidor, a cliente disponibilizou a Network API.O back-end é responsável pela integração do front-end com com o XenServer através da XenEnterprise Management API e com o servidor de configurações de rede através da Network APIEste front-end, o back-end e as integrações necessárias compreende o escopo da proposta que será desenvolvido pela XXX.4.2 Tecnologias de hardware e software utilizadas

Descrição Versão Utilização Disponibilidade

Python 2.6 Pacote de desenvolvimento e execução do aplicativo.

http://www.python.org/

Django 1.0.2 Framework para desenvolvimento de aplicações web em Python

http://www.djangoproject.com/

XenServer Enterprise

4.1 Plataforma de gerência de máquinas virtuais

Citrix XenServer

memcached 1.2 Sistema distribuído de cache de objetos em memória

http://www.tummy.com/Community/software/python-memcached/

XenEnterprise Management API

1.1 API para acesso ao servidor Xen Fornecida pela cliente

Network API N/A API interna cliente para acesso à recursos de rede

Fornecida pela cliente

MySQL 5.1 Servidor de banco de dados http://dev.mysql.com/downloads/mysql/5.1.html

Tabela 1 - Tecnologias envolvidas

Página 7 de 22

http://dev.mysql.com/downloads/mysql/5.1.html



http://www.citrix.com/lang/English/lp/lp_1688615.asp

http://www.djangoproject.com/

http://www.python.org/


Versão: 1.0

5 Premissas e restrições

RNF0004 – Todo e qualquer requisito funcional ou não funcional do projeto que seja de responsabilidade de outros fornecedores contratados pela cliente, bem como do próprio, deverão estar devidamente implementados, testados, homologados e entregues à equipe de desenvolvimento da XXX. O prazo máximo para a entrega destes requisitos é até dois dias úteis anteriores à data de início da fase de construção do projeto, caso essa premissa não seja atendida o projeto será paralisado até que todos os requisitos sejam entregues impactando na data final de entrega do projeto.

RNF0005 – Todo e qualquer requisito funcional ou não funcional do projeto que seja de responsabilidade de outros fornecedores contratados pela cliente, bem como do próprio, não será testado, bem como modificado ou ajustado pela equipe de desenvolvimento da XXX. Caso sejam solicitadas modificações e ajuste a requisitos dessa natureza será realizado um cálculo de esforço necessário para a realização das modificações e/ou ajustes e será também avaliada a modificação da data final do projeto.

RNF0006 – Toda e qualquer mudança de escopo do projeto sofrerá uma análise detalhada prévia a sua aceitação e poderá acarretar em uma mudança de esforço de desenvolvimento e prazo de entrega do projeto e que deverá ser devidamente apresentada à Gerência de Desenvolvimento da XXX e aprovada pela mesma.

RNF0007 – Toda e qualquer solicitação de ajustes de requisitos funcionais ou não funcionais do projeto deverão ser enviadas ao Gerente do Projeto para análise de impacto podendo ou não ser aprovada para execução.

RNF0008 – Para execução do projeto a cliente dará todo suporte e orientação para a instalação e configuração do servidor de homologação da XXX para que este esteja com as mesmas configurações do ambiente de homologação utilizado pelo mesmo.

RNF0009 – Para que a cliente possa homologar o projeto deverá ser realizado o deploy das aplicações em seus servidores de homologação.

RNF0010 – Todo o processo de homologação será assistido pela equipe da XXX. RNF0011 – Todo o processo de homologação terá prazo de início e fim estabelecidos em

cronograma. Se durante o prazo de homologação não for reportado nenhum ajuste ou correção de erro à equipe de desenvolvimento da XXX, será assumido que o sistema foi homologado e está de acordo com o esperado e definido nos documentos.

RNF0012 – Toda correção do sistema identificada no processo de homologação será realizada no menor tempo possível pela equipe de desenvolvimento da XXX.

RNF0013 – A cliente ficará responsável por fornecer a API a ser utilizada para o acesso ao servidor de autenticação CADUN. Modificações e/ou melhorias nesta API não fazem parte do escopo do projeto.

Página 8 de 22


Versão: 1.0

RNF0014 - A instalação e/ou configuração dos servidores de load balancing ficará a cargo da cliente.

RNF0015 – A cliente ficará responsável por fornecer a API NetworkAPI. Modificações e/ou melhorias nesta API não fazem parte do escopo do projeto.

RNF0016 – É necessário que a cliente forneça logo no inicio do projeto acesso a um ambiente de desenvolvimento a fim de que seja possível a realização de testes de uso tanto da NetworkAPI quanto da infra-estrutura de pools, hosts e VMs já existente em seu ambiente através da Xen API.

RNF0017 – É necessário que cada uma das premissas descritas acima esteja devidamente satisfeitas no inicio de desenvolvimento do projeto para que o mesmo não sofra impacto no esforço de desenvolvimento e prazo de entrega.

Página 9 de 22


Versão: 1.0

6 Especificação Funcional

6.1 RF0001 – Autenticação e autorização

O acesso ao sistema de gerenciamento deverá ser feito somente por usuários corporativos devidamente autenticados na plataforma CADUN.As permissões dos usuários autenticados serão verificadas pela própria aplicação.

6.2 RF0002 – Manutenção de usuários e grupos

Funcionalidade que permite o Administrador do Sistema cadastrar usuários e grupos de usuários. Para o cadastro de usuários, deverá ser informado o nome (conforme utilizado no CADUN) e os grupos ao qual deverá pertencer. Para o cadastro de grupo, deverá ser informado o nome do grupo e as operações permitidas para o mesmo.O sistema possuirá os seguintes grupos e permissões:

Gerente de VMo Parar VM, Iniciar VM e utilizar o Console Remoto.

Administrador VM o Criar VM, Remover VM. Além disso, herda permissões do Gerente de VM

Gerente de Pools o Colocar Host em Manutenção, Remover Host de Manutenção. Além disso, herda

permissões do Gerente de VM Administrador de Pools

o Criar Pool; Remover Pool; Adicionar Host ao Pool; Remover Host do Pool; Associar Pools a Projetos; Remover Associação entre Pool e Projeto. Além disso, herda permissões do Gerente de Pools

Administrador de Projetoso Criar Projeto, Remover Projeto, Alterar Projeto, Listar Projetos, Gerar Relatório de

Projetos, Criar Farms, Alterar Farms, Remover Farms. Além disso, herda permissões do Administrador VM

Administrador de Recursos de Redeo Alterar Farms (Adiciona e Altera VLAN das Farms)

Administrador do Sistemao Manutenção de Usuários e Grupos e Configuração do Sistema

Administrador de Templateso Gerenciar Templates

O diagrama abaixo mostra as relações de herança de permissões entre os grupos:

Página 10 de 22uc Users and Roles

Administrador VM

Gerente VM Gerente de Pools


Administrador Pools



Administrador do Sistema


Versão: 1.0

6.3 RF0003 – Configuração do sistema

Funcionalidade que permite o Administrador do Sistema definir os parâmetros de configuração para o mesmo. Os seguintes parâmetros foram identificados até o momento:

Sufixo utilizado para nomes de VLAN para instalação de máquinas virtuais; Emails dos grupos de suporte e operação; Usuário para acesso via SSH às máquinas virtuais e hosts.

6.4 RF0004 – Projeto – Criar Projeto

Este requisito atende a criação de um novo projeto de virtualização. A criação de um novo projeto é ligada ao mapeamento dos recursos computacionais necessários fornecidos por parte do novo projeto. Depois de mapeado, o objeto projeto facilita a preparação de templates e quantidade de maquinas virtuais necessárias para cada tipo de serviço solicitado. O objeto projeto é também uma abstração do sistema para facilitar a busca dos recursos alocados podendo-se abstrair a partir deste objeto o número de máquinas virtuais alocadas e em atividade e qual sua localização exata (em que host cada maquina virtual está ativa).

A criação de um projeto consiste em definir seu nome e as farms que farão parte do mesmo. Os detalhes de criação da farm estão descritos na RF0009 – Farm – Criar Farm.

Página 11 de 22

uc Users and Roles

Administrador VM

Gerente VM Gerente de Pools


Administrador Pools



Administrador do Sistema

Figura 2 – Relacionamento entre os papéis de cada usuário


Versão: 1.0

Depois de criado um projeto, o sistema deverá automaticamente enviar um email para o grupo de usuários administradores de pool para notificar que um novo projeto foi criado e que um pool deverá ser associado ao mesmo.O projeto conterá as seguintes propriedades:

nome Finalidade (Produção/Homologação/Desenvolvimento) FARM(n)

A figura abaixo mostra uma proposta da tela do sistema para a criação de projetos:

6.5 RF0005 – Projeto – Remover Projeto

Este requisito atende a remoção um projeto de virtualização do sistema. Para remover um projeto do sistema é obrigatório que não exista nenhuma maquina virtual instanciada dos templates do projeto. O processo remove definitivamente todos os templates e também as VLANs dos pools.

Página 12 de 22

Figura 3 - Tela para Criação de Projeto


Versão: 1.0

6.6 RF0006 – Projeto – Alterar Projeto

Este requisito permite a alteração de um projeto já existente. Deve ser possível adicionar novas farms ou remover farms existentes.

6.7 RF0007 – Projeto – Listar Projetos

Este requisito contempla a listagem de projetos existentes, para exibição na página inicial do sistema de gerenciamento. Deverá ser exibido o nome do projeto, o nome das farms do projeto e o status das mesmas.A figura abaixo mostra uma proposta desta tela do sistema:

A partir desta tela será possível visualizar informações sobre todos os objetos do sistema como Farms, Pools, Hosts e VMs.A figura a seguir mostra uma proposta de tela para a visualização das FARMS de um projeto.

Página 13 de 22

Figura 4 - Tela Listagem de Projetos


Versão: 1.0

A figura a seguir mostra uma proposta de tela para a visualização dos POOLS associados a um projeto:

6.8R

F0008 - Projeto – Gerar Relatório de Projetos

Este requisito contempla a geração de relatórios de projetos, nos quais devem constar as informações dos componentes associados ao mesmo (farms, pools, hosts e virtual machines), bem como um sumário dos recursos (memória, espaço em disco) utilizados por cada projeto.

Página 14 de 22

Figura 5 - Tela para Visualização das Farms

Figura 6 - Tela para Visualização dos Pools


Versão: 1.0

6.9 RF0009 – Farm – Criar Farm

Este requisito contempla a criação de uma nova farm. Uma farm representa um modelo de configuração que é utilizado para a criação de uma nova máquina virtual. Um projeto pode conter várias farms, e as farms podem fazer uso de todos os pools associados ao projeto para criar uma nova VM.A farm conterá as seguintes propriedades:

nome memoria disco numero de instancias uso IO (1-Baixo, 2-Medio, 4-Alto) usoCPU (1-Baixo, 2-Medio, 4-Alto) versaoSO interfaces de rede (frontend / backend) tipo(BE,FE) vlan ip vip (n) nome do serviço Área de negócio Cliente do serviço (Usuário Web/Usuário VPN/Usuário interno/Servidor Interno) Host (FQDN) Número máximo de conexões Porta de acesso URL Health check Ips dos servidores de Transbordo (Lista de valores possíveis) Utilizar um pool de cache (Sim/Não) Requer persistência de conexão (Sim/Não)

A figura a seguir propõe uma tela para criação das farms:

Página 15 de 22


Versão: 1.0

6.10 RF0010 – Farm – Remover Farm

Este requisito contempla a remoção de uma farm de um projeto. Para que uma farm seja removida, não deve haver nenhuma VM instanciada a partir da mesma.

6.11 RF0011 – Farm – Alterar farm

Este requisito contempla a alteração dos atributos de uma farm já existente.Enquanto a primeira máquina virtual não tenha sido criada em um projeto será possível alterar os dados da farm conforme cada perfil do sistema.

Página 16 de 22

Figura 7 - Tela para Criação e Alteração de Farms


Versão: 1.0

Após criar a primeira VM será possível alterar apenas alguns dados da farm como: Memória, Nome e Número de Instância. No caso de alteração da memória será necessário reiniciar as VMs a fim de que tenham nova configuração.

6.12 RF0012 – Pool – Criar pool

Este requisito atende a criação de pool. Um pool é um conjunto de recursos (hosts), o qual pode ser alocado para atender um ou mais projetos. Efetivamente um projeto só poderá criar máquinas virtuais em uma de suas farms a partir do momento em que um ou mais pools tenham sido criados e associados ao mesmo. Um pool, ao ser criado, deve conter pelo menos um host, que será o host master do mesmo. Um pool tem como atributos:

VIP Hosts (n) Usuário para acesso aos hosts do pool Senha (gerada automaticamente) para acesso aos hosts do pool Rede Física (DEV/QA ou STAGING/PRODUÇÃO)

A figura abaixo mostra uma proposição de tela para a criação de pools:

6.13 RF0013 – Pool – Remover pool

Este requisito permite a remoção de um pool. Para que um pool seja removido e não esteja mais associado a um ou mais projetos, não pode haver máquinas virtuais instanciadas nos hosts presentes no mesmo.

Página 17 de 22

Figura 8 - Tela para Criação e Alteração de Pools


Versão: 1.0

6.14 RF0014 – Pool – Adicionar host ao pool

Este requisito permite adicionar um novo host a um pool. Um pool pode conter no mínimo dois e no máximo 16 hosts. O primeiro host informado no momento da criação do pool é o host master, e o segundo, o host slave. Para que um host seja adicionado, deve ser informado o seu nome (FQDN). Uma vez que um host esteja em um pool, um projeto associado ao último poderá utilizar o host para instanciar novas máquinas virtuais.

6.15 RF0015 – Pool – Remover host do pool

Este requisite permite remover um host de um pool. Um pool deverá ter no mínimo dois hosts. Não é possível a remoção do host master ou do host slave. Para a remoção de um host do pool, o host em questão não poderá ter alocado nenhuma maquina virtual. Durante o processo de retirada, todas as máquinas virtuais deverão ser evacuadas ou removidas do host para que seja possível a remoção.

6.16 RF0016 – Pool – Associar pool a projeto

Este caso de uso permite a associação de um pool a um ou mais projetos. Um projeto só poderá criar máquinas virtuais em uma de suas farms a partir do momento em que um ou mais pools tenham sido criados e associados ao mesmo.

6.17 RF0017 – Pool – Remover associação entre pool e projeto

Este caso de uso permite remover a associação entre um pool e um projeto. Para que isto ocorra, não poderá haver máquinas virtuais do projeto instanciadas nos hosts do pool. O pool não é removido, podendo continuar associado a outros projetos.

6.18 RF0018 – VM – Criar VM

Este requisito contempla a criação de uma nova máquina virtual. Uma máquina virtual é sempre criada a partir de uma farm, a qual contém o modelo para a criação da VM. Ao receber a requisição de criação de nova VM, o sistema deverá respeitar o limite de instâncias definido no momento da criação da farm. O processo de criação e configuração de rede da VM será totalmente automatizado, através do uso da API de acesso ao hypervisor (XenAPI) e da API de acesso às configurações de rede (Network API). No momento da criação da VM, o sistema deverá automaticamente escolher o pool e o host adequados para a mesma, baseado numa estratégia round-robin. O sistema deverá estar preparado para alterar a estratégia de escolha de pool/host no futuro. A criação de VM deverá ocorrer de forma assíncrona, num processo separado do front-end de gerenciamento. O usuário poderá acompanhar o status da criação através do front-end.

Página 18 de 22


Versão: 1.0

6.19 RF0019 – VM – Remover VM

Este requisito permite remover uma instância de máquina virtual presente no sistema.

6.20 RF0020 – VM – Inicializar VM

Este requisito contempla a inicialização (reboot) de uma máquina virtual recém criada ou desligada.

6.21 RF0021 – VM – Parar VM

Este requisito permite solicitar ao hypervisor que realize o shutdown de uma determinada máquina virtual.

6.22 RF0022 – Template – Gerenciar templates

Este requisito permite gerenciar os templates disponíveis durante a criação de uma nova farm.O sistema deverá manter as seguintes informações dos templates:

Label do template (o qual irá corresponder à versão do SO); Caminho do repositório NFS do template; Arquivo de quickstart da VM.

6.23 RF0023 – Host – Colocar host em manutenção

Este caso de uso permite alterar o status de um host em um pool de ativado para desativado. Isto corre quando a monitoração identifica algum problema com hardware ou quando há necessidade de desligamento físico do servidor. Após o host ter sido selecionado, o sistema deve requisitar ao hypervisor para colocar host em estado de manutenção para não receber mais máquinas virtuais enquanto estiver em manutenção. O host não deverá possuir VMs ativas para ser colocado em manutenção.

6.24 RF0024 – Host – Remover host de manutenção

Permite colocar o host em estado ativo novamente depois de concluída a manutenção. O sistema deverá comunicar ao hypervisor para retirar o host do estado de manutenção.

6.25 RF0025 – Visualização do log de acesso e operações

Funcionalidade que irá permitir ao administrador do sistema visualizar os acessos logados no sistema, bem como as operações efetuadas sobre os objetos do sistema (adição,remoção e atualização).

Página 19 de 22


Versão: 1.0

6.26 RF0026 – Console Remota

Esta funcionalidade permitirá visualizar e interagir com o console de uma máquina virtual. Seu objetivo é permitir o acesso à máquina virtual, através da XenAPI, ainda que a mesma esteja fora da rede.O console estará disponível no front-end para acesso via web e será feito somente por perfis que possuam tal permissão. As informações que são mostradas na console são obtidas a partir XenAPI, porém será necessário a construção de um serviço no back-end que atuará como um gateway a fim encaminhar apenas os dados do protocolo RFB (Remote Frame Buffer) via TCP/IP em uma porta que será instanciada em tempo de execução do serviço para acesso especifico ao console desta máquina virtual. Esta conexão, disponibilizada pelo serviço, será encerrada no momento em que a console for finalizada ou ficar inativa por um período. Para o acesso aos dados da console o serviço produzirá uma senha aleatória que será devolvida para o front-end. O serviço será responsável por servir o console de várias máquinas virtuais de forma simultânea.

6.27 Rastreabilidade entre os requisitos funcionais

Requisito Fonte Dificuldade

RastreablidadeRF0001 Cliente Baixa TodosRF0002 Cliente Média RF0001RF0003 Cliente Baixa RF0004, RF0005, RF0006, RF0007, RF0008

RF0004 Cliente Baixa RF0003RF0005 Cliente Baixa RF0003RF0006 Cliente Média RF0003RF0007 Cliente Média RF0003, RF0009, RF0012RF0008 Cliente Baixa RF0003RF0009 Cliente Alta RF0022, RF0001, RF0010, RF0011RF0010 Cliente Média RF009RF0011 Cliente Média RF009RF0012 Cliente Alta RF0013, RF0014, RF0015, RF0016,

RF0013 Cliente Média RF0012RF0014 Cliente Baixa RF0012RF0015 Cliente Baixa RF0012RF0016 Cliente Média RF0001, RF0012RF0017 Cliente Baixa RF0016, RF0001, RF0012RF0018 Cliente Alta RF0001, RF0009, RF0012, RF0016, RF0019, RF0020, RF0021

RF0019 Cliente Média RF0018RF0020 Cliente Baixa RF0018RF0021 Cliente Baixa RF0018RF0022 cliente Baixa RF009

Página 20 de 22


Versão: 1.0

RF0023 cliente Média RF0014RF0024 cliente Baixa RF0023RF0025 cliente Baixa TodosRF0026 cliente Alta RF0018

6.28 Requisitos de documentação

Requisito Responsável Dificuldade Prioridade

Casos de uso XXX Média Alta

Especificação técnica XXX Média Alta

Plano de testes XXX Média Média

Manual de usuário XXX Baixa Baixa

Manual de operação XXX Baixa Baixa

Tabela 2 – Documentação

6.29 Não requisitos (Não escopo)

Sigla Descrição Responsável Observação

NR0001 Alta disponibilidade das maquinas virtuais Será contemplada em proposta futura.

NR0002 Algoritmo de load balancing para escolha de pools e hosts baseados em pesos de acordo com o perfil da VM

Será contemplada em proposta futura.

NR0003 Integração com a API de monitoração Será contemplada em proposta futura.

NR0004 Regras de validação a fim de indicar se o pool tem capacidade para prover os requisitos de uma farm associada ao mesmo


NR0005 Configuração e utilização de regras de notificação para as várias equipes envolvidas baseadas em SLA e ordem de acionamento de cada equipe, definida no próprio sistema


Página 21 de 22


Versão: 1.0

NR0006 Criação de novos templates e geração dos mesmos a partir de uma instalação já existente de um VM


NR0007 Construção de um workflow a fim de notificar os envolvidos no processo sobre o status de cada atividade

N/A

Tabela 3 - Não requisitos

7 Riscos Identificados

Id Descrição Contingência Requisitos afetados

R0001 A Network API ainda está em desenvolvimento e não foi completamente testado, o que pode causar atraso no desenvolvimento das funcionalidades que dependem da mesma.

A XXX e a cliente deverão negociar uma nova data de entrega, caso se verifique impacto no desenvolvimento causado pela Network API.

RF0009,RF0010,RF0011, RF0018,RF0019,RF0020, RF0021

R0002 O ambiente de desenvolvimento que permite o aceso à infra-estrutura de rede (via Network API) e infra-estrutura de virtualização (via XenAPI) da cliente não ser disponibilizado em tempo hábil para inicio do do projeto pela XXX, causando impacto na data de entrega do sistema.

A XXX e a cliente deverão negociar uma nova data para inicio do projeto baseado na data de disponibilidade do ambiente de desenvolvimento.

Todos

R0003 O ambiente de teste da cliente não ser disponibilizado em tempo hábil para inicio dos testes do projeto pela XXX, causando impacto na data de entrega do sistema.

A XXX e a cliente deverão negociar uma nova data de entrega baseada na data de disponibilidade do ambiente de testes.

Todos

R0004 Indisponibilidade do ambiente de desenvolvimento e testes da cliente

A XXX e a cliente deverão negociar uma nova data de entrega

Todos

Tabela 4 - Riscos

Página 22 de 22

Documents

Documento de Visao de Softwarewilliam/Disciplinas 2016-2/BSI-GSI030... · Web viewO digrama de caso de uso a seguir mostra os casos de uso gerais do sistema e suas iterações. Requisitos