Introdução à Engenharia de Requisitos

Introdução

O desenvolvimento de um software não começa pela programação. Antes de decidir quais telas serão construídas, quais tecnologias serão utilizadas ou como o código será organizado, é necessário compreender qual problema precisa ser resolvido, quem é afetado por ele, quais resultados são esperados e quais condições devem ser respeitadas. É nesse espaço, situado entre uma necessidade percebida e uma solução computacional suficientemente definida para ser construída, que atua a Engenharia de Requisitos.

Um sistema pode ser tecnicamente bem implementado e ainda assim ser inadequado ao contexto para o qual foi criado. Isso ocorre quando a solução executa corretamente aquilo que foi programado, mas aquilo que foi programado não corresponde às necessidades reais dos usuários ou aos objetivos que motivaram o projeto. As referências consultadas convergem ao mostrar que requisitos inadequadamente compreendidos, analisados ou documentados comprometem as etapas posteriores do desenvolvimento, porque projeto, implementação, testes e validação dependem do entendimento construído nas fases iniciais.

Nesse contexto, um requisito de software expressa algo que o sistema deverá oferecer, realizar ou respeitar para atender uma necessidade. Pode descrever uma funcionalidade, uma regra do domínio, uma condição de funcionamento, uma restrição tecnológica ou uma característica de qualidade. A Engenharia de Requisitos organiza o trabalho necessário para descobrir essas informações, analisá-las, resolver incompatibilidades, registrá-las de maneira compreensível e verificar, junto aos interessados, se representam adequadamente aquilo que deve ser desenvolvido.

Esse trabalho exige interação entre pessoas que observam o mesmo sistema de perspectivas diferentes. Usuários conhecem sua rotina e os problemas enfrentados; gestores conhecem objetivos, restrições e prioridades organizacionais; especialistas dominam regras específicas da área; profissionais de tecnologia precisam transformar essas informações em especificações suficientemente claras para orientar uma solução. Por isso, Engenharia de Requisitos não é apenas produção de documentação: é também um processo de construção de entendimento compartilhado.

Do problema ao escopo do sistema

A compreensão dos requisitos torna-se mais consistente quando se distingue o que pertence ao problema, ao objetivo, ao escopo e à própria especificação dos requisitos. Esses elementos estão relacionados, mas não são equivalentes. Confundi-los pode levar uma equipe a discutir funcionalidades antes de compreender por que o sistema está sendo desenvolvido.

O problema descreve uma situação existente que produz alguma dificuldade, limitação ou necessidade. Em uma biblioteca, por exemplo, pode haver demora para localizar exemplares disponíveis ou dificuldade para acompanhar reservas realizadas pelos usuários. O problema ainda não determina qual tecnologia será usada nem qual interface deverá existir; ele estabelece a situação que justifica uma intervenção.

O objetivo indica o resultado que se pretende alcançar em relação ao problema. Se a dificuldade está na consulta e reserva do acervo, um objetivo possível é permitir que usuários obtenham informação atualizada sobre disponibilidade e realizem reservas por meio do sistema. O objetivo dá direção ao projeto e fornece um critério para avaliar se as funcionalidades propostas contribuem efetivamente para a finalidade esperada.

O escopo estabelece os limites da solução. Ao definir a fronteira do sistema, a equipe identifica o que fará parte de sua responsabilidade e o que permanecerá fora dela. Um sistema de biblioteca pode abranger cadastro do acervo, consulta, empréstimo, devolução e reserva, enquanto processos de aquisição de novos livros e atividades contábeis podem permanecer fora do escopo. Essa delimitação evita que toda necessidade relacionada ao ambiente organizacional seja automaticamente tratada como uma obrigação do sistema em desenvolvimento.

Os requisitos tornam esses limites mais concretos. Eles descrevem serviços, comportamentos, condições e restrições que deverão ser satisfeitos dentro do escopo acordado. Assim, a relação entre os quatro elementos pode ser compreendida como uma passagem progressiva de uma situação mais ampla para uma especificação mais precisa da solução.

Stakeholders, atores e fronteira

A identificação dos envolvidos é parte essencial dessa delimitação. O termo stakeholder designa pessoas ou grupos que são afetados pelo sistema ou possuem interesse em seus resultados. Usuários finais, gestores, especialistas do domínio, áreas responsáveis por processos relacionados e equipes que dependem das informações produzidas podem ser stakeholders, ainda que nem todos utilizem diretamente o software.

