Mudanças entre as edições de "Criando um documento de Casos de uso"
Linha 68: | Linha 68: | ||
=== Integração === | === Integração === | ||
+ | Bem como no tópico de desenvolvimento, é interessante dividir a integração em tópicos, definindo claramente um passo a passo a respeito do que precisa ser feito, por exemplo: | ||
+ | '''- Integrar as informações do cadastro de meta do ERP: ''' | ||
+ | |||
+ | (Descrever aqui o que precisa ser feito) | ||
+ | |||
+ | '''- Salvar as informações do relatório de metas no ERP: ''' | ||
+ | |||
+ | (Descrever aqui o que precisa ser feito) | ||
É interessante que a tabela abaixo seja preenchida, caso se tenha a necessidade de trazer campos do ERP para o GeoSales ou vice versa, de forma a definir e ilustrar a associação de campos entre o ERP e o GeoSales, esclarecendo quaisquer dúvidas a respeito dessa associação. | É interessante que a tabela abaixo seja preenchida, caso se tenha a necessidade de trazer campos do ERP para o GeoSales ou vice versa, de forma a definir e ilustrar a associação de campos entre o ERP e o GeoSales, esclarecendo quaisquer dúvidas a respeito dessa associação. |
Edição das 18h16min de 11 de setembro de 2018
Antes de iniciar o documento de casos de uso:
- Entender a necessidade (consultar documento de levantamento de esforço caso exista).
- Alinhar as visões a respeito da demanda com a liderança da fábrica (desenvolvimento, integração e configurações).
- Caso surjam dúvidas ou questionamentos vindos da equipe ou de algo que foi descrito no levantamento de esforço, solicitar reunião de alinhamento com o cliente a fim de sanar quaisquer dúvidas.
- Preparar a reunião compilando todas as dúvidas no documento de "Ata de reunião". Enviar a pauta deste documento ao cliente no momento do agendamento, contendo os questionamentos a serem feitas na reunião.
- Após a reunião, alinhar novamente com a equipe os pontos discutidos, a fim de projetar a melhor solução para todas as partes. Havendo um consenso a respeito da demanda, iniciar a documentação.
OBS1: É importante não fugir do escopo que foi acordado no documento de levantamento de esforço. Caso o cliente solicite algo que não está no documento de esforço, deve ser analisado e, se preciso, repassado ao Gerente de projetos responsável, para que ele possa prosseguir com a atividade.
OBS2: Atenção à quantidade de horas previstas para documentar a demanda.
Abaixo pode-se visualizar o modelo padrão utilizado na construção de documentos de casos de uso, este modelo pode ser encontrado neste documento: [1]
A estrutura deste documento modelo pode ser usado como base para construção de qualquer caso de uso.
Logo abaixo percorrendo a estrutura desse modelo, serão dadas algumas instruções básicas para o preenchimento de cadas tópico.
Histórico de Alterações
Data | Quem | Comentários |
---|---|---|
03/07/2018 | Ryvane Maria | Criação do documento |
Neste bloco é necessário incluir as alterações feitas no documento.
Por exemplo: Dia 03/07/2018 Ryvane Maria criou este documento, e toda e qualquer alteração feita após a validação do documento deve ser cadastrada neste bloco.
Não é necessário cadastrar alterações feitas em dias anteriores a aprovação do documento, por exemplo: Dia 03/07/2018 Ryvane Maria criou este documento, Dia 04/07/2018 Ryvane Maria alterou a solução deste documento, e assim sucessivamente.
Manter esse bloco atualizado é importante para o acompanhamento da atividade pelo gerente de projetos, pela equipe e pelo próprio cliente.
Necessidade
Este tópico deve abordar a necessidade desta funcionalidade para o sistema.
É um erro comum iniciar o processo de projeção da solução logo na descrição da sua necessidade! É importante se atentar a isto, pois este bloco é destinado a envolver o leitor na situação que levou a necessidade de se implementar a demanda.
Algumas perguntas podem ser aplicadas com a finalidade de facilitar a construção e escrita da necessidade de uma funcionalidade, como por exemplo:
- Por que esta funcionalidade/customização foi solicitada?
- Quais problemas/dificuldades inspiraram o usuário a solicitar a demanda?
- O que isto irá agregar ao GeoSales?
Solução
É na solução que deve ser abordado como a necessidade descrita no tópico acima será atendida.
Algumas perguntas podem ser aplicadas com a finalidade de facilitar a construção e escrita da necessidade de uma funcionalidade, como por exemplo:
Implementação
Este bloco contempla, pelo menos, quatro sub-tópicos, envolvendo setores diferentes que, juntos, contribuirão para a perfeita implementação da funcionalidade.
É possível que, em alguns documentos, não haja necessidade de incluir todos os tópicos descritos. Nestes casos, exclui-se o tópico desnecessário.
Para construir estes tópicos é interessante pontuar tudo que deverá ser executado por cada uma das áreas, criando um passo a passo da implementação da funcionalidade.
Desenvolvimento
Caso seja necessario incluir configuração informar os possiveis valores da configuração, e seu valor default
Integração
Bem como no tópico de desenvolvimento, é interessante dividir a integração em tópicos, definindo claramente um passo a passo a respeito do que precisa ser feito, por exemplo:
- Integrar as informações do cadastro de meta do ERP:
(Descrever aqui o que precisa ser feito)
- Salvar as informações do relatório de metas no ERP:
(Descrever aqui o que precisa ser feito)
É interessante que a tabela abaixo seja preenchida, caso se tenha a necessidade de trazer campos do ERP para o GeoSales ou vice versa, de forma a definir e ilustrar a associação de campos entre o ERP e o GeoSales, esclarecendo quaisquer dúvidas a respeito dessa associação.
Campo ERP | Tabela ERP | Campo Geosales | Tabela geosales | Observação |
---|---|---|---|---|
Campo do ERP | Tabela do ERP | Campo do GeoSales | Tabela do GeoSales | Observação |
Estrutura de banco
Neste tópico é necessário descrever as possíveis alterações que a funcionalidade irá demandar do GeoSales, se será necessário criar novas tabelas, ou alterar as tabelas existentes.
É importante salientar se a tabela deve ser criada, ou é uma tabela já existente onde deverão ser adicionados campos, por exemplo:
"- Tabelas a serem criadas: ou - Tabelas a serem alteradas:"
A estrutura abaixo exibe algumas informações importantes a cerca dos campos que deverão ser criados.
É importante que essa tabela seja preenchida de forma criteriosa, a fim de detalhar o melhor possível a estrutura que necessita ser montada.
TABELA | ||||
---|---|---|---|---|
Coluna | Tipo | Obrigatório | Chave Primária | Explicação |
NOME DO CAMPO | TIPO DO CAMPO | SIM/NAO | SIM/NAO | EXPLICAÇÃO SOBRE O CAMPO |
A primeira coluna especifica o nome do campo que deverá ser criado. Atenção: deve-se usar o modelo especificado no documento padrão de criação de estruturas de banco de dados, que pode ser acessado neste link: [2]
A segunda coluna define o tipo do campo (e o seu tamanho, caso seja necessário, por exemplo: Varchar(20), Int ou Decimal(18,6)).
As colunas 'Obrigatório' e 'Chave Primária' definem se o campo é obrigatário(Nulável), e se é chave primária, respectivamente. Estes campos devem ser preenchidos com SIM ou NÃO.
Na última coluna 'Explicação', deve-se inserir uma breve descrição da utilização do campo, por exemplo "código do organização de venda".
Regras de Negócios
Regras de Integração
Resultados Esperados
Protótipos
Fluxos Padrão
Aprovação
Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. (Essa é uma frase padrão do modelo de documento de casos de uso)
GeoSales
Setor | Aprovado Por | Data | Assinatura |
---|---|---|---|
Desenvolvimento - GeoSales | Pessoa que aprovou | 00/00/0000 | |
Integração - GeoSales | Pessoa que aprovou | 00/00/0000 | |
Configurações - GeoSales | Pessoa que aprovou | 00/00/0000 |
A aprovação do documento se dá por duas etapas, a primeira etapa é a aprovação interna. Todo documento deve ser revisado e validado pelas áreas envolvidas na sua implementação. Esta etapa é crucial para a eficácia na entrega, pois estabelece visões diferentes do que pode ser melhorado, de informações que seriam interessantes incluir, ou de possíveis Gap's e alterações no documento.
Só é permitida a finalização e envio do documento para aprovação do cliente quando todas as áreas envolvidas aprovarem o documento.
Atenção a forma de assinatura do documento. O responsável pela aprovação deverá, logado na wiki, incluir seu nome e a data de aprovação no campo destinado a sua área. É importante que este usuário esteja logado, a fim de formalizar a sua assinatura digital no histórico da Wiki.
Empresa solicitante
Setor | Aprovado Por | Data | Assinatura |
---|---|---|---|
Gerente TI - Cliente | Pessoa que aprova | 00/00/0000 | |
Gerente de Projeto - Cliente | Pessoa que aprova | 00/00/0000 | |
Gerente Comercial - Cliente | Pessoa que aprova | 00/00/0000 |