Guia para Documento de Requisitos€¦ · Web viewOL Informática. Soluções On Line. Documento...

SOL Informática

Soluções On Line

BGMStadium – Sistema de Cobrança

Documento de Requisitos

Autores:Artur Winter

Claudio SantosHelena MendesJuliana Abadia

Rodrigo MachadoVictor Leandro

Wesley Fernandes

Versão 1.6Histórico de Revisão

Data Versão Descrição Autor

16/03/2010 1.1 Desenvolvimento da introdução deste documento Helena Mendes

17/03/2010 1.1 Desenvolvimento dos requisitos funcionais Victor Leandro

18/03/2010 1.2 Inclusão das Convenções, termos e abreviações Helena Mendes

18/03/2010 1.2 Descrição dos usuários Wesley Pedro

18/03/2010 1.2 Desenvolvimento dos requisitos não funcionais Juliana Abadia

18/03/2010 1.3 Descrição geral do sistema Rodrigo Machado

23/03/2010 1.4 Revisão de Conteúdo dos requisitos Helena Mendes

25/03/2010 1.5 Revisão ortográfica, introdução de vocábulos no glossário Artur Winter

26/03/2010 1.6 Correção ortográfica, divisão de perfil, formatação de texto e introdução de vocábulo no glossário Victor Leandro

Versão 1.6 Março/2010

SOL Informática

Soluções On Line

25/05/2010 1.6 Revisão de conformidade de RF com caso de uso Artur/Helena


Sumário

Visão geral deste documento...................................................................................................1

Convenções, termos e abreviações.........................................................................................1NF001................................................................................................................................ 2Usabilidade- Consistência na Interface...................................................................................2NF002................................................................................................................................ 2Segurança – Criptografia......................................................................................................21. Identificação dos Requisitos.......................................................................................32. Prioridades dos Requisitos.........................................................................................4

Referências................................................................................................................................ 4

Abrangência e sistemas relacionados.....................................................................................1

Descrição dos usuários............................................................................................................2

Usabilidade................................................................................................................................ 1Usabilidade.NF001 - Consistência na Interface................................................................1Usabilidade.NF002 - Aparência.........................................................................................1

Confiabilidade............................................................................................................................ 1Confiabilidade.NF003 – Falhas Transitórias e Permanentes............................................1Confiabilidade.NF004 – Falhas Recuperáveis e Irrecuperáveis........................................1Confiabilidade.NF005 – Falhas de Corrompimento e Não corrompimento.......................1

Desempenho.............................................................................................................................. 2Desempenho.NF006 – Tempo de Resposta.....................................................................2Desempenho.NF007 – Tempo Real..................................................................................2

Segurança.................................................................................................................................. 2Segurança.NF008 – Perfis do Usuário..............................................................................2Segurança.NF009 – Criptografia.......................................................................................2Segurança.NF010 – Autenticação.....................................................................................2

Distribuição................................................................................................................................ 3Distribuição.NF011 – Versão.............................................................................................3

Padrões...................................................................................................................................... 3Padrões.NF012 – Padrões Utilizados...............................................................................3

Hardware e software.................................................................................................................. 3Hardware e Software.NF013 – Banco de Dados...............................................................3Hardware e Software.NF014 – Linguagem.......................................................................3

Manutenibilidade....................................................................................................................... 4Manutenibilidade.NF015...................................................................................................4Manutenibilidade.NF016...................................................................................................4


Documento de Requisitos Introdução – P1 / 1

Introdução

Este documento especifica o sistema BGMStadium – Sistema de Cobrança, fornecendo aos desenvolvedores as informações necessárias para o projeto e implementação, assim como para a realização dos testes e homologação do sistema.Além disso, tal documento pode ser visto como um contrato entre o cliente e o gerente de projeto, pois valida a conformidade segundo a especificação de requisitos do cliente para definição do escopo.

“ Os requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais. Esses requisitos refletem as necessidades dos clientes de um sistema que ajuda a resolver algum problema, por exemplo, controlar um dispositivo, enviar um pedido ou encontrar informações. O processo de descobrir, analisar, documentar e verificar esses serviços e restrições é chamado de Engenharia de Requisito(RE – Requeriments Engenharia)”

