Análise de ambigüidade na análise de requisitos

Como escrevi em outro post, na análise de requisitos é fundamental aplicarmos também a análise de ambigüidade que serve para que possamos identificar itens que podem levar a interpretações diferentes por pessoas diferentes, ou seja, para que não fique dúvida na interpretação dos requisitos.

Você deve verificar:

• Os requisitos estão completos? Todas as condições que se aplicam ao requisito estão descritas e o requisito expressa uma idéia completa?

• Os requisitos estão explícitos? Não existe nada “implícito” ou nas entrelinhas do texto?

• Existem ambigüidades no requisito?

• Os requisitos são consistentes?

• Os requisitos são testáveis?

Portanto quando você analisar os requisitos deve descrever exatamente o que é para ser feito e não colocar descrições vagas, mas tome cuidado também para não exagerar muito nos detalhes, abaixo dois exemplos:

Requisito definido incorretamente
O backup deve ser realizado diariamente
Essa é uma definição muito ambígua, diariamente que horas?

Requisito definido corretamente
O backup deve ser realizado diariamente as 7:00
Com essa descrição não deixamos dúvidas.

A melhor maneira de exemplificar a ambigüidade em uma análise de requisitos é imagem abaixo.

Ambigüidade em análise de requisitos. Clique para ampliar.

Até a próxima!

Resumo do 1º Seminário Catarinense de Qualidade e Teste de Software

Como prometido no outro post, irei escrever um pouco sobre o que foi apresentado no 1º Seminário Catarinense de Qualidade e Teste de Software. Participei do evento junto com o Marcos e o Alessandro, ambos meus parceiros de trabalho.

Como sou da área de desenvolvimento, confesso que fiquei um pouco surpreso com a quantidade de gente que trabalha com teste de software e o quanto é desenvolvido essa área.

Em meu pensamento o teste teria que ser uma das últimas tarefas a serem feitas, mas todos os palestrantes deixaram claro que os testes devem iniciar junto com o projeto, ou seja, deve seguir a mesma “linha” do desenvolvimento, começando pelos testes unitários.

Para quem programa em PHP, os teste unitários podem ser feitos com o PHPUnit, que é similar ao JUnit do Java, onde você escreve script de testes, para testar um retorno de uma função por exemplo. Por isso os testes começam junto com o projeto, pois primeiramente você escreve os seus testes unitários para as suas funções, para poder comparar com o retorno esperado.

Um dos pontos fundamentais em um início de projeto é análise de requisitos, que são as características que o nosso sistema deve ter, para atender as expectativas do cliente. E nessa fase se necessário, podemos perder alguns dias de desenvolvimento, para podermos planejar tudo que é necessário ter em nosso sistema, para que lá na frente não tenhamos surpresa, alguma mudança que possa acarretar uma mudança mais brusca.

Na análise de requisitos devemos também praticar a análise de ambigüidade que serve para identificar os requisitos que podem levar a interpretações diferentes por pessoas diferentes, para que não tenhamos o mesmo resultado do exemplo abaixo:

Projeto novo brinquedo – Requisitos

- O objetivo do projeto é construir um brinquedo que cause emoção e possa ser usado por crianças
- Deverá ter subida e descidas íngremes de forma que o usuário sinta medo
- O veículo deve poder levar crianças e ter no mínimo quatro rodas
- O veículo deve rodar sobre trilhos em alta velocidade
- Deve ter um mecanismo de proteção para os passageiros

Atendendo os requisitos, temos um brinquedo igual a este:

Se você perceber todos os requisitos foram atendidos na imagem acima, mas na verdade o brinquedo deveria ser igual a este:

Portanto é preciso deixar bem claro a definição dos requisitos.

O evento foi bem válido, queria parabenizar o pessoal da organização, pois os palestrantes eram muito bons, todas as palestras começaram nos horários previstos e a estrutura do SENAI – CTAI pode comportar a todos os participantes com qualidade.

E o mais importante, como a inscrição para o evento eram dois litros de leite, foram arrecadados mais de 300 litros de leite, para a SERTE.

Melhoria x Retrabalho

Semana passada aqui na Kombo estávamos discutindo sobre qual a diferença entre melhoria e retrabalho.
Chegamos a seguinte definição, deixando claro que o nosso foco é desenvolvimento de software.

- Melhoria: É quando um cliente já usa o produto e de alguma forma a solução já supre as suas necessidades. Quando ocorrer alguma mudança, será algo que não vai mudar a forma de como o cliente fazia antes, serão mudanças simples, sem grandes impactos.

- Retrabalho: Ocorre quando o planejamento falhou, é quando a solução nem chegou ao cliente ainda, e no meio ou no final do desenvolvimento é alterado todo o funcionamento da solução. A equipe de desenvolvimento tem que alterar tudo, gerando grande perda de tempo e custo.

Quem tiver alguma outra definição, favor comentar.

Planejar para quê?

Todos nos já passamos por momentos no qual sabíamos que pouparíamos muitos transtornos se tivéssemos pensado melhor no que fazer antes de agirmos.

O dito popular “quem não tem cabeça tem que ter perna” é a prova disso, porque quando agimos ao acaso, fazemos tudo às pressas e talvez com resultados frustrantes.
Por isso planejamos para poder identificar o que deve ser feito, para saber qual direção deve ser tomada. É a já conhecida questão do foco.

Sem um foco, saímos dando “tiro” para tudo quanto é lado, querendo acertar diversos alvos e acabamos na maioria das vezes não acertando nada. E com isso são feitos gastos a cada nova tentativa e temos um prejuízo com os tiros desperdiçados.

Então, quando você tiver uma idéia ou um volume muito grande de coisas para fazer e nem sabe por onde começar, planeje muito bem antes as tarefas e aí sim você pode começar a dar o primeiro passo em um projeto.