ICC
Portal de Disciplinas

Processos e Requisitos de Software

Entenda os fundamentos que orientam soluções digitais mais sólidas, inteligentes e duradouras.

Visão Geral da Disciplina

Código: INF1916 | Turma: MINF-0102

Carga horária: 72h (4 créditos)

Horário e Local: Segundas e Quintas às 09:20 - 11:00 | Bloco B – Sala 202 | Bloco A Sala 710 – UNICAP

Bem-vindo ao Laboratório Ágil de Engenharia de Requisitos (LAER). Aqui, você vai além do estudo dos processos e requisitos: atua como parte de um time ágil, toma decisões reais, enfrenta mudanças e sustenta suas escolhas com argumentação técnica em um projeto completo.

Tópicos Principais:

Fundamentos de Processos de Software

Engenharia de Requisitos

Requisitos em Ambiente Ágil

Qualidade, Métricas e Arquitetura

Projeto Integrador – Laboratório Ágil (LAER)

Bem-vindo à Disciplina!

Uma jornada do conceito à prática ágil

O que esperar desta disciplina?

Evolução Progressiva

A disciplina foi organizada para que cada módulo prepare o estudante para o seguinte, permitindo uma evolução contínua das competências.

Aprendizado Ativo

Não é uma disciplina de memorização. É sobre compreender processos, tomar decisões ágeis e justificar tecnicamente suas escolhas.

Projeto Integrador Real

Você desenvolverá um projeto ágil completo do zero, aplicando Scrum, histórias de usuário, sprints e métricas em um domínio real escolhido pela equipe.

Habilidades Profissionais

Ao final, você terá competências essenciais para o mercado: engenharia de requisitos, gestão ágil, métricas de processo e capacidade de defesa técnica.

Como ter sucesso?

  • Participe ativamente das aulas e tire dúvidas
  • Pratique com as listas de exercícios regularmente
  • Desenvolva o projeto continuamente, evoluindo sprint a sprint.
  • Trabalhe em equipe de forma colaborativa e transparente
  • Entenda os processos, não apenas decore os frameworks
  • Prepare-se bem para a defesa técnica final

Objetivos da Disciplina

Conheça as competências que você desenvolverá ao longo da disciplina.

Objetivo Geral

Capacitar o estudante a compreender, aplicar e gerenciar processos de desenvolvimento de software, com ênfase em engenharia de requisitos e metodologias ágeis, assegurando a entrega de produtos de software com qualidade, rastreabilidade e alinhamento às necessidades do cliente.

Objetivos Específicos

Compreender modelos de processo de software (Cascata, Ágil, Scrum)

Elicitar, documentar e validar requisitos funcionais e não funcionais

Aplicar técnicas de gerenciamento de requisitos em projetos reais

Desenvolver e priorizar Product Backlog com histórias de usuário

Planejar e executar Sprints com transparência e métricas ágeis

Avaliar qualidade de requisitos e arquitetura de software

Defender tecnicamente projeto integrador ágil (LAER)

Resultados de Aprendizagem

Ao final da disciplina, o estudante será capaz de:

  1. RA1 – Identificar e comparar modelos de processo de software
  1. RA2 – Elicitar e documentar requisitos com qualidade
  1. RA3 – Gerenciar requisitos em ambiente ágil com Scrum
  1. RA4 – Planejar e executar sprints com métricas e transparência
  1. RA5 – Avaliar qualidade, arquitetura e requisitos não funcionais
  1. RA6 – Defender tecnicamente projeto integrador ágil

Mapa de Competências × Avaliação

Organização em Macro-Módulos

A disciplina está organizada em cinco macro-módulos progressivos, do conceitual ao prático ágil.

1

Macro-Módulo I

Fundamentos de Processos de Software

  • Modelos de processo (Cascata, Ágil)
  • Ciclo de vida de software
  • Introdução ao Scrum

Pré-requisito: Nenhum | Avaliação: 1º GQ (Prova)

2

Macro-Módulo II

