❧ Engenharia de Requisitos ❧

Introdução5.1

A Engenharia de Requisitos ocupa uma posição central no desenvolvimento de software porque define, com clareza progressiva, o que o sistema deve fazer, quais restrições deve respeitar e como essas expectativas serão comunicadas entre clientes, usuários, analistas, arquitetos e desenvolvedores. Em projetos reais, muitos dos problemas que aparecem no código, nos testes e até na implantação têm origem muito antes da implementação: surgem de requisitos ambíguos, incompletos, contraditórios ou mal compreendidos.

Quando falamos em requisitos, não estamos tratando apenas de uma lista de funcionalidades. Estamos tratando de necessidades de negócio, expectativas dos usuários, regras organizacionais, limitações técnicas, exigências legais e critérios de qualidade que moldam o sistema como um todo. Por isso, a Engenharia de Requisitos não é uma etapa burocrática; ela é o processo de transformar um problema difuso do mundo real em uma descrição de software que possa ser analisada, projetada, implementada, validada e mantida.

Segundo Sommerville, os requisitos de um sistema são descrições dos serviços que o sistema deve fornecer e das restrições sob as quais ele deve operar. O processo de descobrir, analisar, documentar, validar e gerenciar essas descrições é justamente o que chamamos de Engenharia de Requisitos.

É importante perceber que o termo "requisito" é usado em níveis diferentes de abstração. Às vezes, ele aparece como uma necessidade de negócio expressa de forma ampla; em outros casos, como uma especificação detalhada de comportamento. Essa distinção precisa ser bem compreendida para evitar confusão entre aquilo que o cliente quer e aquilo que a equipe técnica precisa implementar.

Requisitos de Usuário e Requisitos de Sistema5.2

Uma distinção fundamental apresentada por Sommerville é a separação entre requisitos de usuário e requisitos de sistema.

1. Requisitos de usuário são descrições em alto nível, normalmente em linguagem natural e com apoio de diagramas simples, escritas para clientes, gestores e usuários finais.
2. Requisitos de sistema são descrições mais detalhadas e técnicas da funcionalidade, das restrições e do comportamento do software, usadas principalmente pela equipe de desenvolvimento.

Essa distinção existe porque públicos diferentes precisam de níveis diferentes de detalhe. O usuário final quer entender o que o sistema fará em termos de negócio. Já arquitetos, programadores e testadores precisam de precisão suficiente para construir e validar o sistema corretamente.

O ponto mais importante aqui, e que costuma aparecer bastante em prova, é este: requisitos de sistema são mais detalhados e mais técnicos que requisitos de usuário, mas ainda não devem definir a tecnologia da solução. Em outras palavras, requisito de sistema ainda não é escolha de linguagem, framework, banco de dados ou arquitetura de implantação. Ele detalha comportamento, entradas, saídas, restrições e regras do sistema. A decisão de implementar isso com Java, Python, SAP, PostgreSQL ou microsserviços pertence ao projeto e à implementação, não à definição do requisito em si.

flowchart TD
    A[Problema do negocio] --> B[Requisitos de usuario]
    B --> C[Requisitos de sistema]
    C --> D[Projeto e implementacao]

flowchart TD
    A[Problema do negocio] --> B[Requisitos de usuario]
    B --> C[Requisitos de sistema]
    C --> D[Projeto e implementacao]

Considere o exemplo abaixo:

Requisito de usuário:
O sistema deve gerar relatórios mensais com o custo dos medicamentos prescritos por cada clínica.

Possíveis requisitos de sistema derivados:

1. O sistema deve consolidar prescrições por clínica no último dia útil do mês.
2. O relatório deve listar medicamento, quantidade prescrita e custo total.
3. O acesso ao relatório deve ser restrito a usuários autorizados.

O requisito de usuário comunica a necessidade geral. Os requisitos de sistema detalham como essa necessidade será tratada pelo software.

Exemplos rápidos5.2.1

Requisitos Funcionais e Não Funcionais5.3

Os requisitos de software são frequentemente classificados em dois grandes grupos: funcionais e não funcionais.

Requisitos Funcionais5.3.1