Um ator, por sua vez, desempenha um papel que interage com o sistema. Esse ator pode ser uma pessoa, uma organização, outro sistema ou, em determinados contextos, um equipamento. A distinção é relevante porque alguém pode influenciar ou ser afetado pelo projeto sem realizar uma interação operacional com a solução. Um gestor responsável por aprovar regras pode ser stakeholder mesmo que não utilize as funcionalidades diariamente.

A análise da fronteira ajuda a relacionar esses participantes ao escopo. Quando uma atividade está fora da responsabilidade do sistema, os processos, atores e informações associados a ela não devem ser incorporados automaticamente como requisitos funcionais. Caso essa fronteira seja modificada posteriormente, novos requisitos podem surgir e outros participantes podem passar a fazer parte das interações previstas.

Requisitos de software e necessidades dos usuários

As referências utilizadas apresentam requisito como uma descrição relacionada aos serviços oferecidos pelo software, às ações que ele deverá executar e às condições ou restrições necessárias para atender uma necessidade. Em termos didáticos, pode-se compreender um requisito como uma declaração verificável sobre uma capacidade, comportamento, regra ou condição que deverá ser satisfeita pelo sistema.

Essa definição amplia a ideia de que requisito é apenas uma lista de funções. Embora funcionalidades sejam uma parte central da especificação, um sistema também precisa operar dentro de condições determinadas. Segurança, disponibilidade, compatibilidade, desempenho, regras organizacionais, padrões do domínio e limitações de infraestrutura podem ser tão importantes quanto cadastrar, consultar ou emitir informações.

O requisito funciona, portanto, como uma ligação entre a necessidade percebida e a solução a ser construída. Essa ligação precisa preservar o significado da necessidade sem antecipar detalhes técnicos desnecessários. Se uma declaração destinada a representar o que o usuário precisa já está excessivamente condicionada à arquitetura interna, a equipe pode misturar duas discussões distintas: o que precisa ser atendido e como tecnicamente isso será implementado.

Requisitos funcionais, não funcionais e de domínio

Uma classificação recorrente nas obras consultadas distingue requisitos funcionais, não funcionais e de domínio. Essa classificação auxilia a análise porque permite observar o sistema sob diferentes perspectivas sem reduzir todos os requisitos ao mesmo tipo de informação.

Os requisitos funcionais respondem principalmente à pergunta “o que o sistema deve fazer?”. Em um sistema de biblioteca, consultar o acervo, registrar empréstimos, devolver exemplares e realizar reservas são exemplos de funções. Essas funções podem ser documentadas de formas diferentes conforme a abordagem adotada pelo projeto, como descrições de casos de uso ou histórias de usuário.

Os requisitos não funcionais descrevem condições que não correspondem diretamente a uma função isolada, mas interferem na qualidade e na operação do produto. Podem envolver disponibilidade, segurança, compatibilidade, capacidade, desempenho ou conformidade com determinados padrões. Uma funcionalidade pode estar corretamente implementada e ainda assim ser inadequada se o sistema não satisfizer as condições não funcionais relevantes ao contexto.

Já os requisitos de domínio derivam do campo de aplicação. Um sistema de saúde, uma biblioteca, uma instituição financeira ou um ambiente industrial possui terminologia, regras e padrões específicos. Esses elementos podem originar requisitos funcionais ou restrições, e sua compreensão costuma exigir a participação de pessoas que conheçam efetivamente o domínio.

A classificação é útil para organizar a análise, mas não elimina a necessidade de observar as relações existentes entre os requisitos. Uma regra de domínio pode determinar o comportamento de várias funcionalidades; uma exigência de segurança pode afetar diferentes módulos; uma restrição de infraestrutura pode influenciar as alternativas de projeto. Requisitos devem ser compreendidos como partes relacionadas de uma mesma solução, e não como itens independentes de uma lista.

O processo de Engenharia de Requisitos