Requisitos em Ambiente Ágil

  • Histórias de usuário
  • Product Backlog e Priorização
  • Estimativas ágeis e Sprint Planning

Pré-requisito: Macro-Módulo I | Avaliação: Projeto – Sprint 1

3

Macro-Módulo III

Engenharia de Requisitos

  • Requisitos funcionais e não funcionais
  • Elicitação, documentação e validação
  • Gerenciamento, rastreabilidade e mudanças

Pré-requisito: Macro-Módulo II | Avaliação: 1º GQ (Prova + Projeto)

4

Macro-Módulo IV

Qualidade, Métricas e Arquitetura

  • Requisitos não funcionais
  • Arquitetura de Software
  • Qualidade do Processo e Métricas Ágeis

Pré-requisito: Macro-Módulo III | Avaliação: 2º GQ (Projeto)

5

Macro-Módulo V

Projeto Integrador – LAER

  • Desenvolvimento de projeto ágil
  • Aplicação integrada de conceitos
  • Defesa técnica estruturada

Pré-requisito: Macro-Módulos I–IV | Avaliação: Defesa Técnica Final (2º GQ)

Como Serão as Aulas

Estrutura de cada encontro

Exposição Dialogada

Apresentação dos conceitos com espaço para perguntas, discussões e conexões com situações reais do mercado.

Resolução de Problemas

Exercícios práticos aplicados em sala, individualmente ou em grupo, com feedback imediato do professor.

Estudos de Caso

Análise de situações reais de projetos de software para contextualizar os conceitos e desenvolver senso crítico.

Aplicação ao Projeto Integrador

Cada aula contribui diretamente ao LAER. Os conceitos aprendidos são imediatamente aplicados ao backlog, sprints ou documentação do projeto.

Metodologia de Ensino

Nossa abordagem pedagógica é centrada no aluno, combinando teoria e prática através de metodologias ativas que promovem o desenvolvimento progressivo de competências.

Estratégias Pedagógicas

Resolução progressiva de problemas

Listas estruturadas (1 fácil, 2 médias, 1 difícil, 1 desafio)

Desenvolvimento de Projeto Integrador

Simulações práticas de Sprint e Scrum

Revisões estruturadas antes dos GQ

Aprendizagem baseada na Taxonomia de Bloom

Ferramentas e Recursos

Conheça as ferramentas que utilizaremos e as referências bibliográficas recomendadas.

Ferramentas Utilizadas

Bibliografia Básica

  • SOMMERVILLE, I. Engenharia de Software. Pearson.
  • PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: Uma Abordagem Profissional. McGraw-Hill.

Bibliografia Complementar

  • WIEGERS, K.; BEATTY, J. Software Requirements. Microsoft Press.
  • COHN, M. User Stories Applied. Addison-Wesley.
  • BECK, K. Extreme Programming Explained. Addison-Wesley.
  • KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: Processes and Techniques. Wiley.

Material das Aulas e Exercícios

📘 Macro-Módulo I – Fundamentos de Processos de Software

Apresenta os modelos de processo de software e introduz o Scrum como framework ágil central da disciplina.

📗 Macro-Módulo II – Requisitos em Ambiente Ágil

Aborda a escrita de histórias de usuário, priorização de backlog, estimativas e planejamento de sprints.

📙 Macro-Módulo III – Engenharia de Requisitos

Desenvolve a capacidade de elicitar, documentar, validar e gerenciar requisitos funcionais e não funcionais.

📕 Macro-Módulo IV – Qualidade, Métricas e Arquitetura

Explora práticas avançadas de engenharia de software: XP, dívida técnica, métricas de processo, escalabilidade, DevOps e gestão de produto.

🏁 Macro-Módulo V – Projeto Integrador – LAER

Integra todos os conceitos da disciplina em um projeto ágil real, culminando na defesa técnica final.

Sistema de Avaliação

