Introdução à Engenharia de Requisitos e Técnicas de Elicitação

Este artigo faz parte de uma série de texto com fins didáticos para a disciplina [IF977] Engenharia de Software do curso de Bacharelado em Sistemas de Informação do Centro de Informática UFPE.

A artigo anterior foi Metodologias Ágeis e SAFe.

A engenharia de requisitos desempenha um papel essencial no ciclo de vida do desenvolvimento de software, pois estabelece a base para a construção de sistemas que atendam às expectativas dos stakeholders. Essa disciplina abrange desde a identificação e documentação de requisitos até a análise e validação desses elementos. Este artigo apresenta os conceitos de requisitos funcionais e não funcionais, bem como técnicas de elicitação amplamente utilizadas para compreender as necessidades de um projeto de software.

Requisitos Funcionais e Não Funcionais

Os requisitos de software são a base para a construção de sistemas que atendam às expectativas dos stakeholders, estabelecendo diretrizes claras sobre o que o sistema deve fazer e como deve operar. Esta seção discute os dois principais tipos de requisitos: funcionais e não funcionais, destacando sua importância, exemplos práticos e desafios associados.

Requisitos Funcionais

Os requisitos funcionais descrevem as ações ou comportamentos específicos que o sistema deve executar para atender às necessidades dos usuários. Eles respondem à pergunta "o que o sistema deve fazer?". Esses requisitos são frequentemente documentados como histórias de usuário, casos de uso ou especificações detalhadas.

Por exemplo, em um sistema de comércio eletrônico, requisitos funcionais podem incluir:

• Permitir que os usuários criem contas.
• Oferecer a funcionalidade de busca de produtos por categorias.
• Processar pagamentos de forma segura e eficiente.

A clareza e especificidade desses requisitos são essenciais para garantir que os desenvolvedores e demais membros da equipe compartilhem um entendimento comum sobre as funcionalidades esperadas. No entanto, sua definição pode ser desafiadora, especialmente em projetos com múltiplos stakeholders cujas necessidades podem ser conflitantes.

Requisitos Não Funcionais

Os requisitos não funcionais definem critérios de qualidade e restrições sob as quais o sistema deve operar. Eles não estão diretamente relacionados às funcionalidades, mas influenciam a experiência do usuário e a eficiência operacional do sistema. Exemplos comuns incluem desempenho, segurança, escalabilidade e usabilidade.

Continuando com o exemplo de comércio eletrônico, requisitos não funcionais podem incluir:

• O tempo de carregamento de cada página não deve exceder dois segundos.
• O sistema deve suportar até 10.000 acessos simultâneos durante promoções.
• As transações financeiras devem ser protegidas por criptografia.

Requisitos não funcionais, frequentemente chamados de atributos de qualidade, podem ser mais difíceis de mensurar e priorizar. No entanto, sua importância é crucial para garantir a confiabilidade e a aceitação do sistema.

Relação e Equilíbrio entre os Requisitos

A distinção entre requisitos funcionais e não funcionais é fundamental, mas ambos são interdependentes. Um sistema funcionalmente robusto pode falhar se seus requisitos não funcionais não forem adequadamente considerados. Por exemplo, um sistema de busca eficiente perde sua eficácia se os resultados demorarem muito para carregar.

O equilíbrio entre os dois tipos de requisitos deve ser cuidadosamente gerenciado, especialmente em projetos com restrições de tempo e orçamento. Priorização adequada, validação contínua e colaboração entre stakeholders são práticas recomendadas para garantir que ambos sejam tratados de maneira eficaz.

Conexão com Técnicas de Elicitação

Tendo compreendido os requisitos funcionais e não funcionais, o próximo passo é explorar técnicas de elicitação que permitam identificá-los de forma eficiente. Na próxima seção, abordaremos métodos como entrevistas, workshops e prototipagem, que auxiliam na captura de requisitos claros e alinhados às necessidades dos usuários.

Técnicas de Elicitação de Requisitos

A elicitação de requisitos é um dos pilares da engenharia de requisitos, representando o processo de identificar, coletar e esclarecer as necessidades dos stakeholders. Essa atividade é fundamental para garantir que o sistema a ser desenvolvido atenda às expectativas e limitações do contexto. Diversas técnicas de elicitação são amplamente utilizadas, cada uma com suas particularidades, vantagens e desafios. Esta seção explora as principais técnicas de elicitação, suas aplicações práticas e critérios para escolha.

Entrevistas