Os requisitos funcionais descrevem os serviços que o sistema deve fornecer, como deve reagir a entradas específicas e como deve se comportar em determinadas situações. Em termos simples, eles dizem o que o sistema faz.

Exemplos de requisitos funcionais para um sistema como o MHC-PMS:

1. O usuário deve ser capaz de pesquisar a lista de agendamentos de todas as clínicas.
2. O sistema deve gerar diariamente a lista de pacientes com consultas marcadas.
3. O sistema deve permitir registrar prescrições médicas no prontuário do paciente.

Outros exemplos rápidos:

1. O sistema deve permitir cadastrar disciplinas.
2. O sistema deve emitir histórico escolar em PDF.
3. O sistema deve permitir ao professor lançar notas por avaliação.
4. O sistema deve recalcular automaticamente a média final do aluno após alteração de nota.

O principal problema com requisitos funcionais mal escritos é a ambiguidade. Se um requisito diz "pesquisar agendamentos", isso significa pesquisar em uma clínica específica, em todas as clínicas, por nome, por data, por médico ou por combinação desses filtros? Se o requisito não for claro, a implementação pode ficar tecnicamente correta e, ainda assim, funcionalmente errada para o cliente.

Requisitos Não Funcionais5.3.2

Os requisitos não funcionais descrevem restrições ou qualidades do sistema. Em vez de dizerem o que o sistema faz, eles dizem como o sistema deve se comportar ou sob quais condições deve operar.

Eles podem surgir de:

1. Requisitos de produto: desempenho, confiabilidade, segurança, usabilidade.
2. Requisitos organizacionais: padrões, processos, tecnologias adotadas pela organização.
3. Requisitos externos: leis, regulações, normas éticas e de proteção de dados.

flowchart TD
    RNF[Requisitos nao funcionais] --> P[Produto]
    RNF --> O[Organizacionais]
    RNF --> E[Externos]
    P --> P1[Desempenho]
    P --> P2[Confiabilidade]
    P --> P3[Usabilidade]
    O --> O1[Padroes internos]
    O --> O2[Tecnologias adotadas]
    E --> E1[Leis]
    E --> E2[Regulacoes]
    E --> E3[Etica]

flowchart TD
    RNF[Requisitos nao funcionais] --> P[Produto]
    RNF --> O[Organizacionais]
    RNF --> E[Externos]
    P --> P1[Desempenho]
    P --> P2[Confiabilidade]
    P --> P3[Usabilidade]
    O --> O1[Padroes internos]
    O --> O2[Tecnologias adotadas]
    E --> E1[Leis]
    E --> E2[Regulacoes]
    E --> E3[Etica]

Exemplos:

1. O sistema deve estar disponível das 8h30 às 17h30 nos dias úteis.
2. O sistema deve responder a consultas em até 2 segundos.
3. O acesso aos prontuários deve ser restrito a profissionais autorizados.
4. O sistema deve estar em conformidade com a legislação de privacidade de dados.

Outros exemplos:

1. O sistema deve suportar 500 acessos simultâneos sem degradação significativa.
2. O sistema deve registrar logs de auditoria por 5 anos.
3. O sistema deve estar disponível em pelo menos 99,5% do período letivo.
4. O tempo de treinamento para uso das funções principais não deve ultrapassar 4 horas.

Exemplos por tipo de requisito5.3.3

Os requisitos não funcionais costumam ser mais críticos do que muitos requisitos funcionais. Um sistema pode até ter todos os recursos esperados, mas, se for lento, inseguro, indisponível ou difícil de usar, será rejeitado pelos usuários.

Métricas para Requisitos Não Funcionais5.3.4

Sempre que possível, requisitos não funcionais devem ser definidos de forma mensurável. Isso facilita validação e negociação.

Um requisito como "o sistema deve ser fácil de usar" é vago. Já uma formulação como "um usuário treinado deve conseguir executar as funções principais após 4 horas de treinamento" é muito mais verificável.

O Documento de Requisitos de Software5.4

O documento de requisitos de software, frequentemente chamado de SRS (Software Requirements Specification), é a declaração formal do que deve ser implementado. Ele funciona como ponte entre o problema do negócio e a solução técnica.