A avaliação da disciplina foi planejada para acompanhar a aprendizagem de forma contínua, valorizando tanto o desenvolvimento ao longo do semestre quanto a demonstração de competências nas avaliações formais. Ela está organizada em dois tipos de avaliação.

📘 Avaliação Formativa

A avaliação formativa ocorre ao longo das aulas e tem como objetivo acompanhar a evolução da aprendizagem, identificar dificuldades e fornecer feedback contínuo para orientar o desenvolvimento do estudante.

Serão utilizadas estratégias como:

  • Quizzes
  • Listas de exercícios
  • Estudos de caso
  • Atividades em sala
  • Oficinas
  • Discussões técnicas
  • Feedbacks sobre o Projeto Integrador

Essas atividades são obrigatórias e fazem parte da metodologia da disciplina, contribuindo para a consolidação dos conteúdos antes das avaliações somativas.

📝 Avaliação Somativa

A avaliação somativa verifica o domínio das competências desenvolvidas na disciplina e é composta por provas e entregas do Projeto Integrador.

1º GQ (Peso 2)

2º GQ (Peso 3)

🎯 Critérios de Aprovação

  • Aprovação direta: Média ≥ 7,0
  • Direito ao Exame Final: 3,0 ≤ Média < 7,0
  • Aprovação após o Exame Final: Média Final ≥ 5,0

Cálculo da Média Final:

Média = (1º GQ × 2 + 2º GQ × 3) ÷ 5

📌 Frequência

A frequência mínima obrigatória é de 75% da carga horária da disciplina. A frequência inferior a esse percentual implica reprovação por falta, independentemente da média obtida.

Trilha de Aprendizagem

A progressão da disciplina, do conceito à defesa técnica

Cada etapa da trilha prepara você para a próxima. Não existe atalho — existe progressão.

Fundamentos de Processos

Modelos de processo, ciclo de vida do software

Scrum

Papéis, eventos, artefatos e framework ágil

Histórias de Usuário

Escrita, critérios de aceitação e qualidade

Product Backlog

Priorização, refinamento e gestão

Sprint

Planning, execução, Review e Retrospectiva

Engenharia de Requisitos

Elicitação, documentação e validação de requisitos

Requisitos Não Funcionais

Classificação, categorias e especificação de RNFs

Arquitetura

Decisões arquiteturais motivadas pelos RNFs

Métricas Ágeis

Velocity, burndown e melhoria contínua

Gestão de Mudanças

Rastreabilidade e análise de impacto

Projeto Integrador

Aplicação integrada de todos os conceitos

Defesa Técnica

Apresentação, justificativa e argumentação profissional

Cronograma da Disciplina

Acompanhe o planejamento completo das aulas, incluindo datas de avaliações e feriados.

Carga horária: 60h presenciais (4 créditos) | Aulas de 2h (09:20–11:00)

📘 Macro-Módulo I – Fundamentos de Processos de Software

📗 Macro-Módulo II – Requisitos em Ambiente Ágil

📙 Macro-Módulo III – Engenharia de Requisitos (Parte 1)

📙 Macro-Módulo III – Engenharia de Requisitos (Parte 2)

📕 Macro-Módulo IV – Qualidade, Métricas e Arquitetura

🏁 Macro-Módulo V – Projeto Integrador – LAER

O Projeto Integrador Acompanha Toda a Disciplina

Cada conteúdo estudado será imediatamente aplicado ao projeto.

Módulo I – Fundamentos

Você entende como o software é desenvolvido e por que o Scrum é o framework central da disciplina.

Módulo II – Requisitos em Ambiente Ágil

Você define o produto, escreve as primeiras histórias de usuário e monta o backlog inicial do projeto.

Módulo III – Engenharia de Requisitos

Você aprofunda os requisitos, identifica RNFs e garante rastreabilidade entre as decisões do projeto.

Módulo IV – Qualidade e Métricas

Você executa sprints, coleta métricas, analisa desempenho e documenta mudanças de requisito.

Módulo V – Defesa Técnica

