2.1 - Elaboração de Requisitos¶

2.1.1 Escrevendo histórias de usuário¶

O Processo de Entrega de Soluções (PES) prevê o uso de Test Driven Development (TDD) e, a partir do padrão para escrita das histórias de usuário, o Behavior Driven Development (BDD).

BDD fornece uma estrutura para uma história de usuário. No mínimo, sua história deve conter todos os elementos descritos no modelo como este:

Título (descreva a história em apenas uma linha)

Narrativa:
Como (papel/usuário/ator) xxxxxxxxxx
Preciso (necessidade / objetivo a ser atingido) xxxxxxxxxxxxxxxxxxx
Para que (a razão porque quer atingir o objetivo) xxxxxxxxxxxxx

Critérios de aceitação (apresentados como cenários)

Cenário 1: Título
Dado (contexto) xxxxxxxxxxxxxxxxxxxxx
E (mais contexto) xxxxxxxxxxxxxxxxxxxxxx
Quando (ação / um determinado evento ocorre) xxxxxxxxxxxxxxxxxx
Então (reação / resultado / isto deve acontecer) xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
E (outro resultado) xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Cenário 2: Título ...

Seguir esse padrão é o primeiro passo para que possamos utilizar os cenários também para a automatização de testes utilizando BDD.

Algumas regras básicas para a escrita são essenciais:

I) evitar frase negativas
II) evitar redundâncias no texto
III) usar sempre a ordem direta nas frases
IV) Usar linguagem do usuário, não de tecnologia.

Tomem-se como exemplos os seguintes cenários:

Exemplo 1:

_Preenchimento do campo [Terreno com Acessão/Benfeitoria?]_
Dado que o usuário está realizando o preenchimento dos dados do terreno
Quando ele na aba [Imóvel] no preenchimento das informações dos detalhes do imóvel informar no campo [Tipo do Imóvel] a opção [Unidade Autônoma] ou [Cavidade]
Então o sistema não deverá exibir o campo [Terreno com Acessão/Benfeitoria?] para a marcação.

A análise do texto sugere que o ideal seria que a situação estivesse completa no "Dado que", que define o contexto, e não no "quando", que define o evento que ocorre.
Poderíamos reescrever como:

*Dado que* o usuário está realizando o preenchimento dos dados físicos do terreno
Quando [Tipo do Imóvel] for [Unidade Autônoma] ou [Cavidade]

Mas ainda há um problema: o “Então” deve manifestar a reação do sistema quando o evento ocorrer. Logo, o melhor seria dizer em que condições o campo deve ser exibido e evitar uma “não reação”

*Dado que* o usuário está realizando o preenchimento dos dados físicos do terreno
Quando [Tipo do Imóvel] for diferente de [Unidade Autônoma] e [Cavidade]
Então o sistema deve exibir o campo [Terreno com Acessão/Benfeitoria?]

Exemplo 2:

_Preenchimento do campo [Área da União]_
Dado que o usuário está realizando o preenchimento dos dados do terreno
Quando ele durante o preenchimento dos dados do imóvel, tiver selecionado como o proprietário do imóvel a opção [União/Parcialmente]
Então o sistema deve exibir para o preenchimento, o campo [Área da União], do contrário o campo não será apresentado e não poderá ser preenchido.

Simplificando a redação com o objetivo também de torná-la mais clara, de forma que não haja dúvidas para o desenvolvedor, e para facilitar a transcrição do critério de aceite para os testes, temos o seguinte:

_Preenchimento do campo [Área da União]_
Dado que o usuário está realizando o preenchimento dos dados do terreno
Quando o proprietário do imóvel for [União/Parcialmente]
Então deve ser exibido o campo [Área da União].

Exemplo 3:

_Editar Endereço do Imóvel Geolocalizado_
Dado que o usuário qualificador confirmou a edição do endereço do imóvel geolocalizado
Quando o sistema efetuar a ação
Então será apresentada uma modal contemplando o endereço cadastrado e os campos de endereço para que o usuário os atualize, conforme abaixo:
- CEP;
- Logradouro;
- Complemento;
- Número;
- Município;
- UF.

Pode-se notar que o contexto (“Dado que”) possui a informação do “Quando”, que é o evento que acontece e que dispara a reação do sistema (“Então”), e o “Quando” não possui nenhuma informação.
Os atributos não precisam ser listados, pois estão detalhados no protótipo. Exceção se estivesse adotando a especificação por exemplo, em que haveria uma tabela com os atributos e seus valores.
A frase “será apresentada uma modal” é inadequada para uma história de usuário por se referir a termos técnicos de tecnologia.