A Engenharia de Requisitos organiza um conjunto de atividades voltadas à criação, análise e manutenção das informações que descrevem aquilo que o software precisa atender. As referências consultadas apresentam pequenas diferenças na divisão e na nomenclatura das etapas. Em uma delas, aparecem obtenção, análise e negociação, especificação, modelagem e validação; em outra, o processo é apresentado de maneira mais sintética como elicitação, análise, especificação e validação. Há também abordagens que destacam explicitamente o estudo de viabilidade.

Essas diferenças não representam processos incompatíveis. Elas evidenciam formas distintas de agrupar atividades que possuem uma lógica comum: primeiro é necessário compreender o contexto e coletar informações; depois essas informações precisam ser avaliadas e conciliadas; em seguida, devem ser registradas de forma adequada; por fim, é necessário confirmar se a especificação representa corretamente aquilo que os envolvidos esperam do sistema.

Essa representação não deve ser interpretada como uma sequência rígida na qual uma etapa nunca é retomada. Durante a análise pode surgir a necessidade de conversar novamente com um usuário; a especificação pode revelar uma informação ausente; a validação pode identificar uma interpretação incorreta ou uma nova restrição. A interação entre as atividades faz parte da própria natureza da Engenharia de Requisitos.

Elicitação: transformar contexto em informação analisável

A elicitação, também chamada de levantamento ou obtenção de requisitos em diferentes referências, procura reunir informações necessárias para compreender o domínio do problema e aquilo que se espera do sistema. Ela envolve descobrir quais dificuldades motivam o projeto, quem participa do contexto, quais objetivos precisam ser atendidos, o que estará dentro da fronteira do sistema e quais restrições limitam a solução.

Não se trata simplesmente de perguntar ao cliente “o que você quer que o sistema faça?”. Usuários podem dominar sua atividade cotidiana, mas não necessariamente conhecer todas as possibilidades de automação ou conseguir explicar cada detalhe do processo. Algumas tarefas são tão habituais que determinadas regras deixam de ser mencionadas por parecerem óbvias para quem as executa. Outras necessidades podem ser percebidas de maneira diferente por setores distintos da organização.

A elicitação precisa, por isso, recorrer a diferentes fontes. Pessoas são uma fonte importante, mas documentos existentes, sistemas legados, formulários, dados, recursos disponíveis, ambiente físico e condições de segurança também podem revelar requisitos que não aparecem espontaneamente em uma entrevista.

Análise e negociação: compreender relações e resolver conflitos

Depois que as informações são obtidas, elas precisam ser analisadas. A equipe procura compreender se cada requisito contribui para os objetivos do sistema, se existem dependências, sobreposições, incompatibilidades ou restrições que inviabilizam determinada interpretação. É também nessa etapa que informações inicialmente vagas podem ser refinadas e que necessidades provenientes de diferentes stakeholders precisam ser conciliadas.

Dois setores podem solicitar comportamentos incompatíveis; uma funcionalidade desejada pode ultrapassar o escopo estabelecido; uma regra pode depender de outra que ainda não foi definida. A análise não elimina essas diferenças simplesmente escolhendo uma das versões. Seu papel é torná-las visíveis e criar condições para uma negociação informada entre os participantes responsáveis pelas decisões.

Especificação: registrar o entendimento construído

Especificar requisitos significa transformar o entendimento obtido e analisado em uma representação que possa ser consultada, discutida, revisada e utilizada nas etapas posteriores. Essa representação pode assumir diferentes formas. Dependendo do processo de desenvolvimento, podem ser utilizados documentos de visão, descrições em linguagem natural, casos de uso, histórias de usuário, modelos ou combinações desses artefatos.

O valor da documentação não depende de produzir grande quantidade de texto. A documentação é útil quando preserva decisões importantes, reduz interpretações divergentes e permite relacionar aquilo que será construído às necessidades que originaram o projeto. Uma especificação extensa, porém ambígua, pode ser menos útil do que uma representação menor, clara e suficientemente detalhada.

Validação: confirmar que se pretende construir o produto correto

A validação confronta a especificação com as necessidades e expectativas dos stakeholders. O objetivo é verificar se o entendimento registrado corresponde ao que deve ser atendido. Documentos, modelos, casos de uso, histórias de usuário e protótipos podem ser apresentados aos participantes para confirmação, correção ou refinamento.

Esse momento é especialmente importante porque transforma uma interpretação produzida pela equipe em um entendimento compartilhado. Quanto mais cedo uma inconsistência for identificada, menor a chance de que ela se propague para modelos, código, testes e demais artefatos construídos a partir daquele requisito.