Sommerville.Ian, Engenharia de software 8.ed.2007.

Visão geral deste documentoEsta introdução fornece as informações necessárias para fazer um bom uso deste documento, explicitando seus objetivos e as convenções que foram adotadas no texto, além de conter uma lista de referências para outros documentos relacionados. As demais seções apresentam a especificação do sistema BGMStadium e estão organizadas como descrito abaixo. Capitulo 1 – Descrição geral do sistema: apresenta uma visão geral do sistema,

caracterizando qual é o seu escopo e descrevendo seus usuários. Capitulo 2 – Requisitos funcionais (casos de uso): especificam todos os requisitos

funcionais do sistema, descrevendo os fluxos de eventos, prioridades, atores, entradas e saídas de cada caso de uso a ser implementado.

Capitulo 3 – Requisitos não funcionais: especifica todos os requisitos não funcionais do sistema, divididos em requisitos de usabilidade, confiabilidade, desempenho, segurança, distribuição, adequação a padrões e requisitos de hardware e software.

Convenções, termos e abreviaçõesA correta interpretação deste documento exige o conhecimento de algumas convenções e termos específicos, que são descritos a seguir:Convencionou-se que usaríamos o padrão IEEE/ANSI 830-1993, que propõe que o documento seja estruturado da seguinte forma:

Introdução: propósito do documento, visão geral do documento, convenções, termos e abreviações, referências;

Descrição geral: perspectiva do produto, funções, características do usuário, restrições de ordem geral, opções de projeto e dependências;

Requisitos específicos: devem ser especificados requisitos funcionais e não funcionais do sistema;

Índice.Por convenção, a referência a requisitos é feita através do nome da subseção na qual eles estão descritos, seguido do identificador do requisito, de acordo com o esquema do item 1.Para estabelecer a prioridade dos requisitos foram adotadas as denominações “essencial”, “importante” e “desejável” definições no item 2.



Termos e abreviações

Descrição:



Casos de uso Identificação e relacionamento das funcionalidades

Desenvolvedores Profissionais que tem a função de codificar o sistema

Dispositivo São também denominados periféricos. Eles permitem a interação do processador com o homem, possibilitando a entrada e/ou a saída de dados

Engenharia de Requisito

Processo para identificação e controle dos requisitos por meio do levantamento e análise

Escopo Documento que define as diretrizes de um projeto

Hardware Parte física dos equipamentos de informática

Homologação Validação e aceite do cliente

Implementação É a elaboração e preparação dos módulos necessários à sua execução.

Login É a chave de acesso à um determinado sistema computacional, onde o usuário possui um nome de usuário e uma senha para validação.

MySQL É um sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem SQL (Linguagem de Consulta Estruturada, do inglês Structured Query Language) como interface. É atualmente um dos bancos de dados mais populares, com mais de 10 milhões de instalações pelo mundo.

NF001 Usabilidade- Consistência na Interface

NF002 Usabilidade- Aparência

NF003 Confiabilidade–Falhas Transitóriase Permanentes

NF005 Confiabilidade – Falhas de Corrompimento e Não corrompimento

NF006 Desempenho – Tempo de Resposta

NF007 Desempenho – Tempo Real

NF008 Segurança – Perfis do UsuárioNF009 Segurança – Criptografia

NF010 Segurança – Autenticação

NF011 Distribuição – Versão

NF012 Padrões

NF013 Hardware e Software – Banco de Dados

NF014 Hardware e Software – Linguagem

Requisitos Necessidades funcionais e não funcionais do cliente

RF Requisito FuncionalRF001 Manter clientes

RF002 Manter devedores

RF003 Manter funcionários

RF004 Manter perfil dos funcionários

RF005 Controlar movimentações de documentos

RF006 Visualizar relatórios de devedores

RF007 Visualizar relatórios de clientes



RF008 Controlar Sistema financeiro

RF009 Visualizar situação jurídica

RF010 Controlar sistema de atendimento

RF011 Manter carga automática de dados dos clientes

RF012 Emitir relatórios estatísticos

RF013 Supervisionar funcionários cobradores

RF014 Manter Histórico

RF015 Emitir boletos

RF016 Manter a segurança do sistema

RF017 Manter rotinas de lote

SAC Serviço de Atentimento ao Consumidor

