Os problemas que os engenheiros de software precisam solucionar, muitas vezes, podem ser muito complexos. Compreender corretamente o problema se torna muito difícil, especialmente se o sistema for novo. E claro, fica difícil definir com clareza o que o sistema deve fazer. A descrição das funções e das restrições são os requisitos do sistema. O processo de descobrir, analisar, documentar e verificar os requisitos recebe então o nome de Engenharia de Requisitos (SOMMERVILLE, 2008).

1.1 Características da Engenharia de Requisitos

O termo requisito não se aplica de forma consistente a indústria de software. Isso se deve ao fato de em alguns casos os requisitos serem encarados como uma declaração abstrata de uma função que o sistema deve fornecer ou uma restrição do sistema. Em outros casos ele é uma descrição detalhada de uma função do sistema (SOMMERVILLE, 2008). Em todo caso deve-se levar em conta que uma boa Engenharia de Requisitos é um passo fundamental para o desenvolvimento de um bom produto (PAULA FILHO, 2000).

Se uma empresa deseja estabelecer um contrato de desenvolvimento de um grande projeto a princípio ela deve fazer definição de requisitos relativamente abstrata (PAULA FILHO, 2000). Isso possibilita que os diferentes fornecedores apresentem propostas sugerindo diferentes maneiras de atender as necessidades organizacionais do cliente. Evitando ainda, que soluções predefinidas sejam adotadas em detrimento das particularidades organizacionais. Uma vez que o contrato esteja firmado o fornecedor deve então preparar uma definição de sistema bem detalhada. O que facilita a compreensão por parte do cliente e possibilita também validar o que o software fará (SOMMERVILLE, 2008).

Durante a Engenharia de Requisitos podem aparecer alguns problemas decorrentes da falta de uma separação nítida entre os dois diferentes níveis de descrição. Esses níveis podem ser distinguidos utilizando-se os termos requisitos de usuário para os requisitos abstratos de alto nível e requisitos de sistema para indicar a descrição detalhada das funcionalidades do sistema. Pode ser produzida ainda uma descrição mais detalhada associando a Engenharia de Requisitos às atividades de projeto. Para Sommerville (2008) esses dois níveis de requisitos e a especificação de projeto de software podem ser definidos do seguinte modo:

  • Requisitos de usuário são declarações em linguagem natural e diagramas contendo as funcionalidades e as restrições sob as quais o sistema deve operar. Esse documento é escrito para gerentes do cliente e dos fornecedores que não tenham conhecimento técnico detalhado do sistema.
  • Requisitos de sistema detalham funcionalidades e restrições. Esse documento pode inclusive servir como um contrato entre as partes envolvidas no projeto. Ele é escrito para os profissionais técnicos de nível sênior e para gerentes de projeto
  • Especificação de projeto de software é uma descrição abstrata do projeto de software na qual se acrescenta mais detalhes aos requisitos do sistema. Esse documento é escrito para os engenheiros de software que desenvolverão o sistema.

1.2 Requisitos Funcionais e Não Funcionais

Sommerville (2008) classifica os requisitos de sistema de software como funcionais, não funcionais e como requisitos de domínio:

  • Requisitos funcionais definem as funcionalidades do sistema como deve reagir em condições específicas e como se comportar em determinadas situações. Podem ainda declarar o que o sistema não deve fazer.
  • Requisitos não funcionais são restrições sobre serviços ou funções oferecidas pelo sistema. Dentre elas destacam-se restrições de tempo, sobre o processo de desenvolvimento e de padrões. A descrição das restrições complementa a definição de requisitos (PAULA FILHO, 2000).
  • Requisitos de domínio são restrições originárias do domínio da aplicação do sistema e refletem características do mesmo. Podem ser requisitos funcionais ou não funcionais.

A distinção entre esses diferentes tipos de requisitos não é tão clara como sugere essas definições. Um requisito pode parecer-se inicialmente não funcional, mas que quando desenvolvido com mais detalhes pode dar origem a uma série de novos requisitos funcionais. Ao discutirmos sobre requisitos devemos levar em conta que na realidade a distinção entre eles é artificial (SOMMERVILLE, 2008).

1.2.1 Requisitos funcionais

Os requisitos funcionais descrevem a funcionalidade ou os serviços que se espera que o sistema realize em benefício dos usuários (PAULA FILHO, 2000). Eles variam de acordo com o tipo de software em desenvolvimento, com usuários e com o tipo de sistema que está sendo desenvolvido. Requisitos funcionais podem ser expressos de diversas maneiras e, como já foi dito acima, em diferentes níveis de detalhamento. Os requisitos funcionais de usuários definem recursos específicos que devem ser fornecidos pelo sistema (SOMMERVILLE, 2008).

É natural para um desenvolvedor de sistemas interpretar um requisito ambíguo para simplificar sua implementação. Entretanto isso pode não ser necessariamente o que o cliente necessita. Surgem então novos requisitos e é necessário realizar alterações no sistema, o que afetará diretamente o tempo e o custo do projeto.

Inicialmente a especificação de requisitos funcionais deve ser completa – deve definir todos os requisitos de usuário e refletir as decisões de especificação tomadas – e consistente – os requisitos não devem ter definições contraditórias (PAULA FILHO, 2000). Entretanto, na realidade, em sistemas complexos e grandes, é quase impossível atingir a consistência e a completeza dos requisitos. Isso ocorre, principalmente, em função da complexidade inerente ao sistema e porque as pessoas possuem diferentes pontos de vistas em relação a um problema. Esses problemas somente emergem após uma a