Mudanças entre as edições de "Criando um documento de Casos de uso"
| (14 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
| Linha 52: | Linha 52: | ||
É na solução que deve ser abordado como a necessidade descrita no tópico acima será atendida. | É 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: | + | Algumas perguntas podem ser aplicadas com a finalidade de facilitar a construção e escrita da necessidade de uma funcionalidade, como por exemplo: |
| + | #O que será feito para solucionar as necessidades relatadas no tópico acima? | ||
| + | #O que a equipe de desenvolvimento precisará fazer para que tudo dê certo? | ||
| + | #O que a equipe de integração precisará fazer para que tudo dê certo? | ||
| + | #O que o cliente precisará fazer para que tudo dê certo?(criar campo no ERP, habilitar configurações, etc) | ||
== Implementação == | == Implementação == | ||
| Linha 64: | Linha 68: | ||
=== Desenvolvimento === | === Desenvolvimento === | ||
| − | Caso seja | + | |
| + | Neste tópico é interessante dividir a o desenvolvimento em subtópicos, definindo claramente um passo a passo a respeito do que precisa ser feito, por exemplo: | ||
| + | |||
| + | '''- Criar configuração para ativar a funcionalidade:''' | ||
| + | |||
| + | (Descrever aqui o que precisa ser feito) | ||
| + | |||
| + | Observação: Caso seja necessário incluir alguma configuração para habilitar algum comportamento na funcionalidade, é necessário informar, além do nome sugerido para a configuração, os valores que ela receberá, e seu valor default inicial. | ||
| + | |||
| + | '''- Criar campos na tabela PEDIDO:''' | ||
| + | |||
| + | (Descrever aqui o que precisa ser feito) | ||
| + | |||
| + | '''- Criar tela de montagem de carga:''' | ||
| + | |||
| + | (Descrever aqui o que precisa ser feito) | ||
| + | |||
| + | É interessante detalhar o máximo possível tudo que precisa ser feito, e todos as informações que são importantes para o desenvolvimento, exemplificando caso seja necessário. | ||
=== 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. | ||
{| class="wikitable" | {| class="wikitable" | ||
| Linha 78: | Linha 110: | ||
| Campo do ERP || Tabela do ERP || Campo do GeoSales || Tabela do GeoSales || Observação | | Campo do ERP || Tabela do ERP || Campo do GeoSales || Tabela do GeoSales || Observação | ||
|} | |} | ||
| + | |||
| + | É interessante, também, detalhar o máximo possível tudo que precisa ser feito, e todos as informações que são importantes para a integração dos dados, exemplificando caso seja necessário. | ||
=== Estrutura de banco === | === Estrutura de banco === | ||
| Linha 117: | Linha 151: | ||
== Regras de Negócios == | == Regras de Negócios == | ||
| + | |||
| + | É uma regra de negócio tudo que envolva definições da funcionalidade, premissas para seu correto funcionamento e pontos importantes. | ||
== Regras de Integração == | == Regras de Integração == | ||
| + | |||
| + | As regras de integração definem o escopo que será utilizado pelo integrador no momento da integração, se será necessária alguma validação de informações, ou se há algum ponto de entrada no ERP por exemplo. | ||
== Resultados Esperados == | == Resultados Esperados == | ||
| − | === Protótipos === | + | === Protótipos === |
| + | |||
| + | Caso seja necessário, é interessante desenhar um protótipo sugerido de tela, com a finalidade de guiar o desenvolvedor na construção da tela, bem como oferecer a melhor interface no quesito experiência de usuário. | ||
=== Fluxos Padrão === | === Fluxos Padrão === | ||
| + | Caso seja aplicável, definir, através de um fluxograma, as etapas do processo que deverá ser executado como padrão da funcionalidade. Para isso, sugere-se utilizar o programa ''Visio''. | ||
== Aprovaçã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)'' | + | 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 === | === GeoSales === | ||
| Linha 153: | Linha 194: | ||
'''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. | '''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 === | + | === Empresa solicitante === |
| + | |||
| + | Esse tópico fica a cargo do Gerente de projetos, e é preenchido junto ao cliente. | ||
{| class="wikitable" | {| class="wikitable" | ||
Edição atual tal como às 20h01min de 12 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:
- O que será feito para solucionar as necessidades relatadas no tópico acima?
- O que a equipe de desenvolvimento precisará fazer para que tudo dê certo?
- O que a equipe de integração precisará fazer para que tudo dê certo?
- O que o cliente precisará fazer para que tudo dê certo?(criar campo no ERP, habilitar configurações, etc)
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
Neste tópico é interessante dividir a o desenvolvimento em subtópicos, definindo claramente um passo a passo a respeito do que precisa ser feito, por exemplo:
- Criar configuração para ativar a funcionalidade:
(Descrever aqui o que precisa ser feito)
Observação: Caso seja necessário incluir alguma configuração para habilitar algum comportamento na funcionalidade, é necessário informar, além do nome sugerido para a configuração, os valores que ela receberá, e seu valor default inicial.
- Criar campos na tabela PEDIDO:
(Descrever aqui o que precisa ser feito)
- Criar tela de montagem de carga:
(Descrever aqui o que precisa ser feito)
É interessante detalhar o máximo possível tudo que precisa ser feito, e todos as informações que são importantes para o desenvolvimento, exemplificando caso seja necessário.
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 |
É interessante, também, detalhar o máximo possível tudo que precisa ser feito, e todos as informações que são importantes para a integração dos dados, exemplificando caso seja necessário.
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
É uma regra de negócio tudo que envolva definições da funcionalidade, premissas para seu correto funcionamento e pontos importantes.
Regras de Integração
As regras de integração definem o escopo que será utilizado pelo integrador no momento da integração, se será necessária alguma validação de informações, ou se há algum ponto de entrada no ERP por exemplo.
Resultados Esperados
Protótipos
Caso seja necessário, é interessante desenhar um protótipo sugerido de tela, com a finalidade de guiar o desenvolvedor na construção da tela, bem como oferecer a melhor interface no quesito experiência de usuário.
Fluxos Padrão
Caso seja aplicável, definir, através de um fluxograma, as etapas do processo que deverá ser executado como padrão da funcionalidade. Para isso, sugere-se utilizar o programa Visio.
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
Esse tópico fica a cargo do Gerente de projetos, e é preenchido junto ao cliente.
| 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 |