Software É uma sequência de instruções a serem seguidas e/ou executadas, na manipulação, redirecionamento ou modificação de um dado/informação ou acontecimento.

1. Identificação dos Requisitos Em termos gerais, os requisitos são classificados em dois tipos:Requisitos funcionais e Requisitos não funcionais:

Alencar (1999: 26) refere-se aos funcionais da seguinte forma:“dizem respeito à definição das funções que um sistema ou um componente de sistema deva fazer. Ou seja, descrevem as transformações a serem realizadas nas entradas de um sistema ou em um de seus componentes, a fim de que se produzam saídas”.

Já em relação aos requisitos não funcionais, o autor informa que eles“dizem respeito a restrições, aspectos de desempenho, interfaces com o usuário, confiabilidade, segurança manutenibilidade, portabilidade, padrões etc., bem como aspectos sociais e políticos” (ALENCAR, 1999:26). De forma geral, poderse-ia associar o conceito de requisitos não funcionais à idéia de restrição sobre como os requisitos funcionais são implementados. Em outras palavras, os requisitos funcionais descrevem o que o sistema deve fazer, enquanto os não funcionais descrevem como os requisitos funcionais são implementados.

Apud WAGNER ZAPAROLIMestre em Ciência da Computação - MACKENZIE; Consultor de Sistemas; Colunista em Ciência e Tecnologia do jornal Gazeta de Bebedouro; Professor de Lógica de Programação na UNINOVE

Por convenção, a referência aos requisitos é feita por meio do nome da subseção onde eles estão descritos, seguido do identificador do requisito, de acordo com o esquema abaixo:

[nome da subseção.identificador do requisito]Por exemplo, o requisito [Manter Clientes.RF001] está descrito em uma subseção chamada “Manter Clientes”, em um bloco identificado pelo número [RF001]. Já o requisito não funcional [Tempo de resposta.NF006] está descrito na seção de requisitos não funcionais de Desempenho, em um bloco identificado por [NF006].



2. Prioridades dos RequisitosPara estabelecer a prioridade dos requisitos foram adotadas as denominações “essencial”, “importante” e “desejável”. Essencial é o requisito sem o qual o sistema não entra em funcionamento. Requisitos

essenciais são requisitos imprescindíveis, que têm que serem implementados impreterivelmente.

Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim.

Desejável é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que podem ser deixados para versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que está sendo especificada.

Referências

1. ALENCAR, F. M. R. Mapeando a Modelagem Organizacional em

Especificações Precisas. 1999. Tese de doutorado. Centro de Informática.UFPE,Recife.

2. IEEE/ANSI 830-1993

3. Pressman, Roger S. Engenharia de Software ; São Paulo : Pearson mackon, 1995.

4. Sommerville. Ian Engenharia de software, 8ª edição/ São Paulo: Pearson Addison Wesley,2007.

5. WAGNER ZAPAROLI: Mestre em Ciência da Computação - MACKENZIE; Consultor de Sistemas; Colunista em Ciência e Tecnologia do jornal Gazeta de Bebedouro; Professor de Lógica de Programação na UNINOVE.


Documento de Requisitos Requisitos funcionais – C2. P1 / 1

Capítulo

Descrição geral do sistema

O BGMStadium está sendo desenvolvido com o objetivo de viabilizar o total controle de carteiras de cobrança em andamento. O software é eficiente na otimização da cobrança e apresenta grande agilidade na prestação de contas por meio de relatórios completos e personalizados.

Além disso, você poderá facilmente fornecer informações on-line sobre o posicionamento das carteiras de cobrança ao seu credor, gerando qualidade na prestação de serviço. O sistema é dividido em dois módulos: o módulo Web e o módulo Administrativo. O módulo Web permite ao devedor acompaunhar suas dívidas junto ao sistema e sanar suas dúvidas por meio de um serviço de atendimento ao consumidor. O módulo Administrativo é responsável pelos módulos cliente, administrador, financeiro, atendimento e relatório.

Abrangência e sistemas relacionados1.1 Módulo clientes

No módulo clientes será realizado o cadastro de informações de pessoas físicas e jurídicas dos nossos clientes e seus devedores.