Sendo assim, a reescrita do critério tem como resultado:

_Editar Endereço do Imóvel Geolocalizado_
Dado que o usuário qualificador está na funcionalidade [Geolocalizar Imóvel]
Quando confirmar a edição do endereço do imóvel geolocalizado
Então será apresentado o endereço do imóvel para que o usuário o atualize.

2.1.2 Escrevendo histórias técnicas¶

Em algumas situações, em lugar de histórias de usuário, que descrevem comportamentos de um ator/usuário/papel, é necessário preparar histórias técnicas que complementam uma história de usuário com definições técnicas para implementar algo. Exemplos: integração entre soluções de software, sejam internas ou externas; especificação de uma refatoração com detalhamento de aspectos técnicos da solução; dentre outros.

Neste caso, a descrição da história não segue o padrão de história de usuário. Nem mesmo é possível estabelecer um padrão, pois a forma é totalmente dependente do que será descrito. Mas é possível estabelecer algumas orientações.

Considere o seguinte exemplo de uma história técnica de um determinado projeto:

*Narrativa*:
Como Sistema [XYZ]
Preciso de uma rotina mensal de geração de arquivo da notificação da isenção/carência que seja executada no 1º dia útil de cada mês, e disponibilizar no FTP dos Correios
Para impressão e postagem das notificações

*Cenário*: Geração do arquivo de notificação da Isenção
Dado que exista uma isenção concedida a um CNPJ
E a [data fim da isenção] anteceda 3 meses ao 1º dia útil do mês corrente
Quando a rotina mensal de geração do arquivo da notificação for executada
Então o sistema irá gerar um arquivo no formato ".zip" com o delimitador "|" possuindo a nomenclaura referenciada no documento em anexo
E o arquivo será disponibilizado no FTP dos correios, utilizando como referência o documento "MP-SIAPA-GERAL-PIE-Projeto de Interfaces Externas.odt" em anexo.

Primeiramente, a Narrativa não se aplica a essa história: define que precisa de uma rotina mensal de geração de arquivo da notificação da isenção/carência mas não é disso que trata a história técnica.
A história técnica trata apenas dos formatos de geração dos arquivos de notificação. E ela é referenciada na história de usuário que especifica o comportamento da rotina mensal. Ou seja, ela complementa a história de usuário da rotina mensal. Ainda que o usuário seja o próprio sistema.

Como a história técnica não define comportamentos de usuário, a ela bastariam as informações para gerar o arquivo.

Adicionalmente, o contexto (Dado) está incorreto pois é durante o processamento da rotina mensal que é encontrado o evento (Quando) que vai disparar a ação do sistema (Então) e não o contrário.

A história de usuário teria o cenário:

*Cenário*: Geração do arquivo de notificação da Isenção
Dado que a rotina mensal de geração de arquivo de notificação está sendo executada
Quando existir uma isenção concedida a um CNPJ
E a [data fim da isenção] anteceda 3 meses ao 1º dia útil do mês corrente
Então o sistema irá gerar um arquivo de acordo com TS001 - Geração do arquivo de notificação da Isenção.

E a história técnica seria a seguinte:

*Nome da história*: TS001 - Geração do arquivo de notificação da Isenção

Gerar um arquivo no formato ".zip" com o delimitador "|". Conteúdo:
RIP
CNPJ
NOME
ENDEREÇO RFB
BAIRRO RFB
CIDADE RFB
UF RFB
CEP RFB
VENCIMENTO DA ISENÇÃO
ENDEREÇO MP
BAIRRO MP
CIDADE MP
UF MP
CEP MP

Usar o serviço de Carta Simples dos Correios

ARQUIVOS E MENSAGENS DE ENTRADA – CARTA SIMPLES

Fonte de Informação: CartaSimples – Correios
Órgão responsável por sua manutenção: Correios
Informações: Dados do DARF
Meio de acesso: ftp
Endereço de acesso: FTP://transfer.correios.com.br/CDIP/BSB/MPOG6622/PRODUCAO
Forma de requisição: ftp
Local de armazenamento: N/A
Dados de contato no Órgão Responsável: Paulo Roberto Guimarães. E-mail: paulo...@co??eios.com.br, Telefones: 3XX5-8975 / 8626-1583
Motivo de utilização da referida fonte no sistema: Gerar arquivo para emissão e postagem de DARF