Esse documento pode ser usado por diferentes públicos:

1. Clientes e gestores, para verificar se o sistema atende às necessidades organizacionais.
2. Engenheiros de software, para orientar projeto e implementação.
3. Testadores, para derivar casos de teste.
4. Equipes de manutenção, para compreender a intenção original do sistema.

Uma estrutura típica inclui:

1. Introdução e contexto do sistema.
2. Glossário de termos.
3. Requisitos de usuário.
4. Arquitetura geral do sistema.
5. Requisitos detalhados de sistema.
6. Modelos e diagramas.
7. Evolução prevista do sistema.
8. Apêndices e índice.

flowchart TD
    A[Documento de requisitos] --> B[Introducao e contexto]
    A --> C[Glossario]
    A --> D[Requisitos de usuario]
    A --> E[Requisitos de sistema]
    A --> F[Modelos e diagramas]
    A --> G[Evolucao prevista]
    A --> H[Apendices]

flowchart TD
    A[Documento de requisitos] --> B[Introducao e contexto]
    A --> C[Glossario]
    A --> D[Requisitos de usuario]
    A --> E[Requisitos de sistema]
    A --> F[Modelos e diagramas]
    A --> G[Evolucao prevista]
    A --> H[Apendices]

Em ambientes ágeis, muitas vezes esse documento é mais enxuto. Em sistemas grandes, regulados ou críticos, ele tende a ser mais detalhado e formal.

Processos de Engenharia de Requisitos5.5

Sommerville organiza a Engenharia de Requisitos em quatro atividades principais:

1. Estudo de viabilidade
2. Elicitação e análise de requisitos
3. Especificação de requisitos
4. Validação de requisitos

Na prática, essas atividades não acontecem linearmente. Elas são iterativas e frequentemente se sobrepõem.

flowchart LR
    A[Estudo de viabilidade] --> B[Elicitacao e analise]
    B --> C[Especificacao]
    C --> D[Validacao]
    D --> B
    C --> E[Gerenciamento de requisitos]
    D --> E
    B --> E

flowchart LR
    A[Estudo de viabilidade] --> B[Elicitacao e analise]
    B --> C[Especificacao]
    C --> D[Validacao]
    D --> B
    C --> E[Gerenciamento de requisitos]
    D --> E
    B --> E

Estudo de viabilidade5.5.1

O estudo de viabilidade é uma análise inicial para verificar se o sistema faz sentido do ponto de vista técnico, operacional e econômico. Algumas perguntas típicas são:

1. A tecnologia atual permite construir o sistema?
2. O sistema cabe no orçamento e no prazo disponíveis?
3. O ganho organizacional justifica o investimento?

Elicitação e análise5.5.2

É o processo de descobrir os requisitos junto aos stakeholders. Aqui, o foco está em entender o domínio da aplicação, os objetivos do sistema, os conflitos entre interessados e as restrições reais do contexto.

Exemplo: em um sistema acadêmico, o coordenador pode pedir relatórios de evasão, o professor pode pedir diário de classe simplificado e a secretaria pode exigir integração com o sistema institucional. Todos falam do mesmo sistema, mas com prioridades diferentes.

Outro exemplo: em um sistema hospitalar, o médico pode priorizar rapidez de acesso ao prontuário, enquanto o setor jurídico pode priorizar trilha de auditoria e consentimento do paciente. Ambos estão certos, mas puxam o requisito para direções diferentes.

Especificação5.5.3

É o processo de documentar os requisitos em alguma forma estruturada, normalmente em linguagem natural, tabelas, diagramas, cenários e, em alguns casos, notações formais.

Validação5.5.4

É a verificação de que os requisitos são consistentes, completos, realistas e verificáveis.

Gerenciamento de requisitos5.5.5

Como os requisitos mudam ao longo do tempo, é necessário controlar essas mudanças. O gerenciamento de requisitos acompanha solicitações de alteração, impacto, prioridade e rastreabilidade.

Elicitação e Análise de Requisitos5.6

A elicitação é difícil porque diferentes stakeholders têm visões diferentes do sistema, falam a partir de seus próprios contextos e muitas vezes não sabem exatamente o que querem até verem exemplos concretos.