1.2 Módulo financeiroIntegra todos os subsistemas que compõem e envolvem o gerenciamento de valores, são eles:

Cadastro de Contas Bancárias: Por meio do cadastro de contas bancárias será realizado a inclusão das contas bancárias utilizadas pela empresa no sistema, identificando o nome e número do banco, número da agência, número da conta, data de abertura e praça (comp), nome do gerente, telefone, etc.

Cadastro de Tipos de Documento: Por meio do cadastro de tipos de documentos serão inseridos as formas de faturamento e pagamento da empresa, tais como boleto bancário, fatura, cupom fiscal, Cheque à vista, cheque a prazo, cartão de credito, cartão de débito depósito em conta, entre outros de acordo com a política da empresa.

Cadastro de Despesas: Por meio da tela de cadastro de despesas será possível fazer o cadastro dos gastos da empresa. É recomendável o cadastro de todas e quaisquer despesas para que não haja deficiência no controle financeiro dos lançamentos efetuados pela BGMStadium.

Contas a Pagar: Listagem das despesas em aberto no sistema a serem pagas.

Contas a Receber: Listagem das duplicatas em aberto no sistema a serem recebidas. Tais duplicatas serão geradas por meio do cadastro de receitas e dos serviços prestados.

Lançamentos Financeiros: Por meio da tela de lançamentos é possível visualizar todas as parcelas (duplicatas) que foram quitadas no sistema. Além de inclusão de



lançamentos avulsos, edição de duplicatas (parcelas) quitadas e transferência de valores entre as contas bancárias cadastradas.

Fluxo de Caixa: Por meio da tela de fluxo de caixa serão gerados as provisões de saldo final por período. A geração do fluxo de caixa será a principal funcionalidade dentro de um sistema financeiro, permitindo à BGMStadium o controle do saldo bancário.

1.3 Módulo RelatórioO módulo relatório disponibilizará para o cliente todos os dados que ele necessitará para uma futura análise estatística.

1.4 Módulo AdministradorO módulo Administrador terá os seguintes itens em destaques:

Cadastro de Tipos de Pefil: Por meio deste cadastro será possível criar os perfis de acesso ao sistema, definindo quais telas serão visualizadas bem como as ações para os registros relacionados (visualização, edição, inclusão, alteração e exclusão de registros).

Cadastro de Usuários: Por meio do cadastro de usuários será feito o cadastro das informações relevantes aos usuários do sistema, tais como login, senha, e-mail e departamento ao qual o usuário pertence.

Cadastro de Tipos de Agenda: Por meio do cadastro de tipos de agenda será possível relacionar um agendamento com o seu "assunto" (ex. reúnião, almoço, visita) definindo assim qual a finalidade do agendamento.

Cadastro de Prioridades de Agenda: Por meio do cadastro de prioridades de agenda será possível associar um agendamento cadastrado no sistema com a prioridade que o mesmo necessita (ex. baixa, média, alta), definindo assim, para o usuário, a urgência do agendamento.

Cadastro de Tipos de Contato: Por meio do cadastro de tipos de contatos será possível cadastrar varias observações a serem utilizadas no processo de cadastro de contatos para clientes, categorizando assim, os contatos de acordo com os departamentos ao qual cada um pertence dentro da empresa no qual o contato atua.

1.5 Módulo AtendimentoNo módulo atendimento será criado um sistema de SAC, para que os clientes possam sanar suas dúvidas quanto ao processo ou ao sistema, também quanto ao valor devido.

Descrição dos usuáriosOs usuários do sistema BGMStadium – Sistema de Cobrança serão dividios em 5 classes, no qual cada um terá um grau de acessibilidade compatível com a sua função e necessidade, os perfis são:

Administrador – Tem a função de administrar todos os módulos, podendo fazer alterações nos mesmos e impressão de todos os relatórios fornecidos pelo sistema, possibilitando uma administração clara para tomadas de decisões em tempo hábil.



Supervisor – Tem a função de monitorar os recuperadores de credito, fornecendo relatórios de resultados por atendente, por clientes e por devedores.

Financeiro – Supervisiona o departamento financeito em todas as suas diretrizes. Suas permissões são de inclusão e alteração somente dos registros do módulo financeiro.

Administrativo – Gerencia o departamento administrativo controlando as atividades administrativas para que as mesmas tenham êxito em seus objetivos.

