Engenharia de Software

Ementa: Histórico da Computação. Introdução a teoria geral dos sistemas. Áreas de conhecimento da Engenharia de Software (requisitos, projeto, construção, teste, manutenção, gerência de configuração, gerência de projeto, processo, modelos e métodos, qualidade, prática profissional, economia e fundamentos de engenharia). Engenharia de Sistemas (fundamentos, metodologias, stakeholders e ciclo de vida).

===============================================

Introdução 

=============================================== 

Uma Jornada Clássica e Contemporânea

A Engenharia de Software, disciplina que se dedica à aplicação de princípios de engenharia para o desenvolvimento de software, tem suas raízes fincadas em um passado onde os desafios de construir sistemas complexos começaram a emergir. Ao longo das décadas, a área evoluiu, incorporando novas metodologias e tecnologias, mas mantendo a essência de seus fundamentos.

A Crise do Software e o Nascimento da Engenharia

A década de 1960 foi marcada pela chamada "crise do software", um período em que os projetos de software frequentemente ultrapassavam orçamentos, prazos e não atendiam às expectativas dos usuários. Foi nesse contexto que a Engenharia de Software surgiu como uma resposta, buscando estabelecer uma abordagem mais sistemática e disciplinada para o desenvolvimento de software.

"A Engenharia de Software é o estabelecimento e uso de princípios sólidos de engenharia para obter economicamente software confiável e que funcione eficientemente em máquinas reais." - Fritz Bauer (1972)

A Importância dos Processos e Metodologias

Uma das contribuições mais significativas da Engenharia de Software foi a introdução de processos e metodologias para guiar o desenvolvimento de software. Modelos como o Modelo Cascata, proposto por Winston Royce em 1970, estabeleceram uma sequência de fases (requisitos, projeto, implementação, teste e manutenção) que se tornaram a base para muitos projetos.

"O modelo cascata é um modelo de processo sequencial, no qual o desenvolvimento flui de forma constante para baixo (como uma cascata) através das fases de análise de requisitos, projeto, implementação, teste, integração e manutenção." - Winston Royce (1970)

A Evolução para a Agilidade

Com o tempo, a necessidade de maior flexibilidade e adaptação às mudanças levou ao surgimento de metodologias ágeis, como o Scrum e o Extreme Programming (XP). Essas abordagens valorizam a colaboração, a entrega contínua de software funcional e a resposta rápida às mudanças nos requisitos.

"Indivíduos e interações acima de processos e ferramentas. Software funcionando acima de documentação abrangente. Colaboração com o cliente acima de negociação de contratos. Responder a mudanças acima de seguir um plano." - Manifesto Ágil (2001)

A Qualidade como Pilar Fundamental

A qualidade do software é um aspecto central da Engenharia de Software. Autores como Watts Humphrey, com seu modelo de maturidade de capacidade (CMM), enfatizaram a importância de processos de qualidade para garantir a entrega de software confiável e de alto desempenho.

"A qualidade não é uma inspeção, é um processo." - Watts Humphrey
 

 O Futuro da Engenharia de Software

A Engenharia de Software continua a evoluir, impulsionada por novas tecnologias como inteligência artificial, computação em nuvem e Internet das Coisas (IoT). A capacidade de construir sistemas cada vez mais complexos e distribuídos exige uma abordagem sólida e adaptável, mantendo sempre o foco na qualidade, na eficiência e na satisfação do usuário.

"A melhor maneira de prever o futuro é inventá-lo." - Alan Kay

Em resumo, a Engenharia de Software é uma disciplina em constante evolução, que busca aplicar princípios de engenharia para o desenvolvimento de software de alta qualidade. Ao longo de sua história, autores clássicos e abordagens inovadoras moldaram a área, preparando-a para os desafios e oportunidades do futuro.

 

  O que um Engenheiro de Software faz? 

 Engenharia de Software foi Regulamentada. E Agora?

 Boas práticas da engenharia de software!  

 Por onde começar a programar? Dicas e Conselhos! 

 Basic Knowledge for Beginners in Programming 

 Entendendo GIT | (não é um tutorial!)  

 O QUE É GIT E GITHUB? - definição e conceitos importantes

 Aprenda Git e Github em 5 minutos 

GDB-Online compiler and debugger 

==============================================