Acesso ao FTP dos Correios:
URL: FTP://transfer.correios.com.br/CDIP/BSB/MPOG6622/PRODUCAO
Usuário: xxxxxxxx
Senha: isf8284
Dados de envio do e-mail:
Endereços de e-mail: paulo...@cor???ios.com.br, ABCOSMO@cor??ios.com.br, [email protected], hi??ro@cor??os.com.br, gisl???ouza@cor???s.com.br
Assunto: Geração de DARFs da SPU
Corpo do e-mail:
Caminho absoluto do arquivo no FTP: <caminho>
Nome do arquivo de serviço: <nome do arquivo>
Quantidade de registros válidos dentro do arquivo de serviço: <quantidade>
Premissas
• Todo arquivo tramitado na prestação do serviço deverá estar obrigatoriamente compactado no formato ZIP. Portanto, deverá ser gerado um arquivo compactado para cada arquivo que deverá ser enviado a ECT (Arquivo de Serviço).
• Nomenclatura do arquivo compactado de serviço:
◦ “CartaSimples” + “_” + <numero do contrato> + <numero do cartão de postagem> + “_” + <número_do_lote> + “_” + <extensão>
◦ Exemplo: CartaSimples_99123666220070499136_4_servico.zip
Arquivo de Serviço
Definições:
◦ Formato: TXT
◦ Codificação: UTF-8
◦ Tamanho máximo: 80MB
◦ Nomenclatura
▪ “CartaSimples” + “_” + <numero do contrato> + <numero do cartão de postagem> + “_” + <número_do_lote> + “_servico”+ <extensão>
▪ Exemplo: CartaSimples_99123666220070499136_4_servico.txt
▪ Separador de dados do arquivo: | (Pipe)
As definições e layout dos campos do arquivo de serviço estão descritas no arquivo anexo CartaSimples-DARF-Campos.odt
O exemplo do arquivo de serviço, em txt, encontra-se no arquivo anexo CartaSimples-DARF-CamposExemplo.txt

Como se vê, a história técnica traz as definições para uso da tecnologia, não o comportamento de ator/papel/usuário.

2.1.3 Escrevendo regras de negócio¶

Registram-se nas regras de negócio requisitos que valem para várias histórias de usuário. Uma regra de negócio não envolve comportamento de ator/papel/usuário. Se, para definir uma regra, é descrito um comportamento, então ela é uma história de usuário que será referenciada por outras histórias (reusada).

Exemplos de regras de negócio:

*RN003 - Formação do RIP*

O número do RIP somente deve ser gerado quando o perfil "Cadastra imóvel da União" ou "Cadastra imóvel próprio" realizar o cadastro do imóvel ou a homologação de um imóvel.
O número do RIP deve ser igual à PK do registro e sempre deve ser apresentado com 8 dígitos.

*RN001 - Validações Topológicas*

_Geometria Duplicada (Terreno/Benfeitoria)_
Não é permitido que geometrias idênticas sejam criadas na mesma posição;
A geometria duplicada deverá ser destacada na cor vermelha.

_Geometria Inválida (Terreno/Benfeitoria)_
Deve possuir no mínimo três pontos;
As linhas não poderão estar desconexas;
As linhas não poderão se cruzar entre si;
A geometria inválida deverá ser destacada na cor vermelha.

_Geometria Sobreposta (Terreno)_
Um terreno não pode interceptar os limites de outro terreno;
Quando houver sobreposição de geometrias, a geometria nova deverá ser destacada na cor vermelha e a área de sobreposição na cor roxa.

_Geometria Fora da Restituição (Benfeitoria)_
A benfeitoria não pode ter alguma área da geometria fora dos limites do terreno cadastral Cartorial a que está vinculado.
A geometria fora da restituição deverá ser destacada na cor vermelha.

*RN006 - Situação do Imóvel*

O sistema deve considerar a situação do imóvel de acordo com as seguintes definições:
Ativo: Qualquer imóvel cadastrado no sistema que ja foi homologado e não foi cancelado
Não Homologado: Qualquer imóvel novo e não homologado
Cancelado: Qualquer imóvel que foi cancelado

*RN020 - Formação do Código de Documento*

O sistema deve gerar os códigos de documentos de acordo com a forma abaixo:

*Código* = [Prefixo][5 dígitos numéricos (sequencia)] / [Ano atual]

Exemplo: ATO00021/2016

*Lista de Prefixos*

Funcionalidade	Prefixo
pendente	pendente