Engenharia de requisitos: diferenças entre revisões

Conteúdo apagado Conteúdo adicionado
m Foram revertidas as edições de 170.78.99.26 para a última revisão de 189.57.51.34, de 10h37min de 2 de abril de 2018 (UTC)
Etiqueta: Reversão
Linha 75:
 
====Cenários (Série de Eventos Hipotéticos)====
[[Uma Thurman|Uma]] forma de levar as pessoas a imaginarem o comportamento de um sistema é o uso de cenários. Através de exemplos práticos descritivos do comportamento de um sistema, os seus usuários podem comentar acerca do seu comportamento e da interação que esperam ter com ele. Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de sistema. De um modo geral, os cenários devem incluir os seguintes elementos:
* estado do sistema no início do cenário;
* sequência de eventos esperada (na ausência de erros) no cenário;
Linha 83:
 
====Prototipagem====
O uso de [[prototipagem]] é feito em diversas fases do processo de engenharia de requisitos (por exemplo na identificação, análise e validação). Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis. Neste tipo de abordagem apenas são desenvolvidas algumas funcionalidades sendo normalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por parte do utilizador e que lhe podem trazer maior valor acrescentado (principalmente na prototipagem evolutiva, isto é, aquela que mais tarde é evoluída para a fase de desenvolvimento). O uso de protótipos deve ser considerado apenas mediante uma análise custo-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente crescer, sendo particularmente úteis em situações em que a interface com os usuários é, para eles, um aspecto crítico.
O uso de [[prototipagem]]
 
====Estudo etnográfico====
é feito em diversas fases do processo de engenharia de requisitos (por exemplo na identificação, análise e validação). Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis. Neste tipo de abordagem apenas são desenvolvidas algumas funcionalidades sendo normalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por parte do utilizador e que lhe podem trazer maior valor acrescentado (principalmente na prototipagem evolutiva, isto é, aquela que mais tarde é evoluída para a fase de desenvolvimento). O uso de protótipos deve ser considerado apenas mediante uma análise custo-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente crescer, sendo particularmente úteis em situações em que a interface com os usuários é, para eles, um aspecto crítico.
Os [[Estudo etnográfico|Estudos Etnográficos]] são uma análise de componente social das tarefas desempenhadas numa dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de se esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo. Através de uma observação direta das atividades realizadas durante um período de trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais. Esta observação pode ser acompanhada de registros áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado. Nesta técnica assume-se que o representante do cliente observado desempenha as suas funções "corretamente", pelo que convém ter algum cuidado na escolha do mesmo.
 
==Análise e negociação dos requisitos==
Linha 203 ⟶ 204:
 
====Análise de consistência automática====
Através da especificação formal de modelos para o sistema é possível, recorrendo a ferramentas adequadas (como as [[ferramentas CASE]]), testar de forma automática a consistência dos modelos ccriados; apenas a consistência é testada nesta técnica, pelo que tem de ser complementada com uma das outras técnicas referidas.
 
===Recomendações===
A fase de validação não deve ser encarada de ânimo leve: trata-se de uma fase muito importante na engenharia de requisitos e da qual dependem elevados custos a médio e longo prazo.
 
Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos em validação de requisitos) é bastante falível e regra geral há erros que não são encontrados num primeiro momento, o que leva inevitavelmente a discordâncias numa fase posterior, já com o documento validado e o projeto em desenvolvimento ou concluído. Quando isto sucede, torna-se necessário negociar e chegar a um acordo quanto à forma de corrigir o erro detectado.
 
==Gestão de requisitos==