Você apresenta o projeto completo, justifica cada decisão e demonstra domínio técnico e profissional.

Projeto Integrador

Laboratório de Engenharia de Requisitos – LAER

Objetivo

Desenvolver um projeto ágil completo, partindo da definição do produto e backlog inicial até a defesa técnica final, aplicando os conhecimentos construídos ao longo da disciplina.

Cada entrega do Projeto Integrador corresponde aos conteúdos estudados até aquele momento da disciplina, permitindo a aplicação incremental dos conceitos e a evolução contínua do projeto.

1º GQ

Entrega 1 – Backlog Inicial

Entrega: 28/09/2026 (Revisão 1º GQ)

Entregáveis:

  • Definição do produto e problema a resolver
  • Personas e stakeholders identificados
  • Product Backlog com mínimo de 15 histórias de usuário
  • Critérios de aceitação para cada história
  • Priorização inicial (MoSCoW ou similar)
  • Justificativa técnica das decisões (1 a 2 páginas)

Valor: 2,0 pontos

Entrega 2 – Sprint 1

Entrega: 01/10/2026 (1º GQ)

Entregáveis:

  • Sprint Planning documentado
  • Sprint Backlog com histórias selecionadas
  • Definição de Pronto (DoD)
  • Registro de execução da Sprint
  • Sprint Review e Retrospectiva documentados
  • Métricas da Sprint (velocity, burndown)

Valor: 3,0 pontos

Entrega 3 – Gestão de Mudança

Entrega: 01/10/2026 (1º GQ)

Entregáveis:

  • Registro de pelo menos uma mudança de requisito ocorrida
  • Análise de impacto da mudança
  • Atualização do backlog e rastreabilidade
  • Justificativa da decisão tomada

Valor: 1,0 ponto (compõe o 1º GQ)

Composição do 1º GQ: Prova Objetiva: 4,0 pts | Backlog Inicial: 2,0 pts | Sprint 1: 3,0 pts | Gestão de Mudança: 1,0 pt

2º GQ

Entrega 4 – Requisitos Não Funcionais e Arquitetura

Entrega: 19/10/2026 (Aula 15)

Entregáveis:

  • Levantamento de requisitos não funcionais (RNF)
  • Classificação por categoria (desempenho, segurança, usabilidade, etc.)
  • Decisões arquiteturais motivadas pelos RNFs
  • Rastreabilidade entre RNFs e histórias de usuário

Valor: 2,0 pontos

Entrega 5 – Métricas e Análise de Desempenho

Entrega: 16/11/2026 (Aula 22)

Entregáveis:

  • Métricas coletadas ao longo das sprints
  • Análise de velocity e burndown
  • Identificação de gargalos e melhorias aplicadas
  • Relatório de qualidade do processo

Valor: 2,0 pontos

Entrega 6 – Defesa Técnica Final

Data: 23/11/2026 (Aula 24)

Entregáveis:

  • Apresentação de 10 a 15 minutos
  • Demonstração do backlog e sprints realizadas
  • Explicação das decisões de requisitos e arquitetura
  • Apresentação das métricas e análise de desempenho
  • Respostas aos questionamentos da banca

Valor: 2,0 pontos

Composição do 2º GQ: Prova Objetiva: 4,0 pts | RNF e Arquitetura: 2,0 pts | Métricas e Desempenho: 2,0 pts | Defesa Técnica Final: 2,0 pts

Formação de Grupos - Projeto Integrador

Orientações para organização e registro dos grupos

Tamanho dos Grupos

  • Mínimo: 2 estudantes
  • Máximo: 4 estudantes
  • Recomendado: 3 integrantes (equilíbrio ideal)

Justificativa: 2 → risco de sobrecarga | 4 → risco de assimetria | 3 → melhor divisão técnica

Modalidade de Formação

  • Formação livre até 28/08/2026
  • Após essa data, o professor poderá realocar estudantes sem grupo

Composição Estratégica (Recomendação)