Exercícios sobre análise de requisitos

Exercício 1: Conceitos Gerais

1. Defina o que é análise de requisitos e qual sua importância no desenvolvimento de software.  
2. Explique a diferença entre requisitos funcionais e não funcionais, dando exemplos de cada um.  
3. O que é um requisito de usabilidade? Dê um exemplo prático.  
4. Quais são as principais etapas do processo de elicitação de requisitos?  

Respostas do exercício 1:

1) A análise de requisitos é o processo de identificar, documentar e validar as necessidades e expectativas dos stakeholders em relação a um sistema de software. Esse processo é essencial porque garante que o software atenda aos objetivos do negócio, reduza retrabalho e minimize erros de desenvolvimento. Uma análise bem-feita ajuda a alinhar as expectativas do cliente com o que será entregue, evitando ambiguidades e falhas no projeto. 

2) Requisitos funcionais: Definem o que o sistema deve fazer, ou seja, suas funcionalidades e comportamentos esperados. Exemplo: "O sistema deve permitir que o usuário cadastre novos clientes com nome, e-mail e telefone."
Requisitos não funcionais: Descrevem como o sistema deve se comportar, incluindo restrições de desempenho, segurança e usabilidade.
Exemplo: "O sistema deve responder a uma solicitação de login em até 2 segundos." 

3) Um requisito de usabilidade define o quão fácil e intuitivo é para um usuário interagir com o sistema. Ele está relacionado à experiência do usuário (UX) e à eficiência da interface.
Exemplo prático: "O sistema deve permitir que um novo usuário consiga concluir um pedido online em no máximo 3 cliques, sem necessidade de treinamento prévio."

==============================================

Exercício 2: Tipos de Requisitos

1. Classifique os seguintes requisitos como funcionais ou não funcionais:  
   - O sistema deve permitir o login via biometria.  
   - O tempo de resposta da aplicação não deve ultrapassar 2 segundos.  
   - O sistema deve armazenar todos os registros de clientes em um banco de dados SQL.  
   - O software deve ser compatível com dispositivos móveis Android e iOS.  
   - Somente administradores podem excluir registros do sistema.  

Respostas do exercício 2:

1)  O sistema deve permitir o login via biometria. → Funcional (Define uma funcionalidade do sistema, ou seja, a autenticação por biometria.)

O tempo de resposta da aplicação não deve ultrapassar 2 segundos. → Não funcional (Refere-se ao desempenho do sistema, não a uma funcionalidade específica.)

O sistema deve armazenar todos os registros de clientes em um banco de dados SQL. → Funcional (Especifica uma funcionalidade do sistema, que é o armazenamento de dados.)

O software deve ser compatível com dispositivos móveis Android e iOS. → Não funcional (Define uma restrição de compatibilidade, não uma funcionalidade do sistema.)

Somente administradores podem excluir registros do sistema. → Funcional (Determina uma regra de negócio relacionada ao controle de acesso.)

==============================================

Exercício 3: Técnicas de Elicitação

1. Quais são as principais técnicas de elicitação de requisitos? Explique ao menos três delas.  
2. Um analista de requisitos está lidando com um cliente que não consegue expressar claramente suas necessidades. Que técnicas poderiam ser utilizadas para extrair informações de forma mais eficaz?  

Respostas do exercício 3:

1) A elicitação de requisitos é o processo de coleta de informações sobre o que o sistema deve fazer. Algumas das principais técnicas são:
🔹 Entrevistas 

Consiste em conversar diretamente com os stakeholders para entender suas necessidades e expectativas. Pode ser estruturada (com perguntas definidas) ou não estruturada (mais aberta e exploratória).

    Exemplo: O analista entrevista um gerente para entender quais relatórios ele precisa no sistema.

🔹 Observação

Envolve acompanhar o usuário em seu ambiente de trabalho para entender como ele realiza suas tarefas e quais dificuldades enfrenta.

    Exemplo: Observar um operador de caixa para entender como ele lida com vendas e pagamentos.

🔹 Prototipação

Criação de versões preliminares do sistema (wireframes, mockups ou protótipos interativos) para validar requisitos antes do desenvolvimento.

    Exemplo: Criar uma tela simulada do sistema de pedidos para que o cliente valide se atende às suas necessidades.

