Engenharia de Requisitos

Requisitos Funcionais

São ações ou funcionalidades que o sistema deve fornecer para atingir seus objetivos. Grosso modo, tratam do "o que o sistema deve fazer", descrevendo serviços, comportamentos e respostas a determinadas situações.

Em alguns casos, os requisitos funcionais também podem especificar o que o sistema não deve fazer, especialmente para garantir regras de negócio, segurança ou integridade dos dados.

Exemplo (do que o sistema deve fazer):
O sistema deverá fornecer a opção de filtrar os resultados por data.

Exemplo (do que o sistema não deve fazer):
O sistema não deve permitir que usuários não autenticados acessem dados confidenciais.

Requisitos Não-Funcionais

São restrições ou condições estipuladas sobre as quais o sistema deve funcionar.
Não estão diretamente relacionados às funções específicas do sistema, mas às gerais – e podem incluir restrições de tempo, restrições de processo de desenvolvimento, restrições impostas por padrões, entre outras. Podem ser mais críticos que os funcionais e sempre devem ser verificáveis. Eles fazem parte da arquitetura técnica de um sistema.

Exemplo: Sistema deverá fornecer disponibilidade mínima de 99,8%.

Requisitos de Domínio

São requisitos derivados do domínio da aplicação e refletem características de sua área de negócio.

Podem ser requisitos funcionais ou não-funcionais.

Exemplo: O sistema deve seguir as normas do CNJ para tramitação processual.

Resumo

Tipo de Requisito	Foco Principal	Exemplo no TJPA
Funcional	O que o sistema deve fazer (ações, respostas)	“Cadastrar processo”
Não Funcional	Como o sistema deve ser (desempenho, segurança)	“Resposta em até 2s”
De Domínio	Regras específicas da área ou negócio	“Seguir atualizações legais do Judiciário”

::: tip

• Um requisito funcional pode resultar na identificação de múltiplos requisitos não funcionais.
• Requisitos não funcionais podem influenciar e gerar requisitos funcionais.

Exemplo: Um requisito não funcional de segurança pode demandar a implementação de um requisito funcional de autenticação de dois fatores.
:::

---

Engenharia de Requisitos

Sommerville afirma que o objetivo da engenharia de requisitos é criar e manter um documento de requisitos de sistema.

Todos os artefatos produzidos nas fases da engenharia de requisitos servem como base para criar o Documento de Requisitos. O processo não é linear — é iterativo: se algo estiver incorreto durante a validação, é possível voltar e ajustar na fase de especificação.

Estudo de Viabilidade

O Estudo de Viabilidade analisa se vale a pena desenvolver o sistema, antes de começar o projeto.

🔎 Avalia 3 pontos principais:

1. ✅ Viabilidade Técnica
   Verifica se é possível construir o sistema com a tecnologia e equipe disponíveis.

2. 💰 Viabilidade Econômica
   Analisa custos e benefícios — o sistema será rentável ou viável financeiramente?

3. 🏛️ Viabilidade Operacional
   Vê se o sistema será aceito e usado corretamente na organização.

Objetivo: Evitar desperdício de tempo e dinheiro com projetos inviáveis.

Elicitação e Análise de Requisitos

Elicitar: descobrir, identificar, deduzir, extrair, evocar, obter informações sobre uma questão específica.

A fase de Elicitação e Análise de Requisitos trata do processo de levantamento e derivação de requisitos de sistema através da observação de sistemas existentes, discussões com usuários e compradores potenciais, análise de tarefas, entre outros. Isso pode envolver o desenvolvimento de um ou mais modelos de sistema e protótipos, que ajudam o analista a compreender o sistema a ser especificado.

Técnicas de Elicitação de Requisitos

1. 🗣️ Entrevistas
   Conversas com stakeholders para entender necessidades.

2. 👥 Workshops / Reuniões de grupo Reuniões longas Discussões em grupo para levantar ideias e alinhar expectativas.

3. ✏️ Questionários
   Formulários com perguntas para coletar requisitos de várias pessoas.

4. 📋 Observação direta
   Análise do ambiente de trabalho para entender como os usuários agem.

5. 🧠 Brainstorming Aqui é bem rápido Geração rápida de ideias em grupo sobre o que o sistema deve fazer.

6. 👤 Técnica da Persona ou Papéis (mudança de perspectiva)
   Assumir diferentes papéis de usuários para descobrir necessidades específicas.

