Engenharia de Requisitos, Reuso e Qualidade de Software

Processos de Engenharia de Requisitos

O processo de engenharia de requisitos inclui um estudo de viabilidade, elicitação e análise de requisitos, validação de requisitos e gerenciamento de requisitos.

• A elicitação e a análise de requisitos constituem um processo iterativo, envolvendo entendimento de domínio, coleta, classificação, estruturação, priorização e validação de requisitos.
• Os sistemas têm múltiplos stakeholders com diferentes requisitos.
• Fatores sociais e organizacionais influenciam os requisitos de sistema.
• A validação de requisitos está relacionada a verificações de validade, consistência, completeza, realismo e facilidade de verificação.
• Mudanças de negócio levam, inevitavelmente, a mudanças de requisitos.
• O gerenciamento de requisitos inclui planejamento e gerenciamento de mudanças.

Requisitos de Software

Os requisitos estabelecem o que o sistema deve fazer e definem as restrições sobre suas operações e sua implementação.

• Requisitos funcionais: definem os serviços que o sistema deve fornecer.
• Requisitos não funcionais: restringem o sistema que está sendo desenvolvido ou o processo de desenvolvimento.
• Requisitos de usuário: são declarações de alto nível sobre o que o sistema deve fazer. Esses requisitos devem ser escritos usando linguagem natural, tabelas e diagramas.
• Requisitos de sistema: se destinam a comunicar quais as funções que o sistema deve fornecer.

Um documento de requisitos de software é uma declaração acordada dos requisitos de sistema. O padrão IEEE é um ponto de partida útil para a definição de padrões de requisitos mais detalhados e específicos.

O que é um requisito?

Pode variar de uma declaração abstrata de alto nível de um serviço ou de uma restrição de sistema para uma especificação matemática funcional. Isto é inevitável quando os requisitos podem servir a uma função dual:

• Pode ser a base para uma proposta de um contrato — portanto, deve ser aberta para interpretação;
• Pode ser a base para o contrato em si — portanto, deve ser definido em detalhe;
• Ambas as declarações podem ser chamadas de requisitos.

Tipos de Requisitos

• Requisitos de usuário: Declarações em linguagem natural mais diagramas de serviços que o sistema fornece e suas restrições operacionais. Escritos para os clientes.
• Requisitos de sistema: Um documento estruturado estabelecendo descrições detalhadas das funções, serviços e restrições operacionais do sistema. Define o que deve ser implementado e, assim, pode ser parte de um contrato entre o cliente e o desenvolvedor.

Requisitos Funcionais e Não Funcionais

• Requisitos funcionais: Declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações.
• Requisitos não funcionais: Restrições sobre serviços ou funções oferecidos pelo sistema, tais como restrições de timing, restrições sobre o processo de desenvolvimento, padrões, etc.
• Requisitos de domínio: Requisitos que vêm do domínio de aplicação do sistema e que refletem as características desse domínio.

O Sistema LIBSYS

Um sistema de biblioteca que fornece uma interface única para uma série de bancos de dados de artigos em bibliotecas diferentes. Os usuários podem pesquisar, baixar e imprimir estes artigos para estudo pessoal.

Classificações de Requisitos Não Funcionais

• Requisitos de produto: Requisitos que especificam que o produto entregue deve se comportar de uma maneira particular, por exemplo, velocidade de execução, confiabilidade, etc.
• Requisitos organizacionais: Requisitos que são uma consequência de políticas e procedimentos da organização, por exemplo, padrões de processo usados, requisitos de implementação, etc.
• Requisitos externos: Requisitos que surgem a partir de fatores externos ao sistema e seu processo de desenvolvimento, por exemplo, requisitos de interoperabilidade, requisitos legais, etc.

Reuso de Software

As vantagens do reuso são custos menores, desenvolvimento mais rápido e riscos baixos.

