Engenharia de Requisitos: Análise e Gerenciamento

Engenharia de Requisitos

A engenharia de requisitos é responsável por todas as atividades inerentes ao tratamento dos requisitos de uma solução.

Análise e Gerenciamento de Requisitos

O que são requisitos? Podemos entender requisitos como sendo as propriedades ou comportamento que atendem às características de uma solução proposta para uma demanda de um processo de negócio. A análise de requisitos é a atividade que busca identificar da melhor forma as propriedades e comportamento necessários para atender à solução proposta.

Principais objetivos da análise de requisitos:

• Definir o escopo do sistema.
• Fornecer uma base para o planejamento do projeto de desenvolvimento, incluindo definições de custo e prazo.
• Fornecer uma base para o planejamento das iterações.

O escopo de um projeto é definido pelo conjunto de requisitos funcionais e não funcionais do mesmo. O escopo define os limites do projeto.

Tipos de Requisitos:

• Funcionais (Functionality)
• Usabilidade (Usability)
• Confiabilidade (Reliability)
• Desempenho (Performance)
• Suportabilidade (Supportability)

Requisitos Funcionais:

Definem o processo de interação entre os Atores e o sistema. Em geral, são capturados em técnicas como Especificação de Casos de Uso, Especificação de Histórias, dentre outras. (Ator é tudo aquilo que interage diretamente com o Sistema, seja um usuário, seja outro sistema, interno ou externo).

Principais objetivos dos Requisitos Funcionais:

• Identificar todos os possíveis cenários de uso da solução proposta.
• Gerar fluxos de eventos completos e significativos.
• Atuar como base para a compreensão dos processos de negócios analisados.

Os requisitos funcionais agem como base para o planejamento de iterações, a modelagem do sistema (design), o planejamento de testes e a rastreabilidade de requisitos (gerenciamento de configuração e mudanças).

Requisitos Não Funcionais:

Definem as demais características comportamentais do sistema. Em geral, não são capturados nas especificações dos requisitos funcionais e devem compor um documento específico. Um requisito não funcional inerente a um requisito funcional específico pode ser definido junto à especificação desse requisito funcional.

Exemplos de Requisitos Não Funcionais:

• Requisitos legais e de regulamentação.
• Padrões de aplicativos.
• Requisitos URPS.
• Requisitos de Sistemas Operacionais, compatibilidade e restrições de design (por exemplo, uso de padrões de projetos para a arquitetura .NET).
• Requisitos de arquitetura de hardware.
• Servidor de protocolos de comunicação, etc.

Em geral, ao definirmos uma solução para uma demanda durante a análise de negócios, definimos quais são as principais características desta solução. A estas características damos o nome de Features. Uma feature é definida por um conjunto de requisitos, sejam eles funcionais ou não funcionais.

Necessidades dos Stakeholders = Features

Tipos de Requisitos -> Requisitos de software, Restrições de arquitetura, Requisitos Funcionais, Não funcionais.

O que são Requisitos (Revisão):

A engenharia de requisitos tem como principal objetivo garantir que o time de desenvolvimento resolva o problema correto e construa a solução correta. Para tal, segue uma abordagem sistemática para: compreender o problema; elicitar, organizar e documentar os requisitos; e gerenciar as mudanças nos requisitos em uma aplicação.

Níveis de Requisitos:

• Necessidade dos stakeholders.
• Características do sistema (ou produto).
• Requisitos de software.
• Necessidade dos stakeholders.
• Modelo de arquitetura.
• Procedimento de testes.
• Procedimento de Deployment.

Problemas Comuns em Requisitos:

• Requisitos não implementados ou implementados parcialmente.
• Áreas de negócios parcialmente ou não analisadas corretamente.
• Necessidades dos stakeholders não avaliadas corretamente.
• Requisitos elicitados de forma indevida ou pobremente elicitados.
• Pouco ou nenhum envolvimento dos stakeholders com o processo de elicitação dos requisitos.
• Desenvolvedores que não respeitam o escopo do projeto.
• Requisitos não mantidos de maneira formal.
• Não existe tratamento formal para o processo de solicitação de mudanças.

Gerenciamento de Requisitos:

Gerenciar requisitos pode parecer uma atividade simples ou trivial, porém está longe disso e por diversas razões: nem sempre os stakeholders conhecem suas reais necessidades; conforme o número de requisitos aumenta, a capacidade de gerenciar os requisitos diminui; os relacionamentos entre os requisitos não são facilmente gerenciáveis; em geral, analistas da área de T.I têm dificuldades em descrever requisitos em uma linguagem não técnica, dificultando o entendimento por parte dos stakeholders.

Os requisitos não são óbvios, eles se originam de várias fontes, pois nem sempre são simples de serem expressos em palavras. Eles são complexos de se gerenciar, pois os requisitos são dinâmicos.

Objetivo Principal do Gerenciamento de Requisitos:

Manter o conjunto de requisitos de um projeto de desenvolvimento de software com clareza. Um bom plano de gerenciamento de requisitos deve:

• Manter uma boa qualidade dos requisitos.
• Definir as características de cada atributo.
• Permitir a rastreabilidade entre requisitos e a rastreabilidade dos requisitos com os demais artefatos gerados pelo projeto.

A meta é entregar produtos de qualidade, no prazo, respeitando o orçamento proposto e que atinjam a real necessidade dos stakeholders.

Plano de Gerenciamento de Requisitos:

Um bom plano de gerenciamento de requisitos deve conter:

• Os tipos de requisitos que serão elicitados e quando elicitá-los.
• Quais atributos serão valorados para cada tipo de requisito.
• Quais requisitos serão rastreados.
• As guias de gerenciamento de requisitos.

Qualidade de Software:

O conceito principal de qualidade de software, em uma visão contemporânea, explicita que o foco do processo de desenvolvimento está em compreender todas as necessidades dos stakeholders, bem como verificar e validar todos os produtos de trabalho gerados.

Manter o equilíbrio é fundamental: Prazo, Recursos, Custos = Escopo

Requisitos pela Concordância:

A definição adequada dos requisitos de um sistema permite que o documento resultante da análise de requisitos sirva como um apoio para a obtenção da concordância sobre o escopo do projeto por parte do time de desenvolvimento e dos stakeholders. A boa documentação dos requisitos oferece:

• Um documento de suporte ao time de desenvolvimento quando os stakeholders não estão disponíveis para sanar possíveis dúvidas.
• Um documento de compromisso entre o time de desenvolvimento e os stakeholders.
• Um critério de validação e aceitação dos sistemas pelos stakeholders.

Avaliação de Desempenho:

Um bom plano de gerenciamento de requisitos permite ao time de desenvolvimento controlar efetivamente o processo de verificação e validação de seus produtos de trabalho entregues. Desta forma, o time tem condições de avaliar a sua produtividade e gerar métricas seguras que possam permitir uma melhor avaliação de prazos e custos em projetos futuros. O uso adequado de métricas oferece à equipe uma melhor condição de planejamento de suas atividades.

Fatores Críticos de Sucesso:

Vários são os fatores críticos de sucesso no desenvolvimento de um projeto, e muitos deles estão diretamente vinculados à gerência de requisitos. Dentre eles podemos citar:

• Suporte do setor estratégico da equipe de desenvolvimento.
• Envolvimento dos usuários.
• Capacidade técnica do gerente de projetos.
• Objetivos de negócios claramente especificados.
• Escopo minimizado, ou ao menos claramente especificado.
• Ambiente de desenvolvimento bem estruturado.
• Metodologia formal.
• Estimativas confiáveis, entre outras.

Como o Time se Envolve com Requisitos:

Analistas de requisitos, desenvolvedores e testadores podem participar efetivamente da atividade de gerência de requisitos:

• Monitorando a aderência às melhores práticas de desenvolvimento.
• Verificando o processo de elicitação de requisitos.
• Documentando requisitos.
• Participando na revisão dos requisitos.
• Participando efetivamente na gerência de mudanças.
• Revisando os resultados da rastreabilidade.
• Verificando a qualidade, a testabilidade e a completude de cada requisito.