2) Técnicas para lidar com clientes que não expressam claramente suas necessidades.

Quando um cliente tem dificuldade em definir seus requisitos, o analista pode utilizar técnicas mais dinâmicas, como:

✔ Prototipação – Criar um esboço ou modelo do sistema para que o cliente visualize e forneça feedback.
✔ Observação – Analisar como o cliente trabalha e identificar requisitos implícitos.
✔ Brainstorming – Reunir um grupo de usuários e incentivá-los a sugerir ideias livremente.
✔ Casos de Uso – Criar narrativas sobre como o usuário interage com o sistema para entender melhor suas necessidades.

==============================================

Exercício 4: Casos Práticos

1. Uma empresa deseja desenvolver um aplicativo de entrega de comida. Liste ao menos *cinco requisitos funcionais* e *três requisitos não funcionais* para esse sistema.  
2. Analise o seguinte requisito e reescreva-o para torná-lo mais claro e preciso:  
   - "O sistema deve ser rápido e fácil de usar."  

Respostas do exercício 4:

Claro, vamos analisar os requisitos para o aplicativo de entrega de comida:
 

1. Requisitos Funcionais:

* Cadastro de Usuários: O aplicativo deve permitir que os usuários criem contas, armazenando informações como nome, endereço, telefone e preferências de pagamento.
* Busca de Restaurantes: Os usuários devem poder procurar restaurantes por nome, tipo de culinária, localização ou pratos específicos.
* Visualização de Cardápios: O aplicativo deve exibir os cardápios dos restaurantes, com descrições detalhadas dos pratos, preços e fotos.
* Realização de Pedidos: Os usuários devem poder selecionar os pratos, adicionar observações, escolher a forma de pagamento e finalizar o pedido.
* Acompanhamento de Pedidos: O aplicativo deve permitir que os usuários acompanhem o status de seus pedidos em tempo real, desde a confirmação até a entrega.
 

2. Requisitos Não Funcionais:

* Desempenho: O aplicativo deve ser rápido e responsivo, com tempos de carregamento curtos e navegação fluida.
* Segurança: O aplicativo deve proteger as informações dos usuários, como dados de pagamento e endereços, contra acesso não autorizado.
* Disponibilidade: O aplicativo deve estar disponível 24 horas por dia, 7 dias por semana, com alta confiabilidade e tempo de inatividade mínimo.
 

3. Reescrita do Requisito:

* "O sistema deve ser rápido e fácil de usar."
Reescrita:

* "O sistema deve apresentar um tempo de resposta máximo de 2 segundos para todas as interações do usuário e deve seguir as diretrizes de design de interface do usuário da plataforma para garantir uma experiência intuitiva."
Explicação da Reescrita:

* A reescrita torna o requisito mais específico e mensurável.
* O tempo de resposta máximo de 2 segundos fornece um critério objetivo para avaliar o desempenho do sistema.
* A referência às diretrizes de design de interface do usuário da plataforma garante que o sistema seja consistente e fácil de usar.

==============================================

Exercício 5: Modelagem de Requisitos 

1. O que é um **caso de uso** e qual sua utilidade na análise de requisitos?  
2. Considere um sistema de biblioteca online. Identifique pelo menos **três atores** e descreva **um caso de uso** para um desses atores.  
3. Desenhe um diagrama de caso de uso representando um sistema de e-commerce simples.  

Respostas do exercício 5:

1) O que é um caso de uso e qual sua utilidade na análise de requisitos?

Um caso de uso é uma técnica para captura de requisitos de um sistema, descrevendo a interação entre atores (usuários ou outros sistemas) e o sistema em si. Ele detalha as ações que um ator realiza para atingir um objetivo específico, como "fazer login", "realizar uma compra" ou "reservar um livro".

Utilidade na Análise de Requisitos:

    Compreensão do Sistema: Casos de uso ajudam a entender o que o sistema precisa fazer, do ponto de vista do usuário.
    Comunicação: Servem como uma linguagem comum entre desenvolvedores, clientes e outros stakeholders.
    Validação: Facilitam a validação dos requisitos com os usuários, garantindo que o sistema atenda às suas necessidades.
    Planejamento: Auxiliam no planejamento do desenvolvimento, definindo o escopo do sistema e priorizando funcionalidades.
    Testes: Servem como base para a criação de casos de teste, garantindo a cobertura de todas as funcionalidades do sistema.

 2) Sistema de Biblioteca Online:

