No contexto de desenvolvimento ágil e ambientes dinâmicos, é essencial derivar um conjunto completo de requisitos de software estéveis para, então, prosseguir ao projeto, construção e teste do sistema.  

Segundo Pressman, a engenharia de requisitos abrange um total de seis tarefas: concepção, levantamento, elaboração, especificação, validação e gestão.  

É prudente distinguir os diferentes níveis de descrição no processo de engenharia de requisitos. Uma possível abordagem seria separá-los em requisitos de sistema para indicar os requisitos abstratos de alto nível e requisitos de usuário para indicar a descrição detalhada do que o sistema deve fazer.  

Em um cenário ideal, engenheiros de software e stakeholders trabalham juntos no mesmo time. Os stakeholders são aqueles afetados de alguma maneira pelo sistema, não sendo recomendado considerar os usuários finais, visto que geralmente possuem apenas uma vaga ideia dos requisitos. 

Os requisitos de sistema de software são classificados frequentemente como funcionais ou não funcionais. Um requisito não funcional pode ser descrito como um atributo de qualidade, de segurança ou de restrições de tempo, por exemplo, e se aplica frequentemente ao sistema como um todo.