Professor: Gabriel Soares Baptista
Quando alguém diz:
isso ainda não basta para implementar o software corretamente.
Frase analisada:
Essa frase já permite que a equipe desenvolva e teste o sistema sem ambiguidades?
Não.
Ela expressa uma necessidade real, mas ainda não define com precisão:
Segundo Sommerville, requisitos são descrições:
Engenharia de Requisitos é o processo de:
essas descrições.
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]Requisitos de usuário:
alto nível
linguagem de negócio
voltados a clientes e usuários finais
Requisitos de sistema:
mais detalhados
mais técnicos
usados por arquitetos, programadores e testadores
Requisito de sistema é mais técnico e detalhado que requisito de usuário.
Mas ele ainda não deve definir a tecnologia da solução.
Ou seja, normalmente ele não diz:
Isso é, em geral, decisão de projeto.
Requisito de usuário
O sistema deve permitir ao coordenador visualizar faltas por turma.
Requisito de sistema
O sistema deve retornar a lista de faltas de uma turma em até 2 segundos após a seleção da turma.
Considere as afirmações:
Qual está correta?
Resposta: B
Descrevem o que o sistema faz.
Exemplos:
Descrevem como o sistema deve se comportar ou sob quais restrições deve operar.
Exemplos:
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]| Tipo | Exemplo |
|---|---|
| Funcional | O sistema deve permitir solicitar matrícula. |
| Não funcional | O sistema deve responder em até 2 segundos. |
| Produto | O sistema deve suportar 500 acessos simultâneos. |
| Organizacional | O sistema deve usar autenticação institucional. |
| Externo | O sistema deve cumprir a LGPD. |
Quais as classificações dos seguintes requisitos:
Classificação
Classifique quanto ao tipo do requisito não funcional:
Resposta comentada
| Propriedade | Medida possível |
|---|---|
| Velocidade | transações por segundo, tempo de resposta |
| Tamanho | megabytes, uso de memória |
| Facilidade de uso | tempo de treinamento, erros por hora |
| Confiabilidade | tempo médio para falha, taxa de falhas |
| Robustez | tempo de reinício, perda de dados após falha |
| Portabilidade | número de plataformas suportadas |
Esses requisitos são vagos.
Melhor:
O SRS é a declaração formal do que deve ser implementado.
Ele serve para:
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]Quatro atividades centrais:
Além disso, o gerenciamento de requisitos acompanha mudanças ao longo do tempo.
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 --> EObjetivo:
Dificuldades típicas:
| Técnica | Melhor uso |
|---|---|
| Entrevistas | captar objetivos, dores e expectativas |
| Cenários | mostrar fluxos concretos de uso |
| Casos de uso | modelar interação entre atores e sistema |
| Etnografia | observar o trabalho real e descobrir exceções do cotidiano |
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]Em uma organização, o processo oficial afirma que todo atendimento deve ser registrado ao final da consulta.
Na prática, alguns profissionais registram parte das informações antes do término para ganhar tempo.
Qual técnica tem maior chance de descobrir esse comportamento real?
Resposta: C) Etnografia
Ela observa o trabalho real no ambiente, revelando diferenças entre processo oficial e prática cotidiana.
Verifica se os requisitos são:
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]Elas não eliminam todos os problemas, mas reduzem ambiguidades e retrabalho antes do projeto e da implementação.
Assinale a alternativa correta sobre validação de requisitos:
Resposta: B
Validação de requisitos atua sobre o próprio conjunto de requisitos, antes da implementação completa.
Os requisitos mudam porque:
Então, é preciso:
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]Uma pequena mudança em um requisito pode afetar arquitetura, código, testes, cronograma e custo.
O processo responsável por acompanhar essas alterações, avaliar seu impacto e manter rastreabilidade é chamado de:
O MHC-PMS mostra bem a importância da Engenharia de Requisitos.
Objetivos principais:
Funcionais
Não funcionais
No MHC-PMS:
O trabalho da Engenharia de Requisitos é tornar esse conflito explícito e negociável.