Atores:

    Leitor
    Bibliotecário
    Sistema de Pagamento

Caso de Uso (Leitor):

    Nome do Caso de Uso: Realizar Reserva de Livro
    Descrição: O leitor acessa o sistema, busca um livro disponível e solicita a reserva para retirada posterior.
    Fluxo Principal:
        O leitor faz login no sistema.
        O leitor pesquisa o livro desejado.
        O sistema exibe os livros disponíveis.
        O leitor seleciona o livro e solicita a reserva.
        O sistema confirma a reserva e informa a data de retirada.
        O leitor recebe um aviso por e-mail ou notificação no aplicativo.
    Fluxos Alternativos:
        Livro não disponível: o sistema informa a indisponibilidade e oferece opções de espera ou livros similares.
        Reserva cancelada: o leitor pode cancelar a reserva antes da data de retirada.
 

3) Diagrama de Caso de Uso (E-commerce Simples):

Code snippet

usecaseDiagram
  actor Cliente
  actor SistemaDePagamento
  actor SistemaDeEntrega

  Cliente --> (Buscar Produtos)
  Cliente --> (Adicionar ao Carrinho)
  Cliente --> (Realizar Pagamento)
  Cliente --> (Acompanhar Pedido)

  (Realizar Pagamento) ..> SistemaDePagamento : include
  (Acompanhar Pedido) ..> SistemaDeEntrega : include

Explicação do Diagrama:

    Cliente: O ator principal, que interage com o sistema para comprar produtos.
    Sistema de Pagamento: Um sistema externo que processa os pagamentos.
    Sistema de Entrega: Um sistema externo que gerencia a entrega dos pedidos.
    Casos de Uso:
        Buscar Produtos: o cliente navega pelo catálogo e busca produtos.
        Adicionar ao Carrinho: o cliente adiciona produtos ao carrinho de compras.
        Realizar Pagamento: o cliente finaliza a compra e realiza o pagamento (inclui interação com o Sistema de Pagamento).
        Acompanhar Pedido: o cliente acompanha o status da entrega do pedido (inclui interação com o Sistema de Entrega).
    Relacionamentos:
        Associação: linhas sólidas que conectam atores a casos de uso.
        Include: linhas tracejadas com a etiqueta "include", indicando que um caso de uso inclui outro.

==============================================

Exercício 6 - Elicitação de Requisitos:

Cenário: Uma startup deseja desenvolver um aplicativo móvel para conectar pessoas que precisam de pequenos serviços domésticos (encanadores, eletricistas, etc.) com profissionais autônomos.
    a) Quais técnicas de elicitação de requisitos você utilizaria para este projeto? Justifique suas escolhas.
    b) Elabore um conjunto de perguntas para uma entrevista com um potencial usuário do aplicativo.
    c) Crie um caso de uso que descreva o processo de um usuário solicitar um serviço através do aplicativo.

Respostas do exercício 6:

a) Técnicas de elicitação de requisitos para o projeto

Para desenvolver um aplicativo de conexão entre clientes e prestadores de serviços, as seguintes técnicas seriam adequadas:

    Entrevistas – Para entender as necessidades dos usuários (clientes e profissionais), suas dificuldades atuais e expectativas sobre a plataforma.

    Prototipação – Criar esboços das telas do aplicativo e validar se atendem às necessidades dos usuários.

    Observação – Acompanhar como clientes encontram e contratam prestadores hoje, identificando problemas que o app pode solucionar.

    Brainstorming – Reunir a equipe e stakeholders para gerar ideias inovadoras sobre funcionalidades, como avaliações, formas de pagamento e filtros de busca.

b) Perguntas para entrevista com um usuário potencial

    Como você costuma encontrar prestadores de serviços domésticos hoje?

    Quais dificuldades você enfrenta ao contratar um profissional autônomo?

    O que tornaria esse processo mais fácil e confiável para você?

    Você prefere agendar um serviço com antecedência ou precisa de atendimento imediato?

    Você costuma dar prioridade para profissionais com avaliações de outros clientes?

    Quais métodos de pagamento você preferiria usar no aplicativo?

    Como você avaliaria um profissional após o serviço? O que seria mais importante na sua decisão?

    Que funcionalidades você gostaria de ver em um app desse tipo?

    Você estaria disposto a pagar uma taxa extra por garantias de qualidade ou seguro do serviço?

    O que faria você deixar de usar o aplicativo?