Cliente – Pessoa física ou jurídica que utiliza o sistema BGMStadium – Sistema de Cobrança, este terá acesso via web aos relatórios que demonstra o andamento de sua carteira de devedor.

Devedor – É o inadimplente da BGMStadium, que terá acesso via web permitindo assim o acompanhamento de sua dívida, possibilitando também a impressão de boletos bancários.

Cobrador – Funcionário da empresa que terá acesso ao sistema e conhecimento das regras de negócios dos clientes mantenedores.

Capítulo

Requisitos funcionais (casos de uso)

Segundo Sommerville Ian(2007,2), “Requisitos Funcionais são as declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais podem também estabelecer explicitamente o que o sistema não deve fazer.”

RF001: Manter pessoa (clientes)

Este requisito irá fornecer as funcionalidades de inclusão, alteração, consulta e inatividade de um cliente.

Atores: Funcionário e Administrador

Prioridade: Essencial Importante Desejável

RF002: Manter pessoa devedores

Este requisito irá fornecer as funcionalidades de inclusão, alteração, consulta e inatividade de um devedor.





RF003: Manter funcionários

Este requisito irá fornecer as funcionalidades de inclusão, alteração, consulta e inatividade de um funcionário.

Atores: Administrador

Prioridade: EEssencial Importante Desejável

RF004: Manter perfil/cargo

Este requisito irá registrar e definir o nível de permissão dos funcionários da empresa.



RF005: Manter documentos

Este requisito irá controlar todo o sistema de movimentação documental relativos a todas as operações de controle, bem como, cheques e acordos.



RF006: Consultar devedor

Este requisito irá consultar o devedor e sua situação dentro da empresa

Atores: Funcionário, Cliente e Administrador


RF007 Consultar clientes mantenedores

Este requisito por meio dos funcionários irá consultar os clientes mantenedores que possuem contrato com a empresa





RF008: Manter Sistema financeiro

Este requisito irá controlar todas as entradas e saídas referentes ao caixa da empresa. Servirá também para controle de renegociações.



RF009: Consultar situação jurídica

Este requisito irá servir como meio de consulta da situação jurídica do inadimplente.

Atores: Funcionário e Administrador.


RF010: Manter sistema de atendimento

Este requisito irá oferecer suporte ao atendente da empresa, como também, controlar os atos do mesmo e com o objetivo focado em oferecer o suporte para o nosso cliente.



RF011: Carga automática dos dados pessoa (devedor)

Este requisito irá oferecer suporte à importação de dados da empresa que já possui sistema de controle de devedores.



RF012: Imprimir relatórios:

Funcionalidade que dará acesso às impressões de relatórios disponíveis referente ao perfil.

Atores: Funcionário, Cliente e Administrador


RF013: Supervisionar funcionários Recuperadores de Crédito.



Este requisito irá oferecer suporte ao funcionário supervisor na tarefa de controle e orientação dos Recuperadores de Crédito da empresa, como também, controlar a distribuição de suas tarefas.



RF014: Manter histórico

Este requisito irá controlar todos os atendimentos da empresa bem como qualquer operação feira nos documentos do cliente, mantendo dados atualizados e disponíveis para decisões futuras ou relatórios estatísticos.

Atores: Supervisor e Atendente.


RF015: Emitir / Imprimir boletos

Este requisito irá gerar e imprimir uma cobrança mensal conforme contrato.

Atores: Funcionário, Devedor e Administrador


RF016: Manter backup/integridade do sistema

Este requisito irá oferecer funcionalidades de agendamento e consulta de backup



RF017 Manter as rotinas de batch.

Este requisito irá oferecer suporte ao envio automático de mensagens com lembretes variados de eventos a acontecer e baixa automática de títulos bancários agendados.




Documento de Requisitos <Opcional> Descrição da interface com o usuário – C4. P1 / 1

Capítulo

Requisitos não funcionais

