Continuando a falar sobre requisitos, vimos o que era um requisito e como definir um bom requisito. Agora vamos falar sobre tipos de requisitos.

Os requisitos podem ser agrupados por categoria. Estas categorias dizem onde se encaixam os requisitos, podendo ser no produto, no projeto ou no processo.

Os requisitos de produto estão relacionados diretamente com o produto final, seja o jogo ou uma engine. Os requisitos de projeto estão relacionados ao projeto em si, quais recursos estão disponíveis, abordagens do projeto, etc. Por fim, os requisitos de processo indicam padrões, procedimentos, linguagens, etc.

Percebemos que os requisitos não estão limitados ao produto, no caso o software. Diferente do que alguns podem pensar, quando se fala de levantamento de requisitos fala-se em verificar quais as necessidades para a produção de um determinado produto, abrangendo pessoal, tecnologias, processos, equipamentos e tudo que envolva a produção, processo e projeto do produto final.

Além das categorias de requisitos existem os tipos de requisitos. Estes tipos podem ser:

• Funcional. São funções que devem ser disponibilizadas pelo software. Como exemplo, o registro de produtos vendidos em uma loja.
• Não-funcional. Refere-se às especificações técnicas e de padrões e métodos do processo produtivo, não estão relacionados diretamente com códigos, mas sim a questões gerenciais e processos. Atender uma determinada norma é um exemplo de requisito não-funcional.
• Inverso. São requisitos de negação, isto é, requisitos que impõe alguma limitação ao sistema, de forma que seja mais fácil adicionar esta limitação do que um conjunto de requisitos de possibilidades. No caso de uma atualização que não funciona para a versão 1.0 de um jogo é mais útil que criar um requisito onde a atualização funciona para a versão 1.2, 1.3, 1.4, 2.0.

Mas para que serve essas classificações?

Quando trabalhamos com produtos de grande porte é natural que a lista de requisitos seja enorme. Então, o primeiro objetivo da classificação é exatamente separar os requisitos em grupos para que cada especialista possa verificar a qualidade dos requisitos colhidos.

Outro objetivo é que o levantamento de requisitos envolve o cliente, com seus usuários. No caso de jogos pense no cliente como o mercado e outros fatores para criação de jogos, e no caso de engines o cliente é simplesmente os desenvolvedores de jogos que vão usar a engine. Estes usuários, de onde serão extraídos os requisitos, podem ser de diversas áreas. É natural que dependendo da área do usuário os requisitos fornecidos por ele terá uma característica mais técnica (usar c++, preferir listas para cadastro de imagens) ou não. Com a divisão dos requisitos é possível mapear a origem do requisito e em caso de dúvida, ou o requisito não ser bom, é possível contatar o usuário mais indicado para tirar dúvidas e ajudar a criar um bom requisito.

Esta é a segunda parte sobre requisitos, falamos sobre a divisão dos requisitos. Em breve teremos mais assuntos sobre requisitos e outras questões de modelagem.

ciao