c) Caso de Uso: Solicitação de Serviço
Nome: Solicitação de Serviço
Ator: Usuário (Cliente)
Descrição: O usuário solicita um serviço doméstico através do aplicativo.
Fluxo Principal:

    O usuário acessa o aplicativo e faz login.

    O usuário seleciona a categoria do serviço (ex: encanamento, eletricista).

    O usuário informa detalhes do serviço (ex: conserto de vazamento na cozinha).

    O usuário escolhe uma data e horário desejado.

    O sistema exibe profissionais disponíveis com avaliações e preços.

    O usuário seleciona um profissional e confirma a solicitação.

    O profissional recebe a solicitação e aceita ou recusa o pedido.

    O usuário recebe a confirmação e acompanha o status do serviço.

    Após a conclusão, o usuário avalia o profissional.

Fluxo Alternativo:

    Se nenhum profissional estiver disponível, o sistema sugere novas datas ou envia notificações quando houver disponibilidade.

==============================================

Exercício 7 -  Tipos de Requisitos:

Cenário: Um sistema de e-commerce deve ser desenvolvido para uma loja de roupas online.
    a) Identifique pelo menos 5 requisitos funcionais para este sistema.
    b) Identifique pelo menos 3 requisitos não funcionais para este sistema, classificando-os (desempenho, segurança, usabilidade, etc.).
    c) Explique a diferença entre requisitos de usuário e requisitos de sistema.

Respostas do exercício 7:

a) Requisitos Funcionais para o Sistema de E-commerce

    O sistema deve permitir que os usuários cadastrem uma conta com nome, e-mail e senha.

    O sistema deve permitir a busca de produtos por nome, categoria e faixa de preço.

    O sistema deve possibilitar a adição de produtos ao carrinho de compras e a finalização da compra.

    O sistema deve enviar notificações por e-mail para o cliente após a conclusão da compra.

    O sistema deve permitir que os usuários realizem pagamentos via cartão de crédito, boleto e Pix.

b) Requisitos Não Funcionais

    Desempenho: O tempo de carregamento das páginas não deve ultrapassar 2 segundos em conexões de internet de pelo menos 10 Mbps.

    Segurança: Os dados dos clientes devem ser armazenados de forma criptografada e o sistema deve oferecer autenticação em dois fatores para login.

    Usabilidade: O site deve ser responsivo e acessível em dispositivos móveis e desktops, garantindo uma navegação intuitiva.

c) Diferença entre Requisitos de Usuário e Requisitos de Sistema

    Requisitos de Usuário: São descritos de forma geral e em linguagem compreensível pelos usuários finais, focando em suas necessidades e expectativas.

        Exemplo: "O usuário deve conseguir visualizar todos os produtos disponíveis antes de realizar uma compra."

    Requisitos de Sistema: São mais técnicos e detalhados, descrevendo como o sistema deve ser implementado para atender às necessidades do usuário.

        Exemplo: "O sistema deve listar os produtos em uma página paginada, exibindo no máximo 20 itens por página."

Os requisitos de usuário servem como base para a definição dos requisitos de sistema, garantindo que o software atenda às expectativas do cliente.

==============================================

Exercício 8 - Especificação de Requisitos:

Cenário: Um sistema de gerenciamento de biblioteca deve permitir o cadastro de livros, empréstimos e devoluções.
    a) Escreva a especificação de um requisito funcional para o cadastro de um novo livro no sistema, utilizando um modelo de especificação (ex: IEEE 830).
    b) Crie um diagrama de casos de uso para o sistema de gerenciamento de biblioteca.
    c) Descreva um cenário de teste para verificar a funcionalidade de empréstimo de um livro. 

Respostas do exercício 8:

a) Especificação de Requisito Funcional (IEEE 830)
Requisito Funcional: Cadastro de Novo Livro

Identificador: RF-001
Nome: Cadastro de Livro
Descrição: O sistema deve permitir que um bibliotecário cadastre novos livros no sistema, inserindo informações essenciais.
Atores: Bibliotecário
Pré-condições: O bibliotecário deve estar autenticado no sistema.
Pós-condições: O livro será salvo no banco de dados e estará disponível para empréstimo.