Algumas dificuldades típicas são:

1. Usuários não conseguem explicitar todas as necessidades.
2. Stakeholders possuem interesses conflitantes.
3. Requisitos mudam durante a análise.
4. Regras do domínio são implícitas e nem sempre verbalizadas.

flowchart TD
    A[Stakeholders] --> B[Entrevistas]
    A --> C[Cenarios e casos de uso]
    A --> D[Observacao do trabalho]
    B --> E[Requisitos iniciais]
    C --> E
    D --> E
    E --> F[Negociacao e refinamento]

flowchart TD
    A[Stakeholders] --> B[Entrevistas]
    A --> C[Cenarios e casos de uso]
    A --> D[Observacao do trabalho]
    B --> E[Requisitos iniciais]
    C --> E
    D --> E
    E --> F[Negociacao e refinamento]

Sommerville destaca algumas técnicas importantes para apoiar essa atividade.

Entrevistas5.6.1

Entrevistas podem ser:

1. Fechadas, com perguntas pré-definidas.
2. Abertas, com exploração mais livre dos problemas do domínio.

São úteis para entender objetivos, dores e expectativas, mas têm limitações para capturar conhecimento tácito e regras organizacionais implícitas.

Exemplo: perguntar ao coordenador "quais relatórios você precisa emitir no fechamento do semestre?" é eficiente para captar objetivos, mas pode não revelar atalhos informais usados pela secretaria no dia a dia.

Outro exemplo: entrevistar um professor pode revelar a necessidade de importar notas por planilha, mas talvez não revele o fluxo completo de validação das notas antes do fechamento do diário.

Cenários5.6.2

Cenários descrevem exemplos concretos de uso do sistema. Eles ajudam os usuários a reagir a situações realistas, o que normalmente é mais fácil do que reagir a descrições abstratas.

Um cenário bem escrito pode incluir:

1. Situação inicial.
2. Fluxo normal de eventos.
3. Exceções e problemas possíveis.
4. Estado final do sistema.

Exemplo:
Aluno solicita matrícula em disciplina optativa. O sistema verifica pré-requisito, vagas disponíveis e conflito de horário. Se houver vaga e o aluno atender aos critérios, a matrícula é registrada. Se não houver vaga, o sistema informa indisponibilidade e orienta a fila de espera.

Outro exemplo:
Paciente chega à clínica sem agendamento. A recepção busca o prontuário, verifica se existe encaixe, registra a chegada e encaminha o caso para triagem. Se o paciente não estiver cadastrado, o sistema abre fluxo de cadastro inicial.

Casos de uso5.6.3

Casos de uso identificam interações entre atores e o sistema. Eles ajudam a esclarecer objetivos do usuário e a delimitar funcionalidades relevantes. São especialmente úteis quando queremos entender interações externas, mas não substituem por completo outras técnicas de elicitação.

Exemplos de casos de uso em um sistema acadêmico:

1. Realizar matrícula.
2. Lançar notas.
3. Emitir histórico.
4. Consultar frequência.

Esses casos de uso ajudam a responder a uma pergunta muito cobrada em avaliação: quem interage com o sistema e com qual objetivo? O ator não executa passos isolados; ele busca atingir um objetivo completo de negócio.

Etnografia5.6.4

A etnografia observa o trabalho real dos usuários no ambiente em que o sistema será utilizado. Ela é valiosa porque muitas organizações não funcionam exatamente como seus processos oficiais descrevem. O trabalho cotidiano, os atalhos, as exceções e as cooperações informais entre pessoas podem gerar requisitos críticos que não apareceriam em entrevistas formais.

Exemplo: a secretaria pode oficialmente registrar trancamentos de matrícula por um formulário padronizado, mas na prática pode manter uma planilha paralela para acompanhar casos especiais. Se isso não for observado, o sistema poderá ignorar uma necessidade real do setor.

Outro exemplo: em uma clínica, o fluxo oficial pode dizer que toda medicação é registrada após a consulta, mas na prática um enfermeiro pode antecipar esse registro em casos recorrentes para ganhar tempo no atendimento.

Validação de Requisitos5.7

