A modelagem de aplicações é algo que poucos gostam de fazer. Normalmente, as pessoas saem colocando a mão na massa e apenas no meio da aplicação vão se preocupar com questões de modelagem.

Para ajudar na hora de criar uma aplicação de tamanho considerado é recomendado projetar tudo antes de sair colocando a mão na massa.

“10% de inspiração e 90% de transpiração? Com software não funciona bem assim.”

Quanto se fala de software a frase acima não se aplica. Na construção de software, a parte de modelagem pode levar mais tempo que a parte de codificação. Para se ter uma idéia, durante a modelagem(isto é, o o que fazer) devem ser abordadas questões relacionadas a desempenho, modularização, dependências, problemas à serem resolvidos e várias outras questões que vão implicar diretamente no como fazer. A primeira etapa da modelagem é entender o que o software deve fazer e quais suas capacidades, limitações e necessidades. Para isto, é preciso saber quais os requisitos que o software terá de ter para satisfazer essas capacidades, limitações e necessidades.

Mas o que é um requisito? Segundo Dorfman e Thayler um requisito de software “é a capacidade do software que precisa ser atendida ou possuída pelo sistema ou um componente do sistema para satisfazer um contrato, norma, especificação ou outra documentação imposta formalmente“. Veja que apesar da literatura de engenharia de requisitos não abordar o tema jogos, essa área possui um complexo conjunto de requisitos de software.

Agora que sabemos o que é um requisito, vamos ver o que ele pode descrever e como deve ser estruturado. O requisito pode descrever uma propriedade genérica do sistema, uma restrição específica de hardware ou software, uma regra de negócio e até uma restrição de desenvolvimento. Vamos ao exemplo de um requisito:

O jogo deve ser desenvolvido em linguagem c++ com a engine da empresa na versão 3.4.

Perceba que este requisito acima é uma restrição no desenvolvimento, isto é, nesse projeto deve-se utilizar a linguagem c++ e estar limitado à utilização da engine X na versão 3.4. Mas nem sempre um requisito é descrito assim com poucas palavras, podem existir requisitos que ocupam um paragráfo inteiro. Mas como saber se um requisito é de fato bom? Para isto devem-se verificar se o requisito é:

Não ambíguo, isto é, não possui nenhuma dupla interpretação e frases genéricas de interpretação pessoal como: “o novo sistema deve ser melhor do que o anterior”. Melhor quanto e em que sentido?

Verificável, poder ao final do projeto olhar no sistema e poder testar por completo de modo aceitável. “O sistema deverá ter um menu de ajuda com as seguntes opções…”. Isto pode ser testato facilmente ao final do projeto e de forma completa. Perceba que este requisito descreve apenas o que o menu deve possuir, outro requisito pode descrever sua aparência, posicionamento e forma(s) de acesso.

Deterministico, definir medidas e quantidades sem deixar dúvidas: “O sistema deverá rodar em máquinas com até 256mb de memória ram”.

Rastreável, conseguir ao final do projeto determinar que aquela funcionalidade veio do requisito X. Perceba que em alguns casos ele pode ser confundido com o determinístico, mas a diferença básica é que um requisito rastreável pode não estar disponível para teste completo. Um exemplo seria um algoritmo de colisão, ele está lá, funcionando, mas pode ser falho em um ou outro objeto em fases avançadas e em situações específicas. O requisito foi implementado, rastreado, mas não pode ser testado por completo.

Correto, pode parecer brincadeida, mas deve-se assegurar que o requisito descrito é o que se deseja realmente. Manter sempre o foco é importante.

Estas descrições acima podem auxiliar na definição de requisitos, ao criar um requisito podemos nos quesitionar se este é não ambíguo, verificável, determinístico, rastreável e correto.

Bom, para não deixar o post muito longo e para existir uma segunda parte vamos ficar por aqui. No próximo post sobre requisitos vamos abordar as categorias de requisitos e seus tipos. Se alguém achar algum erro, ou desejar acrescentar algo, faça.

até a próxima.