As entrevistas são uma das técnicas mais comuns de elicitação. Elas envolvem a realização de conversas estruturadas, semiestruturadas ou abertas com os stakeholders, permitindo a coleta direta de informações sobre suas necessidades, expectativas e desafios. As entrevistas são úteis para obter insights detalhados, especialmente em contextos onde os stakeholders têm uma visão clara do que esperam do sistema.

Por exemplo, ao desenvolver um sistema para gestão hospitalar, uma entrevista com profissionais da saúde pode ajudar a identificar fluxos críticos, como o agendamento de consultas e o registro de prontuários. Apesar de eficazes, as entrevistas podem ser limitadas pela subjetividade das respostas e pela dificuldade em capturar aspectos implícitos.

Workshops

Os workshops são reuniões colaborativas que reúnem múltiplos stakeholders para discutir e priorizar requisitos. Essa técnica é particularmente eficaz para alinhar expectativas em projetos que envolvem diferentes departamentos ou áreas de uma organização. Durante um workshop, atividades como brainstorming e exercícios de priorização ajudam a gerar consenso e identificar requisitos prioritários.

Por exemplo, ao projetar uma plataforma de e-commerce, um workshop pode envolver representantes das áreas de marketing, TI e logística para determinar funcionalidades essenciais, como métodos de pagamento e opções de entrega.

Observação e Shadowing

A observação consiste em acompanhar os stakeholders durante a execução de suas tarefas, enquanto o shadowing é uma abordagem mais imersiva, na qual o analista participa ativamente do ambiente. Essas técnicas são úteis para identificar requisitos que os stakeholders podem não expressar verbalmente, mas que são evidentes no contexto de suas atividades.

Por exemplo, ao desenvolver um sistema para operadoras de call center, a observação pode revelar a necessidade de funcionalidades como acesso rápido a scripts de atendimento ou integração com sistemas de CRM.

Análise de Documentos

A análise de documentos é uma técnica passiva que envolve o exame de materiais existentes, como manuais, relatórios e diagramas. Ela é especialmente útil em contextos onde os processos já estão bem definidos ou em projetos de atualização de sistemas legados.

Por exemplo, a análise de documentos pode ser usada para extrair requisitos ao migrar um sistema financeiro para uma nova plataforma, garantindo que funcionalidades críticas sejam mantidas.

Prototipagem

A prototipagem envolve a criação de modelos ou representações iniciais do sistema, permitindo aos stakeholders visualizar e validar requisitos de forma tangível. Essa técnica é eficaz em projetos com alto grau de inovação, onde os requisitos podem ser difíceis de expressar de forma abstrata.

Por exemplo, ao projetar uma interface de aplicativo móvel, um protótipo interativo pode ajudar os stakeholders a refinar suas expectativas sobre o layout e a navegabilidade.

Escolha da Técnica

A escolha da técnica de elicitação deve considerar fatores como o tipo de projeto, o perfil dos stakeholders, os recursos disponíveis e o prazo do projeto. Em muitos casos, uma combinação de técnicas é necessária para capturar requisitos de forma abrangente e precisa. Por exemplo, a análise de documentos pode ser usada para iniciar a elicitação, complementada por entrevistas e prototipagem.

Conexão com a Engenharia de Requisitos

As técnicas de elicitação são um elemento central da engenharia de requisitos, fornecendo a base para a especificação, análise e validação de requisitos. Na próxima seção, serão explorados métodos para documentar e priorizar requisitos, garantindo que as informações coletadas sejam transformadas em insumos úteis para o desenvolvimento do sistema.

Escolhendo a Técnica Adequada

A escolha da técnica de elicitação é um dos momentos mais críticos na engenharia de requisitos. Cada projeto apresenta um conjunto único de características que influenciam diretamente a eficácia das técnicas aplicadas. Este processo envolve avaliar o contexto do projeto, as necessidades dos stakeholders e os recursos disponíveis. Esta seção apresenta fatores determinantes para a seleção da técnica mais adequada e discute estratégias para maximizar a eficiência da elicitação.

Fatores Determinantes para a Escolha

A seleção de uma técnica de elicitação deve considerar uma série de fatores interdependentes:

1. Complexidade do Projeto: Projetos com alto nível de complexidade, como sistemas integrados ou aplicações em ambientes regulamentados, geralmente requerem uma combinação de técnicas, como análise de documentos para compreender sistemas existentes e entrevistas com especialistas.
2. Perfil dos Stakeholders: O nível de conhecimento técnico e a disponibilidade dos stakeholders impactam diretamente a escolha. Por exemplo, entrevistas são eficazes quando os stakeholders possuem uma visão clara de suas necessidades, enquanto prototipagem é útil para usuários que precisam de algo visual para expressar suas ideias.
3. Objetivos do Projeto: Projetos orientados a inovações podem demandar técnicas como workshops ou prototipagem, enquanto projetos de manutenção ou atualização de sistemas existentes podem se beneficiar de análise de documentos e observação.
4. Restrição de Recursos: O tempo e o orçamento disponíveis afetam diretamente a escolha. Técnicas como observação e shadowing podem ser mais custosas em termos de tempo, enquanto análise de documentos pode ser mais viável em projetos com recursos limitados.
5. Fase do Projeto: No início, técnicas exploratórias como entrevistas e workshops são mais indicadas, enquanto na fase de validação, prototipagem e testes com usuários desempenham um papel mais relevante.

Estratégias para a Seleção

Não há uma técnica única que se aplique a todos os cenários, e frequentemente uma abordagem combinada é a mais eficaz. Por exemplo:

• Em projetos de sistemas críticos, pode-se iniciar com análise de documentos e entrevistas para criar uma base sólida, complementada por prototipagem para validar os requisitos.
• Projetos ágeis podem se beneficiar de workshops frequentes para revisar e priorizar requisitos em ciclos curtos.

A iteração entre técnicas permite refinar continuamente a compreensão dos requisitos e alinhar expectativas entre stakeholders e a equipe de desenvolvimento.

Conexão com Técnicas de Documentação e Priorização

Após identificar os requisitos, a próxima etapa é documentá-los e priorizá-los de maneira que se tornem insumos claros e acionáveis para o desenvolvimento do sistema. As técnicas de documentação e priorização serão exploradas na próxima seção, estabelecendo uma ponte entre a elicitação e a gestão dos requisitos.

Reflexão e Debate

A engenharia de requisitos desempenha um papel estratégico no sucesso de projetos de software, sendo a base para todas as atividades subsequentes no ciclo de vida do desenvolvimento. Nesta seção, revisamos os conceitos de requisitos funcionais e não funcionais, exploramos diversas técnicas de elicitação e discutimos critérios para escolher a abordagem mais adequada em diferentes contextos. Essas discussões destacaram a importância da flexibilidade e da colaboração contínua entre stakeholders e equipes de desenvolvimento.

A análise apresentada reforça que cada projeto de software é único, exigindo adaptações na aplicação de conceitos e técnicas. Por exemplo, enquanto projetos inovadores podem se beneficiar de prototipagem e workshops, projetos que envolvem sistemas legados demandam uma análise aprofundada de documentos e entrevistas com especialistas. Além disso, o equilíbrio entre requisitos funcionais e não funcionais deve ser cuidadosamente gerenciado, pois ambos impactam diretamente a qualidade e a aceitação do sistema.

Como próximo passo, é essencial promover um debate sobre as escolhas feitas na elicitação e sua relação com os resultados esperados. Questões como "Quais técnicas são mais eficazes em cenários de incerteza?" ou "Como priorizar requisitos conflitantes de diferentes stakeholders?" podem estimular reflexões críticas e debates construtivos, permitindo que os alunos consolidem suas aprendizagens.

Referências para leituras futuras

1. Garcia, V. C. (2023). "Gestão de Requisitos no Desenvolvimento de Software". June 07, 2024.
2. Valente, M. T. (2022. "Engenharia de Software Moderna". Independente (1 janeiro 2022)
3. Pressman, R. S. (2019). I"SE Software Engineering: A Practitioner's Approach". McGraw-Hill Education; 9ª edição (30 setembro 2019)
4. Sommerville, I. (2015). "Software Engineering" (10th ed.). Pearson.
5. Wiegers, K., & Beatty, J. (2013). "Software Requirements" (3rd ed.). Microsoft Press.
6. Pohl, K. (2010). "Requirements Engineering: Fundamentals, Principles, and Techniques". Springer Berlin, Heidelberg.
7. Zowghi, D., Coulin, C. (2005). "Requirements Elicitation: A Survey of Techniques, Approaches, and Tools". In: Aurum, A., Wohlin, C. (eds) Engineering and Managing Software Requirements. Springer, Berlin, Heidelberg.
8. ISO/IEC 25010:2011. "Systems and Software Engineering — Systems and Software Quality Requirements and Evaluation (SQuaRE) — System and Software Quality Models". Withdrawn (Edition 1, 2011).
9. ISO/IEC 25002:2024. "Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality model overview and usage".