A validação de requisitos procura verificar se os requisitos realmente definem o sistema que o cliente quer e se são tecnicamente sólidos o suficiente para orientar o desenvolvimento.

As verificações principais são:

1. Validade: os requisitos refletem necessidades reais?
2. Consistência: existem contradições entre requisitos?
3. Completude: faltam funções ou restrições importantes?
4. Realismo: os requisitos podem ser implementados com tecnologia, prazo e orçamento disponíveis?
5. Verificabilidade: é possível testar se o requisito foi atendido?

flowchart TD
    A[Validacao de requisitos] --> B[Validade]
    A --> C[Consistencia]
    A --> D[Completude]
    A --> E[Realismo]
    A --> F[Verificabilidade]

flowchart TD
    A[Validacao de requisitos] --> B[Validade]
    A --> C[Consistencia]
    A --> D[Completude]
    A --> E[Realismo]
    A --> F[Verificabilidade]

Técnicas comuns de validação incluem:

1. Revisões de requisitos com equipe multidisciplinar.
2. Prototipação.
3. Geração de casos de teste a partir dos requisitos.

Mesmo com validação, nem todos os problemas serão encontrados. Por isso, mudanças de requisitos continuam ocorrendo ao longo do projeto.

Gerenciamento de Requisitos5.8

Os requisitos de sistemas reais evoluem continuamente. Negócio muda, legislação muda, tecnologia muda, prioridades dos usuários mudam. Por isso, a Engenharia de Requisitos não termina quando o documento é escrito.

O gerenciamento de requisitos envolve:

1. Identificar unicamente cada requisito.
2. Controlar solicitações de mudança.
3. Avaliar impactos e custos dessas mudanças.
4. Manter rastreabilidade entre requisitos, projeto, implementação e testes.

flowchart LR
    A[Problema ou mudanca proposta] --> B[Analise da mudanca]
    B --> C[Estimativa de impacto e custo]
    C --> D[Decisao]
    D --> E[Atualizacao de requisitos]
    E --> F[Atualizacao de projeto e testes]

flowchart LR
    A[Problema ou mudanca proposta] --> B[Analise da mudanca]
    B --> C[Estimativa de impacto e custo]
    C --> D[Decisao]
    D --> E[Atualizacao de requisitos]
    E --> F[Atualizacao de projeto e testes]

Isso é especialmente importante em sistemas grandes, onde uma pequena alteração em um requisito pode afetar várias partes da arquitetura, da implementação e da validação.

Um bom exemplo é este: se um requisito aparentemente simples mudar de "o sistema deve autenticar o usuário" para "o sistema deve autenticar via login institucional e segundo fator", isso pode afetar interface, integração externa, regras de negócio, testes e treinamento.

Estudo de Caso: MHC-PMS5.9

O MHC-PMS, usado por Sommerville como estudo de caso recorrente, é um bom exemplo de por que a Engenharia de Requisitos é central. Trata-se de um sistema de informação para cuidados com saúde mental, com dois objetivos principais:

1. apoiar o tratamento clínico com informações atualizadas sobre pacientes;
2. gerar informação gerencial para planejamento e controle do serviço de saúde.

Nesse sistema, há exemplos claros de requisitos funcionais e não funcionais:

Funcionais

1. registrar pacientes;
2. manter histórico clínico;
3. acompanhar consultas e tratamentos;
4. gerar relatórios administrativos.

Não funcionais

1. privacidade dos dados do paciente;
2. disponibilidade do sistema nas clínicas;
3. segurança de acesso;
4. suporte ao uso local quando não houver conexão segura com a rede.

Esse tipo de sistema também ilustra um ponto importante: requisitos podem entrar em conflito. Por exemplo, manter uma única cópia dos dados ajuda a privacidade, mas múltiplas cópias locais ajudam a disponibilidade. O trabalho da Engenharia de Requisitos é justamente tornar esses conflitos explícitos para que sejam negociados.

Questões5.10

Próximos passos5.11

Na próxima aula, avançaremos para Modelagem de Sistemas com UML, onde veremos como transformar requisitos em modelos visuais de contexto, interação, estrutura e comportamento.