Nome do Produto

História de Usuário
Produto do PGA

Aprovado

IPLANRIO/DPN

19/06/2020

Para mais orientações sobre esse produto entre em contato com IPLANRIO/DPN

Clique aqui para baixar o Modelo do Produto

Dono do Produto: IPLANRIO/DPN

Responsável: CONTRATADA

Homologador:

Tipo:

Descrição

Definição de qual questão a história quer responder.

 

A História de Usuário deve ser apresentada no JIRA, conforme o modelo.

Critérios de Aceitação

 Conter os itens obrigatórios solicitados conforme modelo de história;

· A história deverá permitir que alguém que não conheça o negócio consiga desenvolver e testar a funcionalidade/requisito;

· Amigável para o gestor do projeto entender e aprovar;

· Todas as regras de negócio aprovadas pelo gestor devem ser implementadas;

· INVEST (I :  Independente; N : Negociável; V : Valor para o negócio; E : Estimável; S : Simples; T : Testável).

 

Regra de Negócio: Comportamentos para atender a descrição da história.

 

Protótipo: Referente a história. Interface do usuário podendo utilizar wireframe.

 

Obs: História do Usuário = História + Regra de Negócio + Protótipo.

 

 

Template de História

 

Identificador + Numeração + Resumo

Onde Identificador representa a Sigla do Sistema + Numeração (dada pelo JIRA) e Resumo contendo o nome da História que está sendo apresentado.

 

Descrição

COMO <PERFIL>

QUERO consultar/executar/ <DESCRIÇÃO DA FUNCIONALIDADE>

PARA atender/ a fim de <DESCREVER BENEFICIO PARA PERFIL>

 

Pesquisa

 

Atributos (Busca)

 

Atributos do Resultado (Grid)

 

Wireframe (opcional: pode ser desenhado dentro da história ou um link para abrir a(s) tela(s) desta história – quando a história tiver mais de uma tela informar o código da(s) tela(s) também)

 

 

Edição (Formulário)

 

Atributos

 

Wireframe (opcional: pode ser desenhado dentro da história ou um link para abrir a(s) tela(s) desta história – quando a história tiver mais de uma tela informar o código da(s) tela(s) também)

 

Regras de Negócio

Deverão ser descritas as Regras de Negócio, Regras Funcionais e Fluxos de exceção associadas à funcionalidade que está será desenvolvida e posteriormente testada. A definição de "principais regras de negócio" é dada pelo analista de negócio. Entendemos como principais, as regras que representam a essência da funcionalidade. Por exemplo: Requisito para Geração de uma taxa. Uma das regras principais seria o cálculo da taxa.

 

 

Exemplo:SILFAE-001 Informar Data de Publicação do Diário Oficial.

Descrição

COMO um usuário do Cartório

QUERO consultar Solicitações de sua IRLF, selecionar uma da lista e então informar a Data de Publicação no Diário Oficial

PARA dar ciência dos deferimentos ou indeferimentos destas

Pesquisa

Atributos da Busca

· Publicado (Sim/Não)

· Número do Processo

· Nome do Titular

· Tipo de Solicitação (ver Lista de Tipos do Sistema)

· Situação da Solicitação (Deferido/Indeferido)

· Data de Decisão (Data Inicio/Data Fim)

Atributos do Resultado

· Número do Processo

· Nome do Titular

· Tipo de Solicitação

· Data de Decisão

· Data de Publicação

Wireframe

 

 

Edição (Formulário)

Atributos

· Número do Processo (Não Editável)

· Nome do Titular (Não Editável)

· Tipo de Solicitação (Não Editável)

· Data de Decisão (Não Editável)

· Data de Publicação (Obrigatório)

Wireframe

Regras de Negócio

RN01 - Só serão exibidas Solicitações pertencentes ao Órgão associado ao usuário do Cartório (usuário logado).

RN02 -  A Data de Publicação deverá ser maior ou igual a Data Atual do Sistema.

RN 02 (E) – Caso o usuário informe uma Data menor que a Data Atual do Sistema no Campo Data de Publicação, deverá receber uma mensagem de erro em pop up /campo de erro informando "Nessa função apenas podem ser consideradas Data de Publicação superior ou igual à Data do Dia"

 

RN03 -  Será permitido alterar a Data de Publicação, caso já tenha sido informado.

RN04  - Sempre que uma Data de Publicação for informada deverá ser registrado no Histórico: situação da solicitação, data publicação, matricula do usuário logado.

RN05 – Todos os tratamentos associados a Campos de Data, como por exemplo, dias inválidos no calendário (31/4, 29/02 em ano não bissexto) devem ser tratados.

Orientação: Todos os itens são de preenchimento obrigatório.

 

Como cadastrar uma HISTÓRIA no JIRA

 

CAMPOS:

 

Tipo de Pendência: <Aquisição de Software>

Item de Serviço: <escolher um item da lista compatível com anexo III.a>

Resumo: <Nome da História>

Natureza: <Sistema ou Projeto>

Sprint: <Número da Sprint que está a História>

Versões afetadas: <número(s) da(s) versão(ões) afetada(s)

Epic link: <nome do Épico que agrupa esta História>

Descrição: <Template de História>

Anexo:<caso necessário anexar arquivos>

Data da Solicitação:

Prioridade: <da demanda>

Impacto:

Classificação:

Data de Início Previsto: <data início da Sprint>

Data de Fim Previsto: <data final da Sprint>

Data de Início Real:

Data de Fim Real:

Envolvidos: <nomes dos envolvidos e ou matrícula>

Pendências Linkadas: <Demanda do Gestor>

Responsável: <nome do líder>

Órgão Principal: <Sigla do órgão Gestor>

Comentário:

Contatos


Última atualização deste conteúdo: 19 Mar 2024 - 15:21:10