Este post trata objetivamente da classificação dos diferentes tipos de requisitos de software, a fonte utilizada para a produção deste resumo é a oitava edição do livro Engenharia de Software do Ian Sommerville, normalmente é este livro que as bancas de concurso utilizam para elaborarem as questões referentes ao tema. Uma outra bibliografia utilizada pelas bancas é o livro Engenharia de Software do Roger Pressman, contudo, talvez o livro do Sommerville aborde com maior riqueza de conteúdo o tema Requisitos de Software e por isso, optei por ele para fazer esse resumo pra vocês.
Os requisitos podem ser definidos quanto a sua destinação da seguinte forma
São Requisitos abstratos, de alto nível, entendemos como alto nível os requisitos mais próximos do entendimento do usuário, para isso são utilizadas declarações em linguagem natural, formulários, tabelas, diagramas simples, explicando quais são os serviços esperados do sistema e quais são as restrições sob as quais irá operar.
Também trata das funções, os serviços, e as restrições operacionais, mas de maneira detalhada, deve ser preciso, definindo exatamente o que será implementado podendo inclusive ser parte do contrato entre cliente e desenvolvedor.
Traduz os serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas, e até mesmo o que o sistema não deve fazer. Existem sob a forma de requisitos de usuário e também sob a forma de requisitos de sistema. A especificação de requisitos funcionais deve ser completa, ou seja, todos os requisitos desejados pelo usuário devem ser satisfeitos, deve ser consistente, ou seja, não deve haver definições contraditórias, em sistemas grandes e complexos é quase impossível atingir completeza e consistência, erros e omissões são cometidos e há inconsistência entre os diferentes stakeholders do projeto.
São as restrições sob as quais o sistema deve operar, podendo se dividir em várias categorias. As restrições se estendem também ao processo de desenvolvimento do software podendo por exemplo: determinar o uso de uma ferramenta CASE específica, determinar o uso de um padrão de qualidade específico.
Os requisitos não funcionais podem estar ligados a fatores externos como uma política organizacional ou uma lei a qual a organização se sujeita. Há também casos em que é necessário que o software possua características de interoperabilidade
Especificam o comportamento do produto, os requisitos de produto de dividem em:
Exemplo: o sistema deverá ter uma interface que permita acessibilidade, sendo possível ao usuário aumentar e diminuir a fonte dos textos.
Procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor, entre os exemplos estão os padrões a serem utilizados
requisitos de padrões
Exemplo O sistema deverá estar em conformidade com as melhores práticas de desenvolvimento de software utilizando padrões de projeto como o Singleton:
Exemplo: O sistema deverá se comunicar com os demais sistemas da empresa, utilizando cadastros de usuários preexistentes sendo interoperável.
O desenho abaixo é um mapa mental muito útil e ilustra parte da matéria de requisitos não funcionais.
surgem à medida que a compreensão do cliente sobre o sistema aumenta, tornando-o apto a sugerir e requisitar mudanças, não é possível defini-los na construção do sistema, surgem durante a operação do sistema.
Requisitos Consequentes
requisitos consequentes estão diretamente ligados a introdução de sistemas de computação na empresa, que podem modificar processos e criar novos métodos de trabalho.
são os requisitos relativamente estáveis, que derivam da atividade principal da organização e se relacionam diretamente com o domínio do sistema.