Elicitação e comunicação entre os envolvidos

Um dos aspectos mais desafiadores da Engenharia de Requisitos é a comunicação entre pessoas que utilizam linguagens e referências distintas. O profissional de uma área de negócio descreve situações a partir de processos, regras e problemas que fazem parte de sua experiência. A equipe técnica precisa compreender essas informações e transformá-las em uma representação que possa orientar o desenvolvimento sem descaracterizar a necessidade original.

Gonçalves e Cortés descrevem a análise como uma aproximação entre a linguagem do cliente e uma representação que possa apoiar o desenvolvimento. Essa passagem não é uma tradução mecânica. O analista precisa compreender o significado das informações, identificar lacunas e confirmar interpretações antes que decisões técnicas sejam tomadas.

A entrevista é uma das técnicas mais conhecidas porque permite conversar diretamente com stakeholders sobre necessidades, expectativas, fatos e características do contexto. Entrevistas podem seguir questões previamente planejadas ou assumir formato mais aberto, no qual os assuntos são aprofundados conforme a conversa avança. Entretanto, nenhuma técnica isolada é adequada a todos os contextos.

As obras consultadas apresentam diferentes técnicas que podem ser combinadas conforme o tipo de sistema, a disponibilidade dos participantes e o conhecimento existente sobre o domínio:

• entrevistas, para obter explicações, necessidades, expectativas e percepções diretamente dos envolvidos;
• observação, para compreender atividades realizadas no ambiente real e identificar informações que podem não aparecer no relato verbal;
• demonstração de tarefas, quando é necessário acompanhar detalhadamente como uma atividade específica é executada;
• análise de documentos, útil para reconhecer dados, regras, formulários, relatórios e procedimentos já utilizados;
• questionários, que permitem obter ou complementar informações de diferentes participantes;
• brainstorming, empregado para reunir perspectivas e organizar ideias provenientes de diferentes perfis;
• prototipação, que torna aspectos da solução visíveis e facilita a confirmação de como uma necessidade foi compreendida;
• workshops ou oficinas de requisitos, que reúnem diferentes envolvidos para discutir, alinhar e consolidar informações em sessões focadas.

A escolha dessas técnicas depende da natureza da informação que precisa ser descoberta. Uma entrevista pode revelar a justificativa de uma regra, enquanto a observação pode mostrar exceções que o usuário não mencionou por considerá-las parte natural de sua rotina. Documentos existentes ajudam a identificar dados utilizados no processo, e um protótipo pode tornar concreta uma interpretação que ainda está difícil de explicar apenas por palavras.

A comunicação também precisa considerar a multiplicidade de stakeholders. Nem todos possuem os mesmos objetivos. Uma área pode valorizar rapidez de operação, outra pode enfatizar controle, auditoria ou segurança. O trabalho de requisitos precisa tornar essas perspectivas comparáveis e explícitas para que conflitos possam ser analisados antes de serem incorporados silenciosamente ao produto.

Qualidade, verificação e validação dos requisitos

Um requisito não se torna adequado apenas porque foi escrito. Sua redação precisa permitir que diferentes envolvidos compreendam de maneira suficientemente semelhante aquilo que deverá ser atendido. Quando a especificação contém termos vagos, informações omitidas ou declarações contraditórias, o problema tende a se propagar para as etapas posteriores.

Gonçalves e Cortés destacam a necessidade de requisitos precisos e chamam atenção para três propriedades especialmente importantes: ausência de ambiguidade, completeza e consistência. Calazans acrescenta, no contexto da verificação, a importância da clareza e da possibilidade de revisar os documentos para localizar defeitos antes que eles avancem no processo.

Ambiguidade e vagueza

Um requisito é ambíguo quando admite interpretações diferentes. A frase “o sistema deverá apresentar rapidamente os resultados”, por exemplo, não estabelece o que significa “rapidamente”. Para uma pessoa, cinco segundos podem ser aceitáveis; para outra, a mesma demora pode representar falha. A ambiguidade faz com que diferentes integrantes da equipe construam soluções distintas acreditando que estão atendendo ao mesmo requisito.