Sugere-se que o grupo tenha perfis complementares:

  • 1 perfil analítico (requisitos e backlog)
  • 1 perfil estruturador (processos e documentação)
  • 1 perfil técnico (métricas e arquitetura)
  • 1 perfil comunicador (defesa técnica)

⚠️ Não é obrigatório, mas melhora desempenho.

Registro Oficial do Grupo

Até 28/08/2026, cada grupo deve enviar:

  • Nome do projeto
  • Integrantes
  • Produto/domínio escolhido
  • Justificativa do domínio (1 parágrafo)

Sem registro formal → grupo não validado.

Troca ou Saída de Integrante

  • Permitida apenas até 28/09/2026 (Entrega do Backlog Inicial)
  • Após essa data: mudanças somente com justificativa formal
  • Reorganização pode implicar redefinição de tarefas

Situações Especiais

  • Aluno sem grupo após prazo: Será alocado em grupo existente ou desenvolverá projeto individual (com complexidade reduzida).
  • Conflitos internos: Comunicação formal ao professor. Avaliação individual pode ser aplicada.

Checklist do Projeto Integrador

Verifique todos os requisitos antes de cada entrega

ENTREGA 1 – BACKLOG INICIAL (28/09/2026)

  • ☐ Produto e problema claramente definidos
  • ☐ Personas e stakeholders identificados
  • ☐ Mínimo de 15 histórias de usuário no backlog
  • ☐ Critérios de aceitação escritos para cada história
  • ☐ Priorização realizada (MoSCoW ou similar)
  • ☐ Justificativa técnica das decisões (1 a 2 páginas)

ENTREGA 2 – SPRINT 1 (01/10/2026)

  • ☐ Sprint Planning documentado
  • ☐ Sprint Backlog com histórias selecionadas
  • ☐ Definição de Pronto (DoD) estabelecida
  • ☐ Registro de execução da Sprint
  • ☐ Sprint Review e Retrospectiva documentados
  • ☐ Métricas da Sprint (velocity, burndown)

ENTREGA 3 – GESTÃO DE MUDANÇA (01/10/2026)

  • ☐ Pelo menos uma mudança de requisito registrada
  • ☐ Análise de impacto documentada
  • ☐ Backlog atualizado com rastreabilidade
  • ☐ Justificativa da decisão tomada

ENTREGA 4 – RNF E ARQUITETURA (19/10/2026)

  • ☐ Requisitos não funcionais levantados e classificados
  • ☐ Categorias cobertas (desempenho, segurança, usabilidade)
  • ☐ Decisões arquiteturais motivadas pelos RNFs
  • ☐ Rastreabilidade entre RNFs e histórias de usuário

ENTREGA 5 – MÉTRICAS E DESEMPENHO (16/11/2026)

  • ☐ Métricas coletadas ao longo das sprints
  • ☐ Análise de velocity e burndown apresentada
  • ☐ Gargalos identificados e melhorias aplicadas
  • ☐ Relatório de qualidade do processo entregue

ENTREGA 6 – DEFESA TÉCNICA FINAL (23/11/2026)

  • ☐ Apresentação de 10 a 15 minutos preparada
  • ☐ Backlog e sprints demonstrados com clareza
  • ☐ Decisões de requisitos e arquitetura justificadas
  • ☐ Métricas e análise de desempenho apresentadas
  • ☐ Segurança técnica nas respostas à banca

Linha do Tempo do Projeto

Acompanhe visualmente a evolução do seu projeto

1

28/08/2026 – Lançamento do Projeto

Início oficial do Projeto Integrador. Formação de grupos e escolha do produto/domínio.

2

28/08/2026 – Registro dos Grupos

Envio oficial do nome do grupo, integrantes, produto/domínio escolhido e justificativa.

3

28/09/2026 – Entrega 1: Backlog Inicial

Product Backlog com mínimo de 15 histórias de usuário, critérios de aceitação e priorização.

4

01/10/2026 – Entrega 2: Sprint 1 + Gestão de Mudança