• Design patterns são abstrações de alto nível que documentam soluções bem-sucedidas de projeto.
• Geradores de programa também estão relacionados ao reuso de software — os conceitos reusáveis são embutidos em um sistema gerador.
• Frameworks de aplicação são coleções de objetos concretos e abstratos que são projetadas para reuso por meio de especialização.
• Reuso de produto COTS está relacionado ao reuso de sistemas grandes "de prateleira". Problemas com reuso de COTS incluem a falta de controle sobre a funcionalidade, o desempenho e a avaliação de problemas com interoperações.
• Sistemas ERP são criados pela configuração de um sistema genérico com informações sobre o negócio do cliente.
• Linhas de produto de software são aplicações relativas, desenvolvidas em torno de um núcleo comum de funcionalidade compartilhada.

Verificação e Validação

Verificação e validação não são a mesma coisa. A verificação mostra a conformidade com a especificação; já a validação mostra que o programa atende às necessidades do cliente.

• Planos de teste devem ser definidos para guiar o processo de teste.
• Técnicas de verificação estática envolvem o exame e a análise do programa para detecção de erros.
• Inspeções de programa são eficientes para encontrar erros. Em inspeções, o código de programa é sistematicamente verificado por uma equipe pequena para localizar defeitos de software.
• Ferramentas de análise estática podem descobrir anomalias de programa que podem ser uma indicação de defeitos no código.
• O processo de desenvolvimento Cleanroom depende do desenvolvimento incremental, da verificação estática e dos testes estatísticos.

Verificação Estática e Dinâmica

• Inspeções de software: Relacionadas à análise de representações estáticas de sistema para descobrir problemas (verificação estática). Pode ser suplementado por um documento baseado em ferramenta e análise de código.
• Teste de software: Relacionado ao exercício e à observação do comportamento do produto (verificação dinâmica). O sistema é executado com dados de teste e seu comportamento operacional é observado.

Tipos de Teste

• Teste de validação: Pretende mostrar que o software atende aos seus requisitos. Um teste bem-sucedido é aquele que mostra que um requisito foi adequadamente implementado.
• Teste de defeitos: Testes projetados para descobrir defeitos de sistema. Um teste de defeitos bem-sucedido é aquele que revela a presença de defeitos em um sistema. Abordado no Capítulo 23.

Teste e Debugging

Teste de defeitos e debugging são processos distintos. Verificação e validação estão relacionadas ao estabelecimento da existência de defeitos em um programa. Debugging está relacionado à localização e reparação desses defeitos. O debugging envolve a formulação de uma hipótese sobre o comportamento do programa e o teste dessas hipóteses para encontrar o defeito de sistema.

A Estrutura de um Plano de Teste de Software

• Processo de teste;
• Rastreabilidade de requisitos;
• Itens testados;
• Cronograma de testes;
• Procedimentos de registro de testes;
• Requisitos de hardware e de software;
• Restrições.

Métricas e Medições de Software

• Funcionalidade: é o grau em que o software satisfaz as necessidades declaradas, conforme indicado pelos seguintes sub-atributos: adequabilidade, precisão, interoperabilidade, atendibilidade e segurança.
• Confiabilidade: é o período de tempo em que o software está disponível para uso, conforme indicado pelos seguintes sub-atributos: maturidade, tolerância a falha e recuperabilidade.
• Usabilidade: é o grau em que o software é fácil de usar, conforme indicado pelos seguintes sub-atributos: inteligibilidade, facilidade de aprendizado e operabilidade.
• Eficiência: é o grau em que o software faz uso otimizado dos recursos do sistema, conforme indicado pelos seguintes sub-atributos: comportamento em relação ao tempo e comportamento em relação aos recursos.
• Manutenibilidade: é a facilidade com a qual podem ser feitos reparos no software, conforme indicado pelos seguintes sub-atributos: analisabilidade, estabilidade e testabilidade.
• Portabilidade: é a facilidade com a qual o software pode ser transposto de um ambiente para outro, conforme indicado pelos seguintes sub-atributos: adaptabilidade, instalabilidade, conformidade e permutabilidade.