Reuniões de Melhoria das Especificações II

Primeiros resultados:

Aplicando-se todas estas diretivas, colhemos alguns resultados da primeira reunião.

1. Avaliação do Template (o que agiliza? o que atrapalha?)

O pessoal avaliou o estado do template e dizem que não têm tido grandes problemas. Foi incluído como anexo (opcional) uma tabela para mapeamento de campo de tela (cujo nome estará também no protótipo) com a ‘tabela.coluna’ do banco de dados. Se esta tabela for usada no Caso-de-Uso, exclui-se a necessidade de incluir a validação dentro do texto do Fluxo.

Nome Campo Tipo Obrigatório? Campo no BD
Tipo de Endereço select box* Sim endereco.tipo
Endereço text field** Sim endereco.descricao

*ou ‘campo seleção’ *ou ‘campo texto’
2. Retirada de Informação desnecessária do Caso-de-Uso (o que tem sido burocrático demais?)

Foi excluída a seção ‘Restrições’ dado que já existe no Caso-de-Uso um espaço para serem colocadas as pré e pós-condições.
3. Desmembramento dos passos de acordo com o Fluxo de Tela (clarificação dos passos)

Foi definido que cada verbo deriva um passo, e em cada quadro do ‘ping-pong’ podem existir um ou mais passos. Obs: cada verbo que signifique uma “ação”.
4. Regras de Validação do Campos (informações necessárias como tipo de campo: ‘text field’, ‘text area’, ‘select box’, ‘radio button’ e restrições de valores como numérico inteiro, decimal, etc..)

Ficou decido que não serão incluídas informações de telas nos textos dos passos de cada fluxo, ou seja, o nome de Campos e de Botões da tela. Mas o tipo de item de tela a ser utilizado pode ser indicado. Exemplo: ‘O sistema deve exibir uma tela com os campos: 1. Tipo de endereço: (campo de seleção); 2. Endereço (campo texto, obrigatório); […] ‘
5. Inclusão de Requisitos Funcionais e Não-Funcionais no UC: Sim ou Não?

Ficou em aberto para ser decidido na próxima reunião porque isto vai exigir uma avaliação no tempo disponível para isto, no formato que irão ser registrados os requisitos, etc…
6. Geração de Protótipo (apresentação de uma solução prática pelo Adriano)

Foi apresentada rapidamente a ferramenta ‘Pencil’, sugerida pelo Alessandro, e a equipe entrou num consenso que a ferramenta se mostrou prática e fácil de ser manuseada. A confecção de protótipos foi votado por todos como item obrigatório.
7. Casos de Uso que possuem dependência entre si.

Foi definido que será colocado dentro do próprio caso-de-uso qualquer referência que ele tenha a outro Caso-de-Uso.

Pauta para a próximas reunião (ainda não fechada):

  1. Feedback de todos em relação ao que foi definido e o que foi realmente aplicado, esforço necessário e benefícios
  2. Quais as informações devem vir do cliente para melhorar a precisão das estimativas?
  3. Diagrama de Classes: qual ferramenta utilizar até que a proposta da Mariana com o EA esteja pronta? Obs: Tínhamos discutido que ficariam nos anexos.
  4. Nomenclatura padrão para as especificações de todos os projetos.
  5. (…)
Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s