Engenharia de Requisitos
Dentro da Engenharia de Software (ES), temos uma especialidade que é a Engenharia de Requisitos(ER), que segundo Sommerville (2003), é o processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema. Mas afinal o que é um Requisito de Sistema?
Requisitos de um sistema, segundo Sommerville (2011), são descrições do que o Sistema DEVE fazer, os serviços que oferece e as restrições a seu funcionamento. Esses requisitos refletem a necessidade dos clientes e para um sistema que serve a uma finalidade determinada, como controlar um dispositivo, colocar um pedido ou encontrar informações. Veja o Processo de Engenharia de Requisitos na figura 1 abaixo:
Figura 1 –Processo de Engenharia de Requisitos
Fonte: Sommerville (2007, p.96)
Vamos esclarecer esse processo?
I. Estudo de viabilidade
O estudo de viabilidade consiste num estudo preliminar de requisitos de negócios, no qual é decidido se vale a pena desenvolver o sistema proposto. Um estudo breve verifica se:
- O sistema contribui para os objetivos da organização?
- O sistema pode ser implementado com a tecnologia atual e dentro do orçamento?
- O sistema pode ser integrado com outros sistemas em operação?
A realização do estudo de viabilidade envolve desde a avaliação de informações, coleta de dados e elaboração de um relatório. Durante esta fase podemos consultar os engenheiros de software, especialistas em tecnologia e os usuários finais para coletarmos as informações, levando em média de 02 (duas) a 03 (três) semanas para concluir as atividades.
II. Elicitação e análise de requisitos
Nesta atividade, os engenheiros trabalham em conjunto com os usuários finais do sistema no intuito de entender odomínio da aplicação. Para tal, envolvem várias pessoas da organização, que são denominadas stakeholders. Você sabe o que é um stakeholder?
 | Curiosidade: O termo Stakeholder é aplicado a qualquer pessoa que terá influência direta ou indireta sobre os requisitos do sistema, podendo ser usuários finais, pessoal de uma organização que venham a ser afetado pelo sistema, engenheiros envolvidos no desenvolvimento ou manutenção do sistema (e/ou outros sistemas relacionados),gerentes de negócios, especialistas no domínio da aplicação e até representantes de sindicatos. |
E os membros da equipe técnica trabalham com o cliente e os usuários para descobrir mais informações sobre o domínio da aplicação, serviços do novo sistema, desempenho e as restrições operacionais.
III. Problemas com a análise de requisitos
Durante o processo de elicitação e análise dos requisitos, encontramos alguns problemas para realizar a atividade, pois:
- Pessoas diferentes podem ter requisitos conflitantes;
- Pessoas expressam os requisitos usando termos próprios;
- Fatores políticos podem influenciar os requisitos do sistema;
- Os requisitos se alteram durante o processo de análise, pois o ambiente econômico e de negócios é dinâmico.
Vamos assistir agora um breve vídeo "O Cometa Halley e as pérolas da comunicação".
O que você achou do vídeo?
Como você enxerga o problema de comunicação:
- no momento de levantar os requisitos?
- no momento de apresentar os requisitos a equipe de desenvolvimento?
- o que você e sua equipe tem feito para resolvere este problema?
IV. Processo de elicitação e análise de requisitos
Podemos verificar que cada organização terá a sua própria versão de um modelo para a obtenção e análise de requisitos, dependendo de fatores locais, nível de conhecimento da equipe, tipos do sistema a ser desenvolvido e aos padrões dos usuários.
As atividades do processo são:
- Obtenção de requisitos - um processo que visa coletar requisitos, em que os requisitos de domínio também são descobertos durante esta atividade.
- Classificação e organização de requisitos – envolve a coleta de requisitos não estruturados, agrupando e organizando em conjuntos coerentes.
- Priorização e negociação de requisitos – atividade relacionada à priorização de requisitos, devido a requisitos conflitantes (quando há vários stakeholder atuando),à procura e à resolução de conflitos por meio de negociações.
- Documentação de requisitos – são documentados e colocados na próxima volta da espiral, podendo ser produzidos documentos de requisitos formais ou informais.
V. Especificação e documentação de requisitos
A especificação de requisitos é uma etapa essencial do processo de desenvolvimento de software, que compreende uma definição completa do comportamento externo de software do sistema ou parte do sistema.
- Requisitos do usuário
São declarações, em linguagem natural e diagramas, sobre os serviços que o sistema oferece e as restrições para a sua operação. São escritos para os clientes.
- Requisitos do sistema
Estabelecem detalhadamente as funções e restrições do sistema. O documento de requisitos, chamado deespecificação funcional, pode servir como um contrato entre cliente e desenvolvedor.
- Especificação de software
Trata de uma especificação abstrata e precisa do software, indicando o que ele deve fazer (sem dizer como) que serve de base para o design e implementação. Acrescenta mais detalhes à especificação funcional e é escrito para a equipe de desenvolvimento.
Ao descrever os requisitos, necessitamos nos atentar às seguintes situações, pois:
- A especificação dos requisitos deve ser completa (deve descrever tudo o que é necessário), consistente (não deve haver conflitos e contradições) e não-ambígua (não deve levar a interpretações diferentes por desenvolvedores e usuários).
- É difícil de atingir, considerando que existem diferentes tipos de requisitos envolvidos.
- Depende da precisão da linguagem utilizada, visto que a linguagem natural, informal é mais apropriada para os requisitos do usuário e do sistema, já as linguagens gráficas, semi formais, são apropriadas para os requisitos do sistema e do software, e as linguagens formais são mais apropriadas para uma especificação formal de software em métodos formais.
Nenhum comentário:
Postar um comentário