Pular para o conteúdo principal

Engenharia de Requisitos

Os diversos relacionamento e restrições que os requisitos exercem uns sobre os outros são muito difíceis de ser controlados e gerenciados. Principalmente se considerarmos que algumas decisões de design que afetam um ou mais requisitos só serão tomadas mais adiante do desenvolvimento. Por este motivo, os requisitos precisam ser gerenciados durante todo o desenvolvimento. Um exemplo simples é a decisão de requisitos de segurança mais restritos que podem ir de encontro ao requisito de melhor desempenho.

A importância e complexidade de todas as atividades relacionadas aos requisitos levaram, no início dos anos 90, ao surgimento da Engenharia de Requisitos. O objetivo desta denominação é ressaltar que o processo de definir os requisitos de software é uma atividade extremamente importante e independente das outras atividades da engenharia de software. Ela requer fundamentação e processos próprios, e que devem ser planejados e gerenciados ao longo de todo o ciclo de vida.

Os objetivos da Engenharia de Requisitos podem ser categorizados em três grupos principais [Zave]:

  • Investigação de objetivos, funções e restrições de uma aplicação de software
    • Ultrapassar as barreiras de comunicação
    • Gerar estratégias para converter objetivos vagos em propriedades ou restrições específicas
    • Compreender prioridades e graus de satisfação
    • Associar requisitos com os vários agentes do domínio
    • Estimar custos, riscos e cronogramas
    • Assegurar completude
  • Especificação do software
    • Integrar representações e visões múltiplas
    • Avaliar estratégias de soluções alternativas que satisfaçam os requisitos
    • Obter uma especificação completa, consistente e não ambígua
    • Validar a especificação - verificar que ela satisfaz aos requisitos
    • Obter especificações que sejam apropriadas para as atividades de design e implementação
  • Gerenciamento da evolução e das famílias do software
    • Reutilização de requisitos durante o processo de evolução
    • Reutilização de requisitos no desenvolvimento de software similares
    • Reconstrução de requisitos

A engenharia de requisitos é inerentemente abrangente, interdisciplinar e aberta. Ela lida com a descrição de observações do mundo real através de notações apropriadas.

Os benefícios da Engenharia de Requisitos são:

  • Concordância entre desenvolvedores, clientes e usuário sobre o trabalho a ser feito e quais os critérios de aceitação do sistema.
  • Uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas e equipamentos)
  • Melhoria na usabilidade, manutenibilidade e outras qualidades do sistema.
  • Atingir os objetivos com o mínimo de desperdício

Uma boa especificação de requisitos deve ser:

  • Clara e não-ambígua
  • Completa
  • Correta
  • Compreensível
  • Consistente
  • Concisa
  • Confiável

(Veja mais em Dorfman, Merlin - Requirements Engineering)

Técnicas de levantamento de requisitos

Um dos objetivos da Engenharia de Requisitos é ultrapassar barreiras de comunicação entre os clientes e usuários e os analistas para que os requisitos possam capturados e modelados corretamente.

Dentre as técnicas mais importantes para a comunicação podemos citar três:

  • Entrevistas
  • Observação in loco
  • Encontros

Estas três técnicas são complementares e podem todas ser usadas numa mesma análise de requisitos. A entrevista é normalmente a primeira técnica utilizada. Analistas entrevistam clientes para definir os objetivos gerais e restrições que o software deverá ter. A entrevista deve ser feita de forma objetiva visando obter o máximo de informações do cliente. Diversas seções de entrevistas podem ser marcadas.

Na observação in loco os analistas devem estar inseridos na rotina de trabalho da organização tentando entender e descrever as principais atividades que são realizadas. Na observação devem ser identificadas quais as atividades podem ser automatizadas, quem são os potenciais usuários, quais tarefas eles querem realizar com a ajuda do novo sistema, etc. A observação deve ser complementada com entrevistas específicas com os futuros usuários.

Os encontros são reuniões envolvendo analistas, clientes e usuários que têm por objetivo exclusivamente realizar o levantamento de informações, a descrição dos problemas atuais e indicar metas futuras e requisitos do sistema. Os encontros devem ser realizados em um local neutro (fora da organização), coordenados por um moderador que também não deve pertencer ao grupo dos envolvidos (stakeholders) e normalmente duram de 1 a 3 dias. Nos encontros as informações que vão sendo levantadas vão sendo afixadas em painéis na sala de encontro para que possam ser analisadas e validadas pelos clientes e usuários. Ao final do encontro os analistas devem elaborar um relatório descrevendo os requisitos analisados.

Modelos de documentos de especificação de requisitos

O resultado final da análise e especificação de requisitos e das outras atividades da fase de definção deve ser apresentado aos clientes para que eles possam validá-lo. Este documento oferece a concordância entre clientes, analistas e desenvolvedores sobre o que deve ser desenvolvido. É utilizando este documento que as atividades da fase de desenvolvimento (design e programação) serão validadas.

