Mudanças entre as edições de "Criando um documento de Casos de uso"
Linha 52: | Linha 52: | ||
== Implementação == | == Implementação == | ||
− | Este bloco contempla, pelo menos, quatro sub-tópicos, | + | 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. | É 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. | ||
Linha 63: | Linha 63: | ||
=== Configurações === | === Configurações === | ||
− | |||
Caso seja necessario incluir configuração informar os possiveis valores da configuração, e seu valor default | Caso seja necessario incluir configuração informar os possiveis valores da configuração, e seu valor default |
Edição das 17h29min de 5 de julho 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
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.
Desenvolvimento
Integração
Configurações
Caso seja necessario incluir configuração informar os possiveis valores da configuração, e seu valor default
Estrutura de banco
É importante, neste tópico, 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:"
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: usar o modelo especificado no documento padrão de criação de estruturas de banco de dados, que pode ser acessado neste link: [2]
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 |