“A engenharia de requisitos (ER) é o processo de elicitar necessidades e desejos dos stakeholders e desenvolvê-los em um conjunto acordado de requisitos detalhados que podem servir como base para todas as outras atividades de desenvolvimento subsequentes” (Pohl & Ulfat-Bunyadi, 2013)
Dimensões do processo de engenharia de requisitos
Apresentamos a seguir as dimensões deste processo (que deve estar integrado com algum processo de desenvolvimento de produtos ou serviços ou processos) com base na mesma referência da definição sucinta e formal da engenharia de requisitos, apresentada acima.
A engenharia de requisitos é dividida em três dimensões.
| Apesar do foco da publicação utilizada ser em desenvolvimento de sistemas de informação, essas dimensões também podem ser consideradas para outros tipos de desenvolvimentos. Por isso, ao ler o termo “sistemas”, imagine também outros possíveis objetos de inovação, tais como, produtos, serviços, processos, campanhas de marketing etc. |
Dimensão do conteúdo (anteriormente denominado de dimensão da especificação): O objetivo desta dimensão é chegar a uma especificação completa do sistema, o que significa que todos os requisitos relevantes são conhecidos e cada requisito é compreendido no nível de detalhe necessário. Assim, esta dimensão lida com o conhecimento adquirido durante a engenharia de requisitos sobre os requisitos e as restrições (independentemente de como esse conhecimento é representado).
- início do processo de ER: a compreensão do sistema e seus requisitos é tipicamente opaca.
- final do processo de ER: a compreensão sobre os requisitos deve ser o mais completa possível, conhecendo todos os requisitos funcionais, requisitos de qualidade e restrições, no nível de detalhe necessário.
Dimensão da documentação (anteriormente denominado de dimensão da representação): O objetivo é documentar o conteúdo obtido durante a ER para evitar interpretações erradas. Deve-se utilizar linguagens de documentação apropriadas e estabelecer, ao final do processo de ER, uma especificação de requisitos que esteja em conformidade com as regras de especificação definidas para o projeto de desenvolvimento.
- início do processo de ER: utiliza-se principalmente a linguagem natural (representações informais) para documentar os requisitos para o sistema.
- final do processo de ER: todos os requisitos devem ser documentados usando uma linguagem formal, embora a especificação final dos requisitos não necessariamente tenha que ser formal. A escolha da linguagem depende do uso da informação e dos stakeholders que utilizam a documentação.
Exemplos de artefatos conceituais para documentação de requisitos (não foram extraídos da publicação citada):
|
Dimensão do acordo (agreement): O objetivo dentro da dimensão do acordo é alcançar um consenso sobre os requisitos entre todos os stakeholders envolvidos no processo de ER.
- início do processo de ER: No início do processo de ER, os stakeholders geralmente têm visões diferentes em relação aos objetivos e aos requisitos do sistema.
- final do processo de ER: Essas visões diferentes devem ter convergido durante o desenvolvimento, ou seja, conflitos devem ter sido detectados e resolvidos e uma visão comum e integrada sobre os objetivos e os requisitos que o sistema deve cumprir deve ter sido estabelecida.
O progresso em uma dimensão pode impactar o progresso nas outras duas dimensões, tanto de maneira positiva quanto negativa.
Por exemplo, a elicitação de novos requisitos pode levar a novos conflitos entre os stakeholders ou pode revelar conflitos existentes, impactando assim nas outras dimensões.
| Leia mais na flexM4i sobre: – a definição de requisito – a definição de gestão de requisitos, que contém um item que compara com a engenharia de requisitos – a definição de QFD – o Método MoSCoW para priorização de requisitos – o Modelo de Kano para classificação de requisitos – os Elementos de valor – a Metodologia de engenharia de requisitos em sistemas produto-serviço |
Pohl, K., & Ulfat-Bunyadi, N. (2013). The Three Dimensions of Requirements Engineering: 20 Years Later. Seminal Contributions to Information Systems Engineering, 81–87. https://doi.org/10.1007/978-3-642-36926-1
« retornar para home do glossário