Engenharia de requisitos
Esta página ou seção foi marcada para revisão devido a incoerências ou dados de confiabilidade duvidosa.Janeiro de 2024) ( |
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 oito atividades de alto nível:[1]
- Revisão do processo de requisitos;
- Revisão das demandas dos usuários;
- Esclarecimento das demandas dos usuários;
- Distribuição das tarefas de requisitos;
- Documentação dos requisitos;
- Revisão dos requisitos;
- Revisão dos requisitos pelos usuários;
- Colocação dos requisitos na linha de base.
Este processo deve ser precedido por estudos de viabilidade técnica/financeira 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 com parte deste processo, se incluirmos a fase posterior à produção do documento, é a gestão de mudança (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.
Estudos de viabilidade
editarO estudo de viabilidade deverá culminar com a produção de um relatório e deverá determinar a continuação (ou não) do desenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do projeto e definindo alguns requisitos de alto nível.
O estudo de viabilidade é uma atividade eminentemente de negócio, e que pode eventualmente envolver alguém da área de tecnologia. No entanto quem tem a competência de responder se o projeto vale ou não o investimento é o responsável pelo negócio. O estudo de viabilidade gera informações muito úteis ao início do trabalho da engenharia de requisitos.[2]
Identificação
editarCaso se determine que o projeto é viável, o passo seguinte é a identificação dos requisitos.
Um bom levantamento de requisitos começa sempre pela seleção das melhores fontes de informação que serão usadas para montar a matriz de requisitos, que será matéria-prima para definir o escopo do projeto.[3]
Técnicas para levantamento de requisitos
editarWorkshops de requisitos
editar- O Workshop de Requisitos consiste numa técnica usada através de uma reunião estruturada, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente,[4] para então obter um conjunto de requisitos bem definidos. Ao contrário das reuniões, promove-se a interação entre todos os elementos presentes no workshop fomentando momentos de descontração como forma de dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel é conduzir o workshop e promover a discussão entre os vários intervenientes (ainda que não tenha realmente poder de decisão). As tomadas de decisão devem seguir processos bem definidos e devem resultar de um processo de negociação, mediado pelo facilitador. Uma técnica que é também útil em workshops é o uso de brainstorming (tempestade de ideias) como forma de gerar um elevado número de ideias numa pequena quantidade de tempo. Como resultado dos workshops deve ser produzida documentação que reflita os requisitos e decisões tomadas sobre o sistema a implementar
Estudo etnográfico
editarOs 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.
Outras técnicas de elicitação de requisitos são:
- Surveys;
- JAD;
- Story boarding.[5]
Documento de Especificação de Requisitos
editarApesar da existência dos 3 tipos de especificação vistos nos itens anteriores, existe uma especificação usada como declaração oficial dos requisitos do sistema.
Este documento normalmente é chamado de Especificação de Requisitos de Software (Software Requirements Specification ou SRS), e inclui uma combinação dos requisitos de usuário e de sistema, e tem diferentes utilidades para diferentes leitores[6]:
- Clientes: confirmar a completude dos requisitos e propor alterações.
- Gestores: orçamentar o sistema e planejar o processo de desenvolvimento.
- Engenheiros desenvolvedores e programadores: compreender o sistema a desenvolver.
- Engenheiros de testes: desenvolver testes para validar o cumprimento dos requisitos.
- Engenheiros de manutenção: compreender o sistema e a ligação entre as suas partes visando o suporte técnico e a manutenção.
Existem diversos padrões para este documento, embora não se possa apontar nenhum como o "ideal". Uma estrutura proposta pelo IEEE bastante usada é o IEEE/ANSI 830-1993.[7]
Ver também
editarReferências
- ↑ Engenharia de Software: fundamentos, métodos e padrões. [S.l.: s.n.]
- ↑ Vazquez, Carlos; Simões, Guilherme (2016). Engenharia de Requisitos: Software Orientado ao Negócio. [S.l.]: Brasport
- ↑ Definindo Escopo em Projetos de Software. São Paulo: Novatec. 2015. ISBN 978-85-7522-429-8
|nome1=
sem|sobrenome1=
em Authors list (ajuda) - ↑ este grupo deve ser escolhido levando-se em conta a organização e o contexto em que o sistema será usado
- ↑ «Condições para melhores resultados na elicitação de requisitos». Cloud of Metrics. 8 de Abril de 2019. Consultado em 3 de Julho de 2019
- ↑ Kotonya e Sommerville (1998). Requirements Engineering: Processes and Techniques. Gerald Kotonya, Ian Sommerville. Wiley. 1998.
- ↑ Thayer e Dorfman (1993). Software Requirements Engineering. R. H. Thayer, M. Dorfman. IEEE Computer Society Press. 1993.