Fluxo Principal:

    O bibliotecário acessa o módulo de cadastro de livros.

    O sistema exibe um formulário para inserção de dados do livro.

    O bibliotecário informa os seguintes dados:

        Título

        Autor

        Editora

        Ano de publicação

        ISBN

        Quantidade de exemplares disponíveis

    O bibliotecário confirma o cadastro.

    O sistema valida as informações e salva o livro no banco de dados.

    O sistema exibe uma mensagem de sucesso.

Fluxo Alternativo:

    Se algum campo obrigatório não for preenchido, o sistema exibe uma mensagem de erro e solicita a correção.

b) Diagrama de Casos de Uso

O diagrama de casos de uso para o sistema de gerenciamento de biblioteca inclui os seguintes atores e funcionalidades:
Atores:

    Bibliotecário (responsável por gerenciar livros e usuários)

    Usuário (Leitor) (responsável por realizar empréstimos e devoluções)

Casos de Uso:

    Bibliotecário:

        Cadastrar livros

        Editar informações dos livros

        Consultar livros

        Registrar empréstimo

        Registrar devolução

    Usuário:

        Pesquisar livros

        Solicitar empréstimo

        Devolver livros

c) Cenário de Teste: Empréstimo de um Livro

Título: Testar o processo de empréstimo de um livro

Objetivo: Verificar se um usuário pode realizar o empréstimo de um livro corretamente.

Pré-condições:

    O usuário deve estar autenticado no sistema.

    Deve haver pelo menos um exemplar disponível do livro desejado.

Passos:

    O usuário acessa a funcionalidade de pesquisa de livros.

    O usuário localiza o livro desejado e verifica sua disponibilidade.

    O usuário seleciona a opção “Solicitar Empréstimo”.

    O sistema verifica se o usuário está dentro do limite de empréstimos ativos.

    O sistema registra o empréstimo e reduz a quantidade de exemplares disponíveis.

    O sistema exibe uma confirmação do empréstimo e a data de devolução prevista.

Critério de Sucesso:

    O livro é registrado como emprestado no sistema.

    A quantidade de exemplares disponíveis é reduzida.

    O usuário visualiza a data de devolução.

Fluxo Alternativo:

    Se o usuário já atingiu o limite de empréstimos, o sistema exibe uma mensagem de erro.

    Se não houver exemplares disponíveis, o sistema informa a indisponibilidade do livro.

==============================================

Exercício 9 - Validação de Requisitos:

Cenário: Uma equipe de desenvolvimento apresentou a especificação de requisitos para um sistema de gestão de projetos.
    a) Quais técnicas de validação de requisitos você utilizaria para garantir a qualidade da especificação?
    b) Elabore uma lista de verificação (checklist) para revisar a especificação de requisitos.
    c) Descreva um processo de revisão formal da especificação de requisitos.

Respostas do exercício 9:

a) Técnicas de Validação de Requisitos

Para garantir a qualidade da especificação de requisitos do sistema de gestão de projetos, algumas técnicas de validação podem ser utilizadas:

    Revisão por Pares – Outros membros da equipe revisam a especificação para identificar inconsistências, ambiguidades ou erros.

    Prototipação – Criar protótipos das funcionalidades para validar se os requisitos atendem às necessidades dos usuários.

    Casos de Uso e Cenários – Simular fluxos de trabalho no sistema para verificar se os requisitos cobrem todas as necessidades do usuário.

    Matriz de Rastreabilidade – Garantir que todos os requisitos estão alinhados com os objetivos do projeto e possuem rastreabilidade até suas fontes.

b) Checklist para Revisão da Especificação de Requisitos

✅ Clareza e Compreensão

    Os requisitos estão descritos de forma clara e sem ambiguidades?

    Há definições para termos técnicos ou específicos do negócio?

✅ Completude

    Todos os requisitos essenciais foram identificados?

    Há requisitos para todas as funcionalidades críticas do sistema?

✅ Consistência

    Não há contradições entre os requisitos?

    Os requisitos seguem um padrão de escrita uniforme?

✅ Viabilidade

    Os requisitos podem ser implementados com a tecnologia disponível?

    Não há requisitos que violem restrições técnicas ou de negócio?

