Processos De Gerenciamento

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 prototipificação 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 utilizadores é, para eles, um aspecto crítico.

4.3.5 - Estudo etnográfico

Os Estudos Etnográficos são uma análise do componente social das tarefas desempenhadas numa dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para levá-las 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 processá-los 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.

5 - Análise e negociação dos requisitos

Após a identificação dos requisitos do sistema, segue-se à etapa de análise e negociação dos mesmos.

5.1 - Atividades envolvidas

Algumas das atividades envolvidas na análise de requisitos incluem:

• Classificação: agrupamento de requisitos em "módulos" para facilitar a visão global do funcionamento pretendido para o sistema.

• Resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante resolver estes conflitos o mais breve possível.

• Prioritização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa); obviamente, este pode ser um factor gerador de conflitos.

• Confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade (de acordo com o que se pretende do sistema).

Estas fases não são independentes entre si, pois uma informação obtida numa delas pode servir inclusive para as demais fases.

A identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio do futuro sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do sistema a cada ciclo de trabalho.

5.2 – Dificuldades

As dificuldades encontradas na análise são de diversas naturezas:

• Factores externos (políticos) podem influenciar os requisitos (alguma parte interessada, com poder de decisão, pode exigir requisitos específicos que sirvam aos seus interesses e não aos da organização, ou forçar o seu ponto de vista em detrimento dos demais interessados que irão operar o sistema).

• O ambiente (económico e/ou organizacional) em que a análise é feita é possue fatores dinâmicos, e como tal os requisitos estão sujeitos a alterações em decorrência destes (por exemplo: novas partes interessadas são envolvidas no projeto, ou alterações em prazos e orçamentos disponíveis).

5.2 - Negociações

Relativo à negociação, torna-se necessário ter alguns cuidados para que esta decorra sem problemas, chegando-se logo a consensos. Para tanto, faz-se algumas sugestões:

• Saber lidar com ataques pessoais (evitando-os sempre que possível, remetendo a sua resolução para mais tarde, fora de reunião), de preferência nunca tomando partidos.

• Fomentar a justificação das posições (negativas) tomadas pelos intervenientes na negociação.

• Salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos os envolvidos.

• Relatar restrições, quando se torna óbvio que as actuais não conseguem levar a um consenso.

6 - Validação

Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de facto, ao sistema que o cliente pretende.

À semelhança do que sucede na análise dos requisitos, pretende-se encontrar problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos.

A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à dimensão do projecto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior a alterações no código ou design, este tipo de erros traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído.

Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os seguintes atributos dos requisitos:

• Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especificação final obtida.

• Consistência:

...