Sprint Planning, execução, Review, Retrospectiva, métricas e registro de mudança de requisito.

5

19/10/2026 – Entrega 3: RNF e Arquitetura

Requisitos não funcionais classificados e decisões arquiteturais motivadas com rastreabilidade.

6

16/11/2026 – Entrega 4: Métricas e Desempenho

Análise de velocity, burndown, gargalos identificados e relatório de qualidade do processo.

7

23/11/2026 – Defesa Técnica Final

Apresentação oral de 10 a 15 minutos com demonstração do backlog, sprints, métricas e decisões técnicas.

8

14/12/2026 – Exame Final (se necessário)

Prova discursiva abrangendo todo o conteúdo da disciplina (Aulas 01 a 24).

Políticas da Disciplina

Regras, prazos e conduta acadêmica

Frequência

  • Frequência mínima: conforme regimento institucional
  • Atrasos superiores a 15 minutos podem ser considerados ausência

Entregas

  • Entregas fora do prazo sofrem desconto progressivo
  • Trabalhos copiados ou plagiados recebem nota zero
  • Documentos devem estar completos e identificados com o nome do grupo

Avaliações (GQ)

  • No dia do GQ haverá obrigatoriamente prova objetiva
  • 1º GQ vale 10 pontos (peso 2)
  • Prova objetiva do 1º GQ vale 4,0 pontos
  • Projeto Integrador vale 6,0 pontos no 1º GQ (Backlog Inicial: 2,0 | Sprint 1: 3,0 | Gestão de Mudança: 1,0)
  • 2º GQ vale 10 pontos (peso 3)
  • Prova objetiva do 2º GQ vale 4,0 pontos
  • Projeto Integrador vale 6,0 pontos no 2º GQ (RNF e Arquitetura: 2,0 | Métricas e Desempenho: 2,0 | Defesa Técnica Final: 2,0)
  • 2ª chamada: não é necessário apresentar atestado ou justificativa
  • As notas do Projeto Integrador compõem a nota do respectivo GQ, conforme definido no Sistema de Avaliação.

Conduta Acadêmica

  • Uso de IA é permitido como apoio, mas o estudante deve compreender e defender tecnicamente o que entregou
  • Na defesa, o aluno deve saber explicar todas as decisões técnicas
  • Integridade acadêmica é fundamental

Política de Atraso - Projeto Integrador

Cada etapa possui data oficial. Entregas devem ocorrer até 23h59 do dia estipulado na plataforma institucional. Arquivos devem estar executáveis e identificados com nome do grupo.

Tabela de Penalidade

Regras Complementares

  • Atraso na Entrega 4 (Métricas e Desempenho) compromete a Defesa Técnica Final
  • Não há prorrogação automática
  • Casos excepcionais seguem regimento institucional
  • Entregas parciais incompletas não garantem pontuação integral
  • Ausência na defesa implica nota zero no projeto
  • Membro que não souber explicar o projeto pode ter avaliação individual reduzida

Recursos Complementares

Materiais adicionais para aprofundar seu aprendizado

📋 Gestão Ágil e Backlog

🗺️ Diagramas e Modelagem

📝 Documentação e Colaboração

Dicas de Estudo

Orientação estratégica para maximizar seu aprendizado

Não decore, compreenda o processo

Processos ágeis são lógica aplicada. Se você entende por que o Scrum funciona, não precisa decorar os eventos — você os reconstrói naturalmente.

Sempre pense em rastreabilidade

Antes de escrever uma história de usuário, pergunte: Quem precisa disso? Por quê? Como saberei que está pronto? Esses são os pilares de um requisito de qualidade.

Para requisitos com qualidade

Treine: escrever critérios de aceitação claros, identificar requisitos não funcionais implícitos, e distinguir o que é requisito do que é solução técnica.

Para o Projeto Integrador

O erro mais comum é: "Backlog bonito, mas sem critérios de aceitação." A defesa técnica exige que você justifique cada decisão de requisito e processo.

Para o 2º GQ