Sempre que possível, termos subjetivos devem ser substituídos por condições que possam ser compreendidas e verificadas. Em vez de declarar apenas que uma operação deve ser rápida, a especificação pode estabelecer uma condição mensurável para o contexto de uso. O nível de precisão necessário depende do requisito, mas a redação deve fornecer informação suficiente para que se possa avaliar posteriormente se ele foi satisfeito.

Incompletude

Um requisito incompleto deixa de registrar informação necessária para compreender ou implementar corretamente uma necessidade. Declarar que “o sistema deverá registrar empréstimos” pode ser insuficiente se não estiver definido, em algum ponto da especificação, quem pode realizar essa operação, quais condições permitem o empréstimo, quais dados precisam ser registrados ou quais restrições do domínio se aplicam.

A incompletude não significa que todo requisito precise conter sozinho todos os detalhes do sistema. Requisitos se relacionam e podem ser complementados por regras, modelos e outros artefatos. O problema ocorre quando uma informação necessária não está definida em nenhum lugar ou não pode ser recuperada pela relação entre os artefatos.

Inconsistência e contradição

A consistência exige que os requisitos não imponham condições incompatíveis entre si. Uma especificação seria contraditória, por exemplo, se em um ponto afirmasse que nenhuma conta pode existir antes do primeiro acesso e, em outro, determinasse que o acesso inicial depende de uma conta administrativa previamente cadastrada. As duas declarações não podem ser satisfeitas simultaneamente sem algum esclarecimento adicional.

Contradições podem surgir porque requisitos são obtidos de pessoas diferentes, em momentos diferentes ou sob pressupostos distintos. A análise e a negociação são necessárias justamente para identificar esses conflitos e produzir uma decisão comum antes da implementação.

Verificabilidade e testabilidade

Um requisito deve fornecer condições que permitam avaliar se foi atendido. Essa propriedade conecta a Engenharia de Requisitos aos testes e à aceitação do sistema. Se não existe maneira objetiva de observar ou verificar a condição descrita, torna-se difícil afirmar se o produto está ou não de acordo com a especificação.

A testabilidade também ajuda a melhorar a própria redação. Quando a equipe tenta imaginar como demonstrará que determinado requisito foi satisfeito, termos vagos e condições ausentes tornam-se mais visíveis. Assim, pensar na futura verificação não é uma tarefa exclusiva da etapa de testes: pode contribuir para a qualidade da especificação desde o início.

Verificação e validação

Embora os termos sejam próximos, verificação e validação focalizam aspectos diferentes. A verificação examina os artefatos produzidos e procura identificar defeitos de forma, clareza, completeza, consistência ou organização. Revisões e inspeções são mecanismos utilizados para localizar problemas antes que avancem para etapas seguintes.

A validação concentra-se na correspondência entre a especificação e as necessidades dos stakeholders. Em termos conceituais, a verificação procura saber se os requisitos estão sendo descritos de maneira adequada, enquanto a validação procura confirmar se aquilo que foi descrito representa o produto que realmente deve ser construído.

Essa distinção mostra por que um documento pode estar formalmente bem escrito e ainda representar uma solução inadequada. A especificação pode ser clara, consistente e organizada, mas estar baseada em uma necessidade mal compreendida. Da mesma forma, a equipe pode compreender corretamente o objetivo do usuário e registrá-lo de maneira vaga ou contraditória. Qualidade de requisitos depende das duas dimensões.

Requisitos no desenvolvimento e na evolução do software

A Engenharia de Requisitos não deve ser tratada como uma etapa isolada cujo resultado deixa de ter utilidade depois que a programação começa. Os requisitos fornecem uma referência para diversos artefatos produzidos ao longo do desenvolvimento. Modelos de análise, decisões de projeto, funcionalidades implementadas, casos de teste e procedimentos de validação dependem, direta ou indiretamente, daquilo que foi estabelecido durante o trabalho de requisitos.

Gonçalves e Cortés destacam essa relação ao apresentar os requisitos como ponto de partida para especificações de casos de uso, diagramas, código, testes e validação. Essa continuidade permite estabelecer rastreabilidade, isto é, relacionar artefatos que representam diferentes níveis ou etapas de desenvolvimento. A rastreabilidade torna possível identificar de onde uma funcionalidade surgiu e quais elementos podem ser afetados quando determinado requisito muda.