✅ Rastreabilidade

    Cada requisito tem um identificador único?

    Os requisitos podem ser rastreados até suas fontes (ex: entrevistas, documentos de negócio)?

✅ Validação com Usuário

    Os usuários finais revisaram e aprovaram os requisitos?

    Há cenários de uso que demonstram como os requisitos atendem às necessidades do usuário?

c) Processo de Revisão Formal da Especificação de Requisitos

    Preparação

        Definir a equipe de revisão (analistas, desenvolvedores, clientes).

        Distribuir a especificação para todos os participantes com antecedência.

    Reunião de Revisão

        Apresentar os requisitos e discutir cada um em detalhes.

        Identificar ambiguidades, inconsistências e omissões.

    Registro de Comentários

        Documentar todas as observações e ajustes sugeridos.

    Correção e Atualização

        A equipe de análise revisa os requisitos conforme os feedbacks recebidos.

        Atualizar a documentação e solicitar nova validação se necessário.

    Aprovação Final

        Os stakeholders validam a versão revisada da especificação.

        A especificação é considerada base oficial para o desenvolvimento.

==============================================

Exercício 10 - Gerenciamento de Requisitos:

Cenário: Durante o desenvolvimento de um sistema de reservas de hotel, um cliente solicita a inclusão de uma nova funcionalidade para reservas de grupos.
    a) Como a equipe de desenvolvimento deve lidar com esta mudança de requisito?
    b) Quais ferramentas de gerenciamento de requisitos podem auxiliar neste processo?
    c) Explique a importância da rastreabilidade de requisitos.

Respostas do exercício 10:

a) Como a equipe deve lidar com a mudança de requisito?

    Analisar o impacto da mudança

        Avaliar como a funcionalidade de reservas de grupos afetará o escopo, prazo e custo do projeto.

        Identificar possíveis impactos técnicos no banco de dados, interface e lógica de negócios.

    Documentar a solicitação

        Registrar a solicitação formalmente e associá-la aos requisitos existentes.

        Criar um documento de alteração de requisitos (Change Request).

    Revisar com os stakeholders

        Discutir com o cliente para entender exatamente o que ele espera da funcionalidade.

        Priorizar a mudança conforme o impacto e a importância para o negócio.

    Aprovação e Planejamento

        Se aprovada, incluir a nova funcionalidade no backlog do projeto.

        Planejar a implementação da mudança, ajustando cronograma e recursos conforme necessário.

    Implementação e Testes

        Desenvolver a nova funcionalidade e validar se ela atende às necessidades do cliente.

        Testar a integração da reserva de grupos com as demais funcionalidades do sistema.

b) Ferramentas de Gerenciamento de Requisitos

Algumas ferramentas que podem auxiliar no controle e rastreamento das mudanças de requisitos incluem:

🔹 Jira – Permite registrar, rastrear e priorizar requisitos e mudanças.
🔹 IBM Engineering Requirements Management DOORS – Ideal para projetos complexos que exigem rastreabilidade detalhada.
🔹 Azure DevOps – Possui módulos para gerenciamento de backlog e requisitos.
🔹 Trello – Simples e eficaz para organizar mudanças e tarefas do projeto.
🔹 Confluence – Pode ser usado para documentar requisitos e mudanças em conjunto com outras ferramentas.

c) Importância da Rastreabilidade de Requisitos

A rastreabilidade de requisitos permite acompanhar a origem, evolução e impacto de cada requisito ao longo do ciclo de vida do projeto. Sua importância inclui:

✔ Facilita o gerenciamento de mudanças – Permite identificar rapidamente quais partes do sistema serão afetadas por uma alteração.
✔ Garante alinhamento com as necessidades do cliente – Ajuda a evitar que funcionalidades críticas sejam esquecidas ou alteradas sem justificativa.
✔ Melhora a qualidade do software – Reduz inconsistências e erros ao garantir que cada requisito seja implementado e testado corretamente.
✔ Auxilia na conformidade e auditoria – Essencial para setores regulados, onde cada requisito precisa ter um histórico claro de aprovação e implementação.

Manter a rastreabilidade dos requisitos ajuda a equipe a trabalhar de forma organizada e minimizar impactos negativos das mudanças no projeto.