7. 🧪 Protótipos
   Criação de modelos simples do sistema para validar ideias com os usuários.

8. 📚 Análise de documentos
   Estudo de manuais, legislações e processos já existentes.

cuidado

Existem outras técnicas como:

• Histórias de Usuário (Storytelling): Baseiam-se no modelo 3C, que organiza os requisitos em Cartões (descrição), Conversas (detalhamento) e Confirmações (critérios de aceitação).
• Etnografia (Observação prolongada do ambiente de trabalho real dos usuários).
• Identificação de requisitos com base em sistemas já usados.
• Sondagens exploratórias (Permitem descobrir necessidades que os usuários nem sabiam que tinham).

---

Especificação de Requisitos

É a fase em que as informações coletadas na elicitação e análise são formalmente documentadas em um Documento de Requisitos, que servirá como contrato entre cliente e desenvolvedor.

Inclui atividades como elaboração de requisitos para o detalhamento, modelagem (por exemplo, casos de uso, diagramas UML), identificação de requisitos conflitantes, análise de viabilidade e organização geral dos requisitos para que se tornem prontos para a formalização.

Objetivos da Especificação:

• Formalizar os requisitos de forma clara e compreensível para todas as partes envolvidas.
• Servir como base de consulta e validação durante o desenvolvimento do sistema.

📄 O que o documento contém:

• Requisitos de usuário: linguagem natural, tabelas, diagramas, imagens.
• Requisitos de sistema: linguagem mais técnica, como modelos formais, casos de uso.

Por que "idealmente"?
Porque na prática é difícil atingir todos esses critérios 100%, mas eles são metas a serem buscadas para garantir qualidade na especificação.

Validação de Requisitos

É a fase em que se verifica se os requisitos estão corretos, completos, consistentes e se atendem ao que o usuário realmente deseja.

Objetivo Principal:

Garantir que os requisitos estejam alinhados com as necessidades do cliente, evitando erros caros no futuro.

🔍 O que se avalia:

• Validade: é realmente necessário?

• Consistência: há contradições?

• Completude: nada foi deixado de fora?

• Realismo: pode ser implementado?

• Clareza: é fácil de entender?

• Erros nos requisitos são caros para corrigir depois.

• Pode exigir revisar projeto, código e testes.

• Deve envolver o cliente ativamente.

É difícil prever o sistema em funcionamento só lendo o documento, por isso a participação do usuário é essencial.

Técnicas de Validação de Requisitos

1. 📝 Revisão de Requisitos
   Revisão manual do documento de requisitos por usuários, analistas e desenvolvedores para identificar erros, ambiguidades ou inconsistências.
   🔍 Ex: reuniões de inspeção, walkthroughs.

O walkthrough é uma técnica de validação de requisitos que envolve a apresentação sistemática dos requisitos aos stakeholders, promovendo discussões detalhadas e buscando identificar problemas como inconsistências, ambiguidades e omissões.

2. 🧪 Prototipação
   Criação de uma versão simplificada ou visual do sistema para que o usuário avalie e valide os requisitos com base em algo mais concreto.
   🎯 Ajuda o usuário a "ver" o sistema antes que ele exista.

3. 📋 Geração de Casos de Teste
   Criação antecipada de testes baseados nos requisitos para verificar se eles são claros, testáveis e completos.
   💡 Se não dá pra testar, o requisito provavelmente está mal definido.

Gerenciamento de Requisitos

É o processo responsável por compreender, acompanhar e controlar as mudanças dos requisitos de sistema, identificando inconsistências.

Gerenciamento de Requisitos e Rastreabilidade

• O gerenciamento de requisitos começa assim que a primeira versão do documento de requisitos é criada.
• Deve-se acompanhar os requisitos individualmente e suas ligações com outros requisitos ou partes do sistema.
• Isso permite avaliar o impacto de mudanças (🌐 rastreabilidade).

Mudanças são inevitáveis

• A evolução dos requisitos ocorre durante o projeto e até após a entrega do sistema.
• Por isso, é importante planejar a gestão de mudanças desde a elicitação.

Rastreabilidade

• É a capacidade de rastrear a origem e o impacto de cada requisito.
• Normalmente representada por matrizes de rastreabilidade, ligando:
  • Requisitos ↔ Stakeholders
  • Requisitos ↔ Outros Requisitos
  • Requisitos ↔ Componentes do sistema
  • Requisitos ↔ Justificativas (motivos para sua existência)