Essa relação é particularmente importante porque requisitos não são necessariamente permanentes. Freitas chama atenção para a volatilidade como uma das dificuldades do levantamento: necessidades podem mudar durante o projeto. Mudanças no ambiente organizacional, no entendimento do problema ou nas prioridades dos envolvidos podem alterar o que se espera do sistema.

A existência de mudanças não elimina a necessidade de documentação. Pelo contrário, torna ainda mais importante saber qual requisito está sendo modificado, por que a mudança ocorreu e quais partes da solução dependem dele. Sem essa relação, uma alteração aparentemente pequena pode gerar inconsistências entre funcionalidades, modelos, testes e expectativas dos usuários.

O formato dos artefatos pode variar conforme o processo adotado. Em abordagens orientadas a objetos, casos de uso e modelos podem ser utilizados para representar funcionalidades e interações. Em métodos ágeis, histórias de usuário e critérios de aceite são formas comuns de registrar necessidades. A diferença de formato não elimina a necessidade de compreender problema, escopo, stakeholders, restrições e condições de aceitação.

Essa continuidade também reforça a relação entre requisitos e testes. Quando um requisito é suficientemente claro e verificável, torna-se possível derivar condições que indiquem se o comportamento implementado corresponde ao esperado. Quando o requisito é vago, a equipe de testes precisa interpretar o que deveria ter sido estabelecido anteriormente, e essa interpretação pode divergir daquela utilizada pelos desenvolvedores.

A Engenharia de Requisitos, portanto, não produz apenas uma descrição inicial do sistema. Ela cria uma base de entendimento que acompanha o produto durante análise, projeto, desenvolvimento, testes, validação e evolução. A qualidade dessa base influencia a capacidade da equipe de manter coerência entre aquilo que foi solicitado, aquilo que foi construído e aquilo que será posteriormente modificado.

Síntese

A Engenharia de Requisitos estabelece a ligação entre necessidades humanas e organizacionais e a definição de uma solução de software. Antes que uma funcionalidade possa ser projetada ou programada, é necessário compreender o problema que motivou o sistema, os objetivos que se pretende alcançar, os participantes envolvidos, as restrições existentes e a fronteira que delimita o escopo.

Os requisitos registram serviços, comportamentos, regras e condições que o sistema deverá satisfazer. Requisitos funcionais descrevem aquilo que o software deverá fazer; requisitos não funcionais estabelecem características e condições de operação; requisitos de domínio representam regras e conhecimentos específicos da área em que o sistema será utilizado. Essas categorias se complementam e precisam ser analisadas em conjunto.

O processo de Engenharia de Requisitos pode ser organizado de maneiras diferentes, mas envolve uma lógica recorrente de elicitação, análise e negociação, especificação e validação. A elicitação busca informações em pessoas, processos, documentos e outros elementos do contexto. A análise procura relacionar e refinar essas informações, identificando incompatibilidades. A especificação registra o entendimento obtido, e a validação confirma se esse entendimento corresponde às necessidades dos stakeholders.

A qualidade da especificação depende de clareza, completeza, consistência e possibilidade de verificação. Requisitos vagos geram interpretações diferentes; requisitos incompletos deixam necessidades sem definição; requisitos contraditórios impõem condições incompatíveis; requisitos que não podem ser verificados dificultam testes e aceitação. Por isso, revisões, inspeções e validação com os envolvidos são partes essenciais do trabalho.

Finalmente, os requisitos permanecem ligados às demais etapas do desenvolvimento. Eles orientam modelos, implementação, testes, aceitação e mudanças posteriores. Quando essa relação é preservada, a equipe consegue compreender melhor o impacto de alterações e manter coerência entre a necessidade que originou o projeto e o software que efetivamente será entregue.

Referências

• CALAZANS, Angélica Toffano Sedel. Análise e Projeto de Sistemas. Brasília: Instituto Federal de Brasília, [s.d.]. Material didático do Curso Técnico em Informática.
• FREITAS, Romualdo Rubens de. Análise e Projeto de Software. Cuiabá, MT, 2015. Material didático da Rede e-Tec Brasil.
• GONÇALVES, Enyo José Tavares; CORTÉS, Mariela Inés. Análise e Projeto de Sistemas. 3. ed. Fortaleza: EdUECE, 2015.