O que costuma diferenciar nota 7 de nota 9: entender métricas ágeis na prática, saber justificar decisões arquiteturais com base em RNFs, e apresentar a retrospectiva com aprendizados reais.

Como Estudar Esta Disciplina

Um roteiro para cada aula

Seguir um roteiro consistente por aula é a forma mais eficiente de consolidar o aprendizado progressivo desta disciplina.

Leia os Slides

Antes da aula, revise os slides disponíveis no material. Identifique os conceitos centrais e anote dúvidas.

Resolva a Lista de Exercícios

Após a aula, resolva a lista correspondente. Não avance sem entender os exercícios anteriores.

Faça a Autoavaliação

Verifique se consegue explicar os conceitos com suas próprias palavras. Se não conseguir, revise.

Atualize o Projeto Integrador

Aplique o conteúdo da aula ao seu projeto. Cada aula tem uma contribuição direta ao backlog, às sprints ou à documentação de requisitos que você está construindo.

Tire Dúvidas

Não acumule dúvidas. Procure o professor, monitores ou colegas antes da próxima aula.

Antes da Prova

Checklist de preparação

Use este checklist para verificar se você está pronto para cada avaliação. Só avance quando conseguir marcar todos os itens com confiança.

📘 1º GQ – Fundamentos, Scrum e Requisitos Ágeis

Fundamentos e Scrum

  • Sei explicar os modelos de processo de software (Cascata, Ágil)
  • Sei descrever o ciclo de vida do software
  • Sei identificar os papéis do Scrum (PO, SM, Dev Team)
  • Sei descrever os eventos do Scrum (Sprint, Planning, Review, Retro)
  • Sei explicar os artefatos do Scrum (Backlog, Sprint Backlog, Incremento)
  • Sei diferenciar processo preditivo de processo ágil
  • Sei justificar quando usar Scrum vs outros modelos

Requisitos e Backlog

  • Sei escrever histórias de usuário no formato correto
  • Sei definir critérios de aceitação claros e testáveis
  • Sei distinguir requisitos funcionais de não funcionais
  • Sei priorizar um backlog usando MoSCoW ou similar
  • Sei identificar e documentar RNFs por categoria
  • Sei rastrear requisitos ao longo do projeto
  • Sei aplicar técnicas de elicitação de requisitos

📕 2º GQ – Métricas, Arquitetura e Defesa

Métricas, Arquitetura e Defesa

  • Sei calcular e interpretar velocity de uma sprint
  • Sei analisar um burndown chart
  • Sei identificar gargalos e propor melhorias
  • Sei relacionar RNFs a decisões arquiteturais
  • Sei documentar e justificar mudanças de requisito
  • Sei apresentar o projeto com segurança técnica
  • Sei responder perguntas sobre qualquer decisão do projeto

Erros Comuns na Disciplina

Aprenda com os erros mais frequentes e evite-os

Ao longo dos anos, alguns erros se repetem entre os estudantes. Conhecê-los antecipadamente pode economizar tempo e melhorar significativamente seu desempenho.

Erros Comuns em Requisitos e Backlog

Escrever histórias de usuário sem critérios de aceitação

Uma história sem critério de aceitação é incompleta. Sem saber o que significa 'pronto', a equipe não sabe quando terminou.

Confundir requisito com solução técnica

Requisito descreve o que o sistema deve fazer, não como. 'O sistema deve usar banco PostgreSQL' é uma decisão técnica, não um requisito.

Ignorar requisitos não funcionais

RNFs como desempenho, segurança e usabilidade são tão importantes quanto os funcionais. Ignorá-los gera problemas arquiteturais sérios.

Erros Comuns no Processo Ágil

Fazer Sprint Planning sem backlog priorizado

Sem priorização clara, a equipe seleciona histórias aleatoriamente. O resultado é uma sprint sem foco e sem valor entregue.

Pular a Retrospectiva por falta de tempo

A Retrospectiva é onde o processo melhora. Equipes que a pulam repetem os mesmos erros sprint após sprint.

