Requisitos de Software

 

Um dos maiores problemas em desenvolver um sistema de software está relacionado à engenharia de requisitos. Essa engenharia consiste em definir o que o sistema deve fazer incluindo suas propriedades essenciais, suas restrições perante o sistema e aos processos de desenvolvimento. Em suma, a engenharia de requisitos serve para fazer a comunicação entre o cliente, os usuários e os desenvolvedores.

Essa engenharia não é apenas um processo técnico. Os requisitos são amplamente influenciados pelas preferencias, recusas e preconceitos dos usuários, abrangendo também conceitos políticos e organizacionais.

Requisitos são descrições dos serviços de um sistema, incluindo suas restrições operacionais. Eles, por muitas vezes refletem as necessidades de seus clientes. O processo para descobrir, analisar, verificar e documentar essas necessidades é chamado de engenharia de software.

Existem dois níveis de requisitos: requisitos de usuários e requisitos de sistema.

Requisitos de Usuário são declarações informais, utilizando diagramas, dos serviços necessários para o sistema e suas restrições.

Requisitos de Sistema definem as funções, os serviços e as restrições, formalmente, utilizando documentações.

Lembrando que ambos têm o mesmo objetivo, apenas estão em níveis diferentes, tendo como o objetivo a comunicar-se com diferentes tipos de leitores.

Os requisitos de um sistema são classificados em dois tipos: requisitos funcionais e requisitos não-funcionais. Ainda pode-se incluir um terceiro tipo: requisito de domínio.

 

Requisitos Funcionais

 

Os requisitos funcionais descrevem o que um sistema deve fazer. Eles dependem diretamente do tipo de software que se está desenvolvendo e dos usuários.

Exemplos:

  1. O usuário deve ser capaz de fazer uma busca em todo o conjunto inicial do banco de dados ou selecionar um subconjunto com base nele.
  2. O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos.
  3. Para cada pedido, deve ser alocado um único identificador, o qual o usuário deve ser capaz de copiar para a área de armazenamentos permanente da conta.

Esses requisitos definem o que o sistema, no caso uma biblioteca, deve fazer.

A imprecisão durante a especificação de requisitos é um grande problema, já que desenvolvedores e afins, podem acabar não os interpretando corretamente.

Todos os requisitos devem ter completeza e consistência. Completeza, pois todos os requisitos exigidos pelo cliente devem ser definidos. Consistência, pois nenhum requisito deve ser ambíguo.

 

Requisitos Não-Funcionais

 

Requisitos não-funcionais não tem relação direta com as especificações fornecidas pelo sistema. Eles geralmente estão relacionados às propriedades emergentes do sistema, como segurança, confiabilidade, armazenamento. Ainda se pode dizer que eles definem restrições, como a representação de dados ou dispositivos de entrada e saída.

Geralmente especificam desempenho, proteção, disponibilidade, dando a eles uma importância maior do que os requisitos funcionais. Falhas em requisitos não-funcionais podem significar inutilidade de sistema. Por exemplo, se um carro não corresponde aos requisitos de segurança, ele não receberá certificação de seguro, e consequentemente sua liberação.

Alguns requisitos não-funcionais podem restringir ferramentas e processos que serão utilizados para o desenvolvimento. Por exemplo, uma empresa já utiliza todo seu sistema em alguma linguagem e especifica que o sistema deve ser montado em cima dessa mesma linguagem.

Requisitos não-funcionais surgem através das necessidades do usuário, ao orçamento, às politicas, restrições de hardware ou software, e até de fatores externos como legislações.

Requisitos não-funcionais são difíceis de se enxergar e de se verificar.

Existem três tipos de requisitos não-funcionais.

  • Requisitos de produtos: Especificam o comportamento do produto. Especificam o desempenho do sistema, o quão rápido ele deve ser, ou a quantidade de armazenamento requerida. Especificam também a confiabilidade, a portabilidade e a usabilidade.
  • Requisitos organizacionais: São derivados de procedimentos da organização do cliente e do desenvolvedor. Podem incluir padrões de processos a serem utilizados, requisitos de implementação, como a linguagem a ser utilizada, e requisitos de entrega, que especificam quando o produto será entregue.
  • Requisitos Externos: abrange todos os fatores externos que podem influencias o sistema e o seu processo de desenvolvimento. Incluem requisitos de interoperabilidade, que define como o sistema interagirá com outros sistemas, requisitos legais, para assegurar seu comportamento dentro das leis governamentais e requisitos éticos, que asseguram a ética perante seus usuários.

Exemplos:

  1. Requisito de produto: A interface de usuário deve ser implementada como simples HTML, sem frames ou applets de Java.
  2. Requisito organizacional: O processo de desenvolvimento do sistema e os documentos a serem entregues devem estar em conformidade com o processo e produtos a serem entregues.
  3. Requisito externo: O sistema não deve revelar quaisquer informações pessoais sobre os usuários do sistema ao pessoal que usa o sistema, com exceção do nome e numero de referência.

 

Requisitos de Domínios

 

São derivados do domínio de aplicação do sistema, em vez das necessidades especificas de cada usuário do sistema. Incluem terminologia especifica de domínio e podem estabelecer cálculos específicos a serem realizados. Se esses requisitos não forem satisfeitos, o sistema poderá não funcionar corretamente.

São importantes, pois refletem os fundamentos do domínio de aplicação.

Exemplos:

  1. Deve existir uma interface com o usuário-padrão para todos os bancos de dados.
  2. Devido às restrições de direitos autorais, alguns documentos devem ser excluídos imediatamente na chegada.
  3. O seguinte cálculo deve ser utilizado: Delta = Controle + Gradiente.