Requisitos não funcionais, segundo KIRNER & DAVIS (1996), representam requisitos adicionais que definem as qualidades globais ou atributos a serem exibidos pelo sistema resultante. Segundo TURINE & MASIERO (1996), os requisitos não funcionais, também denominados requisitos de qualidade, incluem tanto limitações no produto (desempenho, confiabilidade e segurança) como limitações no processo de desenvolvimento (custos, métodos a serem adotados no desenvolvimento e componentes a serem reutilizados).Para CYSNEIROS (1997), os requisitos não funcionais, ao contrário dos funcionais, não expressam nenhuma função a ser realizada pelo software, e sim comportamentos e restrições que este software deve satisfazer.

Usabilidade

Usabilidade.NF001 - Consistência na InterfaceA interface com o usuário é de vital importância para o sucesso do sistema. Deverá ter uma interface amigável ao usuário primário sem se tornar cansativa aos usuários mais experientes.


Usabilidade.NF002 - AparênciaA tela seguirá o padrão de desenvolvimento com tela cinza e botões 3D


Confiabilidade

Confiabilidade.NF003 – Falhas Transitórias e Permanentes O sistema deverá identificar as falhas de inserção de entrada de dados, utilizando padrão de mensagens.


Confiabilidade.NF004 – Falhas Recuperáveis e Irrecuperáveis O sistema deverá identificar as falhas de cunho da intervenção da ação do usuário.


Confiabilidade.NF005 – Falhas de Corrompimento e Não corrompimento O sistema deverá identificar as falhas de inconsistência, pois o problema poderá ser da rede ou físico do equipamento.




Desempenho

Desempenho.NF006 – Tempo de RespostaAs páginas web não devem levar mais de 05 segundos para serem carregadas no navegador durante o uso normal do sistema.


Desempenho.NF007 – Tempo RealO sistema deverá agir de acordo com o tempo de sincronismo da plataforma cliente/ servidor.


Segurança

Segurança.NF008 – Perfis do UsuárioOs perfis do usuário para acessar o sistema são:a) Administrador – Irá administrar todos os módulos e terá permissão para inclusão,

exclusão, consulta e alteração de todo e qualquer registro.

b) Supervisor – Terá a permissão de inclusão, exclusão, consulta e alteração somente dos registros criados pelo o mesmo e poderá consultar e alterar registros criados por membros de seu departamento.

c) Cliente – Fará consultas e/ou inserção de devedores no Sistema BGMStadium via Web.

d) Devedor – Terá acesso somente às consultas do andamento processual de seus negócios, via Web.

e) Cobrador – Funcionário da empresa que irá efetuar o cadastro dos atendimentos, podendo incluir, alterar e consultar os registros.


Segurança.NF009 – CriptografiaAs senhas serão criptografadas para segurança do cliente.


Segurança.NF010 – AutenticaçãoA cada 5 minutos sem utilização dos sistema o mesmo solicitará autenticação do usuário.




Distribuição

Distribuição.NF011 – VersãoO versionamento do sistema será realizado, após uma cadeia/ conjunto de mudanças indicados por marcadores (checkpoint).


Padrões

Padrões.NF012 – Padrões UtilizadosO sistema deve obedecer aos seguintes padrões:a) Lei do Software – 9.609b) W3C Webc) IEEE 829d) Plataforma de Acessibilidade Padrão (norma ISO-9386-1 / NBR15655-1).


Hardware e software

Hardware e Software.NF013 – Banco de Dados

O sistema deverá utilizar banco de dados MySQL.


Hardware e Software.NF014 – Linguagem

Visando criar um produto com maior extensibilidade, reusabilidade e flexibilidade, deve ser adotada como linguagem principal de desenvolvimento Java, seguindo cuidadosamente as técnicas de orientação a objetos. Entretanto, outras linguagens também poderão ser usadas quando indicações técnicas recomendem. O uso da linguagem Java permite não especificar qual será o sistema operacional e a máquina em que o programa irá executar. No entanto, essa máquina deverá se comunicar com um sistema de banco de dados.




Manutenibilidade

Manutenibilidade.NF015Manutenções no aplicativo não descritos nesse documento será de responsabilidade do cliente.


Manutenibilidade.NF016Treinamento será efetuado a cargo da empresa desenvolvedora.



Guia para Documento de Requisitos€¦ · Web viewOL Informática. Soluções On Line. Documento...

Documents

Transcript of Guia para Documento de Requisitos€¦ · Web viewOL Informática. Soluções On Line. Documento...