Tratar o Scrum como processo burocrático

Scrum é um framework leve. Se parece pesado, algo está errado. Os eventos existem para gerar valor, não para cumprir protocolo.

Erros Comuns na Defesa Técnica

Não saber justificar as decisões do projeto

Na defesa, qualquer membro pode ser questionado sobre qualquer decisão. 'O grupo decidiu assim' não é uma justificativa técnica.

Apresentar backlog sem rastreabilidade

Histórias sem critérios, sem priorização justificada e sem vínculo com o produto demonstram falta de domínio do processo.

Confundir métricas com resultados

Velocity alta não significa qualidade. Saiba interpretar as métricas no contexto do projeto, não apenas apresentar os números.

Deixar a defesa para o último momento

A defesa é a síntese de todo o semestre. Quem pratica a apresentação com antecedência demonstra maturidade profissional.

O que Diferencia Nota 10?

Critérios de excelência que elevam seu projeto

A diferença entre um projeto bom (nota 7-8) e um projeto excelente (nota 9-10) está nos detalhes. Aqui estão os critérios que realmente fazem a diferença.

Em Requisitos e Backlog

Backlog enxuto e bem priorizado

Não crie histórias desnecessárias. Um backlog focado, com priorização justificada e critérios de aceitação claros, vale mais que um backlog extenso e vago.

Critérios de aceitação precisos e testáveis

Não escreva critérios genéricos. Explique exatamente o que o sistema deve fazer para que a história seja considerada pronta. Isso demonstra maturidade técnica.

Rastreabilidade consistente e profissional

Mantenha vínculos claros entre personas, histórias, RNFs e decisões arquiteturais. Rastreabilidade mostra domínio do processo.

Em Processo Ágil

01

Sprints com planejamento e retrospectiva documentados

Mostre que o processo foi seguido com intenção. Planning com metas claras e Retrospectiva com aprendizados reais demonstram maturidade ágil.

02

Métricas interpretadas com contexto

Não apenas apresente velocity e burndown. Explique o que os dados significam para o projeto e quais decisões foram tomadas a partir deles.

Em RNFs e Arquitetura

RNFs classificados e vinculados ao produto

Não liste RNFs genéricos. Mostre como cada requisito não funcional impacta diretamente o produto e as decisões arquiteturais tomadas.

Decisões arquiteturais justificadas

Não escolha uma arquitetura porque 'parece certa'. Explique por que ela atende aos RNFs identificados. A justificativa mostra profissionalismo.

Gestão de mudança documentada

Projetos nota 10 registram mudanças de requisito com análise de impacto. Isso demonstra controle real do processo.

Na Defesa Técnica

Segurança nas respostas

Responda com confiança, mas admita quando não souber. Honestidade técnica é valorizada.

Capacidade de justificar decisões

"Por que você priorizou essa história?" "Por que esse RNF impacta a arquitetura?" Tenha respostas prontas e fundamentadas.

Demonstração prática do projeto

Mostre o backlog organizado, as sprints executadas e as métricas ao vivo. Isso impressiona e valida seu trabalho.

Competências Desenvolvidas ao Final da Disciplina

Ao concluir a disciplina, o estudante estará apto a:

1

Compreender processos modernos de desenvolvimento de software

2

Elicitar, documentar e validar requisitos funcionais e não funcionais

3

Aplicar Scrum em projetos reais com papéis, eventos e artefatos bem definidos

4

Construir e gerenciar Product Backlogs com histórias de usuário de qualidade

5

Especificar requisitos não funcionais e tomar decisões arquiteturais fundamentadas

6

Utilizar métricas ágeis para apoiar decisões e melhorar continuamente o processo

7

Analisar e documentar impactos de mudanças de requisitos com rastreabilidade

8

Justificar decisões técnicas de forma fundamentada e profissional

9

Comunicar e defender soluções de software com postura técnica, argumentação fundamentada e segurança na apresentação oral.