Cada desenvolvedor utiliza um modelo específico para elaborar este documento. A sua estrutura muitas vezes depende do método que está sendo utilizado. Em linhas gerais este modelo deve ser basicamente textual, utilizando o mínimo de termos técnicos, e ilustrados como modelos gráficos que demonstrem mais claramente a visão que os analistas tiveram dos problemas e dos requisitos para o futuro sistema.

Vamos apresentar, a seguir, dois modelos de documentos encontrados na literatura. Estes modelos descrevem não apenas a especificação dos requisitos, mas os resultados do estudo de viabilidade e o processo de desenvolvimento.

Pressman apresenta o seguinte documento de especificação de requisitos de software:


I. Introdução

1. Referências do Sistema
2. Descrição Geral
3. Restrições de projeto do software

II. Descrição da Informação

1. Representação do fluxo de informação

a. Fluxo de Dados
b. Fluxo de Controle

2. Representação do conteúdo de informação
3. Descrição da interface com o sistema

III Descrição Funcional

1. Divisão funcional em partições
2. Descrição funcional

a. Narativas
b. Restrições/limitações
c. Exigências de desempenho
d. Restrições de projeto
e. Diagramas de apoio

3. Descrição do controle

a. Especificação do controle
b. Restrições de projeto

IV. Descrição Comportamental

1. Estados do Sistema
2. Eventos e ações

V. Critérios de Validação

1. Limites de desempenho
2. Classes de testes
3. Reação esperada do software
4. Considerações especiais

VI. Bibliografia
VII Apêndice

Uma proposta alternativa é a de Farley. De acordo com ele, um documento de especificação de requisitos deve possui as seguintes seções:

  • Visão geral do produto e Sumário
  • Ambientes de desenvolvimento, operação e manutenção
  • Interfaces Externas e Fluxo de Dados
  • Requisitos Funcionais
  • Requisitos de Desempenho
  • Tratamento de Exceções
  • Prioridades de Implementação
  • Antecipação de mudanças e extensões
  • Dicas e diretrizes de Design
  • Critérios de aceitação
  • Índice Remissivo
  • Glossário
Referências

Dorfman, Merlin - Requirements Engineering

Zave, Pamela - Classification of Research Efforts in Requirements Engineering - ACM Computing Surveys, vol. 29, no 4, 1997.

Comentários

Anônimo disse…
Parabéns pelo Blog Jair, excelente explicação deste artigo, de forma clara e objetiva. Contribuiu muito para o meu aprendizado

Postagens mais visitadas deste blog

O Modelo Espiral

O objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos processos específicos. Isto significa que podemos encaixar nele as principais características dos modelos vistos anteriormente, adaptando-os a necessidades específicas de desenvolvedores ou às particularidades do software a ser desenvolvido. Este modelo prevê prototipação, desenvolvimento evolutivo e cíclico, e as principais atividades do modelo cascata. Sua principal inovação é guiar o processo de desenvolvimento gerado a partir deste metamodelo com base em análise de riscos e planejamento que é realizado durante toda a evolução do desenvolvimento. Riscos são circunstâncias adversas que podem surgir durante o desenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto. São exemplos de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentas que não podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou que serão utilizados no produto final, etc.

O Modelo Evolutivo

O modelo evolutivo descreve um processo na qual o software deve ser desenvolvido de forma a evoluir a partir de protótipos iniciais. Para entender melhor este modelo é importante entender o que é prototipação (ou prototipagem). Prototipação é uma abordagem baseada numa visão evolutiva do desenvolvimento de software, afetando o processo como um todo. Esta abordagem envolve a produção de versões iniciais - "protótipos" - de um sistema futuro com o qual pode-se realizar verificações e experimentações para se avaliar algumas de suas qualidades antes que o sistema venha realmente a ser construído. Objetivos da Prototipação Num projeto de software várias questões podem ser respondida com a construcão de protótipos. Nas situações típicas de desenvolvimento podemos distinguir entre diferentes objetivos na prototipação: Exploratória - é quando o protótipo é usado para ajudar a esclarecer requisitos dos usuários com respeito ao sistema futuro. Uma prototipação também é exploratória

Sistemas Computacionais

Um sistema computacional (ou baseado em computador) é aquele que automatiza ou apóia a realização de atividades humanas através do processamento de informações. Um sistema baseado em computador é caracterizado por alguns elementos fundamentais. Hardware Software Informações Usuários Procedimentos ou Tarefas Documentação O hardware corresponde às partes eletrônicas e mecânicas (rígidas) que possibilitam a existência do software, o armazenamento de informações e a interação com o usuário. A CPU, as memórias primária e secundária, os periféricos, os componentes de redes de computadores, são exemplos de elementos de hardware. Um único computador pode possibilitar a existência de diversos sistemas e um sistema pode requisitar diversos computadores. O software é a parte abstrata do sistema computacional que funciona num hardware a partir de instruções codificadas numa linguagem de programação. Estas instruções permitem o processamento e armazenamento de informações na for