qual a diferença ente engenharia de requisitos e elicitação de requisitos
Soluções para a tarefa
A engenharia de requisitos é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo.
O processo de engenharia de requisitos é composto por quatro atividades de alto nível:
· identificação;
· análise e negociação;
· especificação e documentação;
· validação.
Este processo deve ser precedido de estudos de viabilidade que, a partir das restrições do projeto, determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos. Uma outra atividade que se pode considerar que faz também parte deste processo, se incluirmos a fase posterior à produção do documento, é a gestão dos requisitos (change management, sendo que as alterações podem ser causadas pelos mais diversos fatores desde inovações tecnológicas a mudanças na natureza do negócio, entre outras.
A elicitação de requisitos é uma fase muito importante em qualquer projeto de desenvolvimento de software, pois se elaborada de maneira incorreta, todo o projeto estará comprometido.
É importante, pois é nesse momento que identificamos e definimos a estratégia de desenvolvimento do produto/serviço. É agora que conhecemos algumas informações como:
Fonte de Requisitos;
o Quais são as partes interessadas no produto/serviço;
o Quais são as principais necessidades do usuário;
o Definimos as fronteiras do sistema;
o Quais são as premissas e restrições do sistema ou do ambiente.
É normal, que durante a identificação das fontes de requisitos, tenhamos que realizar reuniões com profissionais de todos os níveis hierárquicos e conhecer as necessidades de cada um. Muitas empresas, quando terceirizam o serviço, elegem uma pessoa (stakeholder) para ser o ponto focal entre o contratante e contratada. Isso pode ser muito perigoso, pois caso esse profissional não conheça as reais necessidades dos usuários finais, ou passe alguma informação errada, todo o projeto estará comprometido.
Sei que muitos podem estar pensando que isso não é problema da empresa contratada, pois a responsabilidade é do stakeholder ou contratante, porém, como sempre frisamos, devemos nos preocupar em entregar valor para o nosso cliente, e só atingiremos esse objetivo trabalhando como parceiros.
Por essa razão, sempre que possível, prefira conhecer e conversar pessoalmente com todos os envolvidos no projeto, conhecer suas reais necessidades, e se necessário, fazer a observação “in loco”, que nada mais é que sentar ao lado do operador do sistema por um determinado tempo e conhecer seu trabalho.
Para conhecermos quem são as pessoas interessadas no produto/serviço, devemos fazer perguntas como:
o No caso de sucesso ou falha do projeto, quais as pessoas afetadas?
o Quem são os usuários finais do produto?
o Quem são os responsáveis pela aprovação/reprovação da solução, quando implantada?
o Quem será o responsável pelo desenvolvimento e manutenção do produto?
o Quem são os responsáveis pelos testes?
Definir as fronteiras do sistema ajuda na definição de escopo do sistema. Temos uma visão mais clara do que está dentro e principalmente fora do escopo.
Conhecer as reais necessidades do usuário não significa que atenderemos todos os desejos dele. Temos que nos focar na solução do problema. Como citei anteriormente, nem sempre o usuário sabe de sua real necessidade. Essa etapa é critica. Ter desvios de foco é a coisa mais comum nesse momento.
Identificar premissas e restrições de ambiente é de extrema importância, pois dependendo destas, o valor e o tamanho do projeto podem ser significantemente maiores ou menores.
Engenharia de Requisito: Macromodelo composto de uma série de atividades para tratamento de requisitos e Elicitação de Requisito: Uma das atividades da Engenharia de Requisitos.