quarta-feira, 7 de abril de 2021

Levantamento de Requisitos

Atividades ligadas ao Levantamento de Requisitos

De acordo com o PMBoK (Project Management Body of Knowledge), um guia que reúne o conjunto de Melhores Práticas em Gerenciamento de Projetos produzido pelo Project Management Institute (PMI, 2013, p. 110), o Plano de Gerenciamento dos Requisitos deve compor o Plano de Gerenciamento do Projeto de Software, sendo um documento que objetiva descrever como os requisitos serão analisados, documentados e gerenciados. De acordo com o guia, os componentes do Plano de Gerenciamento dos Requisitos podem incluir a definição:

  • de como as atividades dos requisitos serão planejadas, rastreadas e relatadas;
  • das atividades de gerenciamento da configuração: como as mudanças do produto serão iniciadas, como os impactos serão analisados, rastreados, monitorados e relatados, os níveis de autorização necessários para aprovar tais mudanças etc.;
  • do processo de priorização dos requisitos;
  • das métricas do produto que serão usadas e os argumentos que justificam o seu uso;
  • da estrutura de rastreabilidade que reflita quais atributos dos requisitos serão capturados na matriz de rastreabilidade.

O guia define um processo para a Coleta de Requisitos, que objetiva determinar, documentar e gerenciar as necessidades e requisitos dos stakeholders de forma a atender aos objetivos do projeto.

Os requisitos incluem condições ou capacidades que devem ser atendidas pelo projeto ou estar presentes no produto, serviço ou resultado para cumprir um acordo ou outra especificação formalmente imposta. Os requisitos incluem as necessidades quantificadas e documentadas e as expectativas do patrocinador, cliente e outras partes interessadas. Estes requisitos precisam ser obtidos, analisados e registrados com detalhes suficientes para serem incluídos na linha de base do escopo e medidos uma vez que a execução do projeto se inicie.

Fonte: PMI (2013, p. 112)

O levantamento ou elicitação de requisitos tem como principal objetivo definir e documentar as funções e funcionalidades do sistema necessárias para atender às necessidades e expectativas dos stakeholders. O sucesso do sistema é diretamente influenciado pela atenção ao levantamento e ao gerenciamento dos requisitos.

Pressman (2011, p. 133) afirma que o levantamento de requisitos combina atividades ligadas à análise, negociação e especificação. O autor sugere que os stakeholders devam trabalhar juntos para identificar o problema, propor soluções, negociar abordagens diferentes e especificar os requisitos iniciais da solução, dentro de uma abordagem colaborativa.

Sommerville (2011, p. 70) indica como atividades essenciais ao levantamento de requisitos: descoberta de requisitos; classificação e organização dos requisitos, priorização e negociação dos requisitos e especificação dos requisitos.

A figura ilustra as principais atividades ligadas ao levantamento de requisitos:

Sommerville (2011) enumera os seguintes motivos que tornam a elicitação de requisitos um processo difícil:

  • Os stakeholders usualmente não sabem bem o que querem de um sistema computacional, não conhecem seus limites e muitas vezes solicitam coisas inviáveis;
  • Os stakeholders expressam os requisitos usando seus termos, que têm implícito seu conhecimento de trabalho, e os engenheiros de requisitos podem não compreendê-los;
  • Diferentes stakeholders possuem requisitos distintos e podem expressá-los de forma distinta, então os engenheiros de requisitos devem buscar descobrir semelhanças e conflitos;
  • Fatores políticos, como gerentes desejarem requisitos que aumentem seu poder na organização, podem influenciar os requisitos;
  • Novos requisitos podem surgir em função da entrada de novos stakeholders, mudanças no cenário econômico podem provocar mudanças nos requisitos e, ainda, a importância dos requisitos pode ser alterada.
Negociação

Como podemos notar, caro aluno, a negociação é essencial para balancear as diferentes opiniões e os conflitos provocados pelos diferentes stakeholders no processo de elicitação de requisitos.

Também é importante que os requisitos levantados sejam documentados para que possam ajudar na descoberta de novos requisitos. Os componentes da documentação podem incluir, mas não estão limitados, a:

  • A necessidade do negócio ou oportunidade a ser aproveitada, descrevendo as limitações da situação atual e por que o projeto foi empreendido;
  • Objetivos do negócio e do projeto para permitir rastreamento;
  • Requisitos funcionais descrevendo processos de negócio, informações e interação com o produto de forma apropriada a ser documentada textualmente;
  • Requisitos não funcionais, tais como nível de serviço, desempenho, cuidados, segurança, atendimento a leis e regulamentos etc.;
  • Impactos em outras áreas organizacionais;
  • Impactos em outras entidades internas ou externas à organização.

Para que este processo ocorra com sucesso, os requisitos devem ser claros, completos, sem ambiguidade, implementáveis, consistentes e testáveis, como mostra a tabela. Os requisitos que não apresentem tais qualidades são problemáticos: eles devem ser revistos e renegociados com os clientes e usuários.

TABELA – Características dos requisitos

Não ambíguo

Todo requisito tem apenas uma interpretação possível.

Correto

Todo requisito representa algo requerido do sistema ou funcionalidade a ser construída.

Completo

Contém o que o software deve fazer e atender em todas as situações possíveis.

Compreensível

Todas as pessoas podem facilmente compreender o significado de todos os requisitos com um mínimo de explicação.

Verificável

Atende ao conjunto de técnicas que podem ser usadas para verificar que todo requisito está implementado pelo sistema.

Internamente consistente

Não deve haver requisitos conflitantes entre si.

Externamente consistente

Não deve haver requisitos conflitantes com outra documentação de projeto já definida.

Realizável

Possibilita que um projeto seja implementado corretamente com todos os requisitos declarados.

Conciso

É tão pequeno quanto possível, sem afetar qualquer outra qualidade que deva atender.

Rastreável

É escrito de modo que facilite o “referenciamento” de cada requisito individualmente.

Modificável

Sua estrutura e estilo são tais que qualquer mudança pode ser feita facil, completa e consistentemente.

Anotado por importância relativa

Permite que se possa facilmente determinar qual requisito é mais importante para os clientes.

Anotado por estabilidade relativa

Permite que se possa facilmente determinar qual requisito é mais suscetível à mudança.

Organizado

Permite que se possa facilmente localizar informações e relacionamentos lógicos entre seções adjacentes.

Fonte: Gonsales, 2010

Nenhum comentário:

Postar um comentário