<

1 />

Requisitos e
Métricas de
Software//
Prof. Vinícius Siqueira

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 <
2 />

Bibliografia básica
PRESSMAN, Roger S.. Engenharia de Software. 9a ed. McGraw Hill.

Desenvolvimento
Ágil de Software

Acesse o Livro

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Desenvolvimento Ágil de
Software
É uma abordagem em que softwares são desenvolvidos de forma colaborativa, com equipes
multidisciplinares que têm um bom nível de autonomia na execução de seus trabalhos.

Os princípios de desenvolvimento priorizam a entrega mais do que a análise e o projeto,

também priorizam a comunicação ativa e contínua entre desenvolvedores e clientes.

NÃO significa que nenhum documento é criado, e SIM, que apenas os documentos que vão
ser consultados mais adiante no processo de desenvolvimento são criados.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 <
4 />

2001 - Manifesto Ágil

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Manifesto Ágil
Um manifesto normalmente é associado a um movimento político emergente:
ataca a velha guarda e sugere uma mudança revolucionária (espera-se que para
melhor). De certa forma, é exatamente disso que trata o desenvolvimento ágil.

O desenvolvimento ágil oferece benefícios importantes; no entanto, não é

indicado para todos os projetos, produtos, pessoas e situações.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Talvez
Afinal,
o que é
AGILIDADE?
Satisfazer o cliente com entrega adiantada e contínua.

Talvez
Aceite os pedidos de alterações mesmo com o projeto
adiantado.

Entrega de software em funcionamento

frequentemente.

O comercial e os desenvolvedores devem trabalhar em

conjunto

Construa projetos em torno de pessoas motivadas.

Métodos mais efetivos e eficientes de transmitir informações.

Software em funcionamento é a principal medida de progresso.

Simplicidade, arte de maximizar o volume de trabalho não realizado Os processos ágeis promovem um desenvolvimento sustentável.

Em intervalos regulares, a equipe se avalia para ver como pode ficar

Atenção contínua para com a excelência técnica e para com bons
mais eficiente.
projetos aumenta a agilidade.

As melhores arquiteturas, requisitos e projetos surgem de equipes

organizadas e ágeis.
Não cometa o erro de supor
que a agilidade lhe dará licença
para abreviar soluções. Processo
é um requisito, e disciplina é
essencial.
 Modelo Ágil
É um modelo e uma filosofia que propõe alternativas à gestão de projetos
tradicional e tem a função de aprimorar o processo de desenvolvimento de um
produto ou serviço.

Ex.:
XP Scrum BDD

FDD TDD Lean

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo Ágil
Utiliza uma abordagem de planejamento incremental e muito iterativa.

Cada iteração é um mini-projeto, que normalmente dura de 1 a 4 semanas, e inclui todas as fases para
implementá-lo como levantamento de recursos e requisitos, projeto, desenvolvimento de código, testes
e documentação.

Ao final de cada iteração deve haver uma entrega ao cliente, que inclua um conjunto e novas
funcionalidades, uma nova versão do software.

Após essa entrega há um novo processo de comunicação com o cliente e então são definidas quais
deverão ser as novas entregas.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 XP – Extreme Programming
É uma metodologia focada no desenvolvimento de software que possui valores e princípios, onde são
fundamentados por um conjunto de práticas.

É uma metodologia leve que pode facilmente ser adotada por diferentes níveis de desenvolvedores
(experientes ou não) e em qualquer tamanho de equipe.

O XP pode ser utilizado de forma complementar ao Scrum, pois ele acaba focando mais em processos
de engenharia e desenvolvimento de software.

Tem como princípio o feedback rápido, a simplicidade, a ideia de abraçar mudanças, fazer um trabalho
de qualidade e aceitar mudanças incrementais.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo XP - Planejamento

A atividade de planejamento se inicia com ouvir – uma atividade de

levantamento de requisitos que capacita os membros técnicos da equipe.

A atividade de ouvir conduz à criação de um conjunto de “histórias”

(também denominadas histórias de usuários) que descreve o resultado, as
características e a funcionalidade solicitados para o software a ser
construído.

Cada história é escrita pelo cliente e é colocada e uma ficha, o cliente

atribui um valor à historia, ou seja, uma prioridade.

Os membros avaliam cada história e atribuem um custo, medido em

semanas.

Caso a estimativa exceda 3 semanas de desenvolvimento é solicitado que

o cliente divida em histórias menores.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo XP - Planejamento

(1) todas serão implementadas imediatamente (em um prazo de poucas

semanas).

(2) as histórias de maior valor serão deslocadas para cima no cronograma

e implementadas primeiro

(3) as histórias de maior risco serão deslocadas para cima no cronograma

e implementadas primeiro.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo XP - Projeto

O projeto XP segue rigorosamente o princípio KISS (keep it simple, stupid!,

ou seja, não complique!).

É sempre preferível um projeto simples a uma representação mais

complexa.

Se for encontrado um problema de projeto difícil, como parte do projeto

de uma história, a XP recomenda a criação imediata de um protótipo
operacional dessa parte do projeto. Denominada solução pontual com o
objetivo de reduzir o risco na história contendo o problema de projeto.

É recomendado a refatoração, uma técnica que altera um sistema de

software de modo que o comportamento do código não se altere.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo XP - Codificação

Depois de escrita as histórias e de o trabalho preliminar ter sido feita a

equipe não só cria os testes de unidade, como também, inicia-se o
desenvolvimento.

A equipe de desenvolvimento foca melhor no que deve ser

implementado para ser aprovado no teste.

A medida que a equipe de desenvolvimento conclui as histórias, o código

é integrado ao trabalho de outros.

A estratégia de “integração contínua” ajuda a evitar problemas de

compatibilidade e de interface.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo XP - Testes

Os testes de unidades criados devem ser implementados usando-se uma

metodologia que os capacite a ser automatizados, estimulando uma
estratégia de testes de regressão toda vez que o código sofrer alteração.

Os teste de integração, podem ocorrer diariamente, dando a equipe uma

indicação contínua do progresso e também alertas.

A medida que a equipe de desenvolvimento conclui as histórias, o código

é integrado ao trabalho de outros.

Os testes de aceitação são obtidos de histórias de usuários

implementadas como parte de uma versão do software.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 FDD – Feature Driven Development

É uma metodologia de análise orientada a objetos focado no estudo de problemas com fundamentos
baseados em conceitos palpáveis e utilizando processos interativos para entendimento do contexto que
será analisado.

Uma das características dessa abordagem é realizar a apresentação de todo um conjunto de features em
um período de tempo fixo.

Essa orientação para resultados parciais em curtos espaços de tempo torna o modelo bastante atrativo.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo FDD – Boas Práticas
Modelagem orientada a objetos de domínio: a modelagem deve ser básica, apenas
algo ilustrativo para os envolvidos no projeto;

Desenvolvimento por feature: implementação orientada por funcionalidade;

Código proprietário: o código deve ser realizado apenas por um desenvolvedor, ou

seja, iniciado e terminado pelo mesmo desenvolvedor.

Equipe: equipe destinada a desenvolver funcionalidades necessárias ao projeto;

Inspeções: deve ser realizado o code review, para garantir que o que está sendo
enviado para o ambiente de uso não resultará em bugs e problemas futuros;

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo FDD – Progresso da Equipe
Medir o desempenho da equipe é importante para que o método seja aplicado com
eficácia, além de favorecer a gestão da corporação.

A medição de progresso deve ocorrer a partir de cada item que foi estipulado no início
do planejamento.

O nível de esforço e de prioridade dos features devem ser previamente definidos, e

também serão critérios de avaliação.

Follow Ups diários e/ou semanais devem ser realizados para entender melhor o
progresso do time.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo FDD – Documentação
A estrutura segue o seguinte padrão: <ação> <resulta em> <objeto>

Feature Principal: Gerenciamento de senhas

Conjunto de Features:
1. Verificar quantidade de caracteres
2. Verificar se a senha possui letra maiúscula
3. Verificar se a senha possui letra minúscula
4. Verificar se a senha possui números
5. Verificar se a senha possui caracteres especiais

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Scrum

É um método de desenvolvimento ágil concebido por Jeff e sua equipe nos anos 90.

Os princípios do Scrum são coerentes com o manifesto ágil e são usados para orientar as atividades de
desenvolvimento dentro de um processo que incorpora as seguintes atividades metodológicas:
requisitos, análise, projeto, evolução e entrega.

O Scrum enfatiza o uso de um conjunto de padrões de processos que provaram ser eficazes para
projetos com prazos de entrega apertados, requisitos mutáveis e urgência do negócio.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo Scrum – Padrões de Processos

Backlog, uma lista com prioridades dos requisitos ou funcionalidades do

projeto que fornecem valor comercial ao cliente.

Sprints, consistem em unidades de trabalho solicitadas para atingir um

requisito estabelecido no registro de trabalho (backlog) e que precisa ser
ajustado dentro de um prazo já fechado ( janela de tempo)10 (tipicamente
30 dias).
Reuniões Scrum, são reuniões curtas (tipicamente 15 minutos)

Scrum master, conduz a reunião e avalia as respostas de cada integrante.

Demos, entrega do incremento de software ao cliente para que a

funcionalidade implementada seja demonstrada e avaliada.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo Scrum – Papeis

Product Owner, também conhecido como PO, ele é o dono do produto, é

responsável por todas as melhorias e negociaçoes que envolvem o
produto..

Scrum Master, responsável por difundir os valores do Scrum e suas

práticas, é parte do time e divide responsabilidades com outros membros,
conduzindo a reunião diária e avaliando a resposta de cada
integrante. Protege o time contra interferências externas.

Developers, são engenheiros, mas nem sempre é esse o caso. Muitas

vezes composta por todos os tipos de pessoas, incluindo
desenvolvedores, redatores, equipe de teste, UX, entre outros. Tem por
objetivo se auto organizarem para conseguir tomar decisões e também
entregar a demanda necessária dentro da sprint.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 TDD – Test Driven Development

Desenvolvimento orientado a teste é parte da metodologia XP e utilizado junto com outras

metodologias.

O que você tem a perder utilizando o TDD? NADA. Nesse método é escrito os testes antes
de implementar o sistema.

Facilita o entendimento da equipe em relação ao projeto que se deseja em relação ao

código.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo TDD – Ciclo

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 BDD – Behaviour Driven
Development
Desenvolvimento Orientado por Comportamento, ou seja, é necessário definir os
comportamentos esperados das funcionalidades de acordo com cada cenário identificado.

É uma técnica interessante pois simultaneamente representa a documentação e os critérios

de aceite da funcionalidade

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Modelo BDD - Estrutura

História do usuário: descrição simples e curta de uma funcionalidade na

perspectiva do usuário.

Funcionalidade: comportamento ou ação que o sistema oferece ao seu

usuário baseada em uma entrada e uma saída

Cenário: descreve o conjunto ordenado de comportamentos

baseado em uma entrada para alcançar um resultado específico de
uma funcionalidade

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

Modelo BDD - Exemplo

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Lean

É uma metodologia que visa zerar desperdícios, diminuir custos e aumentar a produtividade
dentro de uma empresa.

Aliado ao uso de tecnologia, esse método fornece os meios para uma gestão ENXUTA
garantindo uma entrega de máxima qualidade para o cliente final.

A metodologia segue: processos otimizados, menos custos e melhor entrega ao consumidor

final

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
 Requisitos e Métricas de Software

Agora é com vocês

Utilize os métodos no trabalho.

1. Escreva histórias de uma funcionalidade simples. (XP)

2. Identifique e liste características de uma funcionalidade simples. (FDD)
3. Realizar reunião diária fictícia do progresso e quais próximos passos do trabalho. (Scrum)
4. Escreva testes de uma funcionalidade simples. (TDD)
5. Descreva 5 cenários esperado de uma funcionalidade simples. (BDD)
6. Identifique e elimine desperdícios em um processo fictício de desenvolvimento de software. (Lean)

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 <
32 />

Bibliografia básica
PRESSMAN, Roger S.. Engenharia de Software. 9a ed. McGraw Hill.

Engenharia
de Requisitos

Acesse o Livro

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Engenharia de Requisitos
É o processo de levantar, analisar, documentar, gerenciar e controlar a qualidade dos
requisitos.

Requisitos são descrições dos serviços que devem ser providos pelo sistema e de suas restrições operaci
onais (SOMMERVILLE, 2007).

Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar
para atingir seus objetivos (PFLEEGER, 2004).

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Engenharia de Requisitos
Um requisito é alguma coisa que o produto tem de fazer ou uma qualidade que ele precisa
apresentar (ROBERTSON; ROBERTSON,2006).

Os requisitos de um sistema definem o que o sistema deve fazer e as circunstâncias sob as quais
deve operar. Em outras palavras: São as funções que um sistema deve incorporar e as
restrições que devem ser satisfeitas.

Uma das princiapais medidas do sucesso de um sistema de software é o grau no qual ele atende
aos requisitos para os quais foi construído.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Importância da Engenharia de
Requisitos
1. Conhecer os requisitos relevantes
2. Estabelecer consenso entre os stakeholders
3. Documentar os requisitos de acordo com determinados padrões
4. Gerenciar os requisitos de forma sistemática
5. Compreender e documentar as necessidades dos stakeholders
6. Especificar e gerenciar os requisitos para minimizar riscos para não entregar um sistema
que não atenda as expectativas e necessidades do usuário

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Envolvidos
Os requisitos devem ser redigidos de modo a serem passíveis de entendimento pelos
diversos interessados, chamados de STAKEHOLDERS.

Clientes, usuários finais e desenvolvedores, são todos interessados em requisitos,

porém, com expectativas diferentes. Enquanto desenvolvedores e usuários finais têm
interesse em detalhes técnicos, clientes requerem descrições mais abstratas.

Assim, é útil apresentar requisitos em diferentes níveis de descrição.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 <
37 />

Bibliografia básica
PRESSMAN, Roger S.. Engenharia de Software. 9a ed. McGraw Hill.

Requisitos de
Usuário e Sistema

Acesse o Livro

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Requisitos de Usuário
São declarações, em uma linguagem natural com diagramas, de quais serviços são
esperados do sistema e as restrições sob as quais ele deve operar.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Requisitos de Sistema
Definem detalhadamente, as funções, os serviços e as restrições operacionais do sistema.
O documento e requisitos de sistema deve ser preciso, definindo exatamente o que será
implementado. Podendo ser parte do contrato entre o comprador do sistema e a
organização que desenvolve o software. É dividido em: Requisitos de domínio, funcionais
e não funcionais.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 <
41 />

Bibliografia básica
PRESSMAN, Roger S.. Engenharia de Software. 9a ed. McGraw Hill.

Regras de
Negócios

Acesse o Livro

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Regras de Negócio
Requisitos de domínio (ou regras de negócio) são provenientes do domínio de aplicação
do sistema e refletem características e restrições desse domínio. Eles são derivados do
negócio que o sistema se propõe a apoiar e podem restringir requisitos funcionais
existentes ou estabelecer como cálculos específicos devem ser realizados, refletindo
fundamentos do domínio de aplicação (SOMMERVILLE, 2011).

Ex.: Em um sistema de matrícula de uma universidade, uma importante regra de negócio

diz que um aluno só pode se matricular em uma turma de uma disciplina se ele tiver
cumprido seus pré-requisitos.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
 <
44 />

Bibliografia básica
PRESSMAN, Roger S.. Engenharia de Software. 9a ed. McGraw Hill.

Requisitos
Funcionais e Não
Funcionais
Acesse o Livro

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Requisitos Funcionais
São declarações de serviços que o sistema deve prover, descrevendo o que o sistema
deve fazer (SOMMERVILLE, 2007). Um requisito funcional descreve uma interação entre
o sistema e o seu ambiente (PFLEEGER, 2004), podendo descrever, ainda, como o sistema
deve reagir a entradas específicas, como o sistema deve se comportar em situações
específicas e o que o sistema não deve fazer (SOMMERVILLE, 2007).

Ex.: O sistema deve registrar locações, indicando o cliente, os itens locados, a data da
locação, a data de devolução e o valor da locação.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
 Requisitos Não Funcionais
Descrevem restrições sobre os serviços ou funções oferecidos pelo sistema (SOMMERVILLE,
2007), as quais limitam as opções para criar uma solução para o problema (PFLEEGER,
2004). Neste sentido, os requisitos não funcionais são muito importantes para a fase de
projeto (design), servindo como base para a tomada de decisões nessa fase.

Ex.: A consulta ao acervo da locadora deve estar disponível pela Internet, a partir dos
principais navegadores disponíveis no mercado. (requisito de portabilidade)

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Requisitos Não Funcionais
Os requisitos não funcionais têm origem nas necessidades dos usuários,
em restrições de orçamento, em políticas organizacionais, em
necessidades de interoperabilidade com outros sistemas de software ou
hardware ou em fatores externos como regulamentos e legislações
(SOMMERVILLE, 2007).

Assim, os requisitos não funcionais podem ser classificados quanto à

sua origem. E podem ser caracterizados em 3 tipos:

1. Requisitos de Produto
2. Requisitos Organizacional
3. Requisitos Externos
<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
 <
50 />

Bibliografia básica
PRESSMAN, Roger S.. Engenharia de Software. 9a ed. McGraw Hill.

Requisitos
Não Funcionais

Produto Acesse o Livro

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Requisitos de Produto
É uma etapa fundamental no processo de desenvolvimento e lançamento de novos
produtos.

Os requisitos de produto são essencialmente as características, especificações e

funcionalidades que o produto deve possuir para atender as necessidades e expectativas
dos clientes.

Com o objetivo de estabelecer o propósito do produto, o que se espera alcançar como

ele e quais as metas a serem atingidas. Esses objetivos servirão como diretrizes para a
definição dos requisitos avaliando assim, se o produto foi bem-sucedido ou não.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
 <
53 />

Bibliografia básica
PRESSMAN, Roger S.. Engenharia de Software. 9a ed. McGraw Hill.

Requisitos
Não Funcionais

Organizacionais Acesse o Livro

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Requisitos Organizacionais
É aquele que está diretamente relacionado aos padrões da organização.

O software deve ser desenvolvido de acordo com as políticas e definições da empresa

para garantir que o produto final gerado esteja em conformidade com as normas
empresariais.

Exemplo:
• Infraestrutura
• Sistema Operacional Compatível
• Conexão
• Criptografia usada pela empresa/organização
• Linguagem de programação requisitada pela empresa/organização

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
 <
56 />

Bibliografia básica
PRESSMAN, Roger S.. Engenharia de Software. 9a ed. McGraw Hill.

Requisitos
Não Funcionais

Externos Acesse o Livro

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Requisitos Externos
São aqueles que estão relacionados a qualquer tipo de agente externo ao software.

Nesse caso, serial aspectos não relacionados diretamente ao produto, mas que pode
impactar no seu funcionamento e deve ser definido.

Exemplo:
• Localização geográfica em que será usado
• Legislação
• Sistemas
• Política de proteção de dados (LGPD)

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
Processos da Engenharia de Software

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
 Levantamento de Requisitos

Fase do Projeto em que o profissional entende a necessidade do cliente,

extraindo informações sobre o que ele deseja.

É o momento de conversa com o usuário, de sentimento sobre o que este

espera que seja entregue a ele.

Algumas Técnicas:
1. Pesquisa: Entrevista/Questionário
2. Criatividade: Brainstorming/Analogia
3. Documentos: Leitura baseada em perspectiva/Reutilização
4. Observação

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
 Análise e Negociação de Requisitos

A análise e negociação de requisitos é normalmente um processo

complexo

Requer pessoas com competências específicas

Baseia-se muito no julgamento e experiência dos participantes

É algo custoso e moroso.

Tem como objetivo descobrir problemas com os requisitos e chegar a

acordos para uma resolução.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
 Documentação

Fase do Projeto de delimitação do escopo do conjunto de funcionalidades

que um sistema deve prover.

Descreve os atributos de qualidade que devem ser suportados.

Deve ser elaborada de maneira precisa, completa, consistente e,

principalmente, compreensível aos stakeholders.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
 Verificação

É o processo de confirmação de que os requisitos do sistema contêm

todos os elementos necessários de requisitos bem escritos.

É uma etapa crítica no desenvolvimento do sistema, pois ajuda a garantir

que o produto atenda aos seus objetivos e funções conforme pretendido

É importante pois ajuda a garantir que o sistema a ser construído

atenderá aos objetivos e funções conforme pretendido.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Validação

Checagem do produto, a fim de garantir que o software em

desenvolvimento irá satisfazer as reais necessidades das partes
interessadas. Ou seja, se os requisitos e modelos documentados atendem
às reais necessidades de usuários e clientes.

Aspectos avaliados:
1. Planejamento do Projeto
2. Gerenciamento de Riscos
3. Testes de Aceitação
4. Controle de Mudanças

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>
 Gerenciamento

Conjunto de atividades que auxilia a equipe do projeto a identificar,

controlar e rastrear os requisitos, bem como as alterações nos requisitos
do projeto.

Razões para implementação do gerenciamento de requisitos:

1. Entrega mais rápida

2. Desenvolvimento de baixo custo com riscos minimizados
3. Gerenciamento de elementos de requisitos
4. Rastreamento, monitoramento e relatórios precisos dos requisitos
5. Gerenciamento mais fácil de mudanças em todo o ciclo de vida de
desenvolvimento

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

"Durante o desenvolvimento do projeto, quanto
mais tarde um defeito nos requisitos for
corrigido, mais altos serão os custos com
sua correção. O esforço necessário para corrigir
um defeito durante a programação é até 20
vezes maior do que realizar a correção durante a
ENGENHARIA DE REQUISITOS. Se o defeito for
corrigido durante os testes de aceitação, o
esforço exigido pode ser até 100 vezes maior."
(BOEHM, 1981.)
 <
73 />

Bibliografia básica
PRESSMAN, Roger S.. Engenharia de Software. 9a ed. McGraw Hill.

Documentação de
Requisitos

Acesse o Livro

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 Requisitos
Consiste na definição do documentada de uma propriedade ou comportamento que um
produto deve atender.

Os Requisitos definem o que é necessário e dão foco à equipe do projeto. Eles são o
método primário para comunicar os objetivos do projeto para todos na equipe.

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>

 <
75 />

Dúvidas?
Instagram

@vinicius_eng_comp

<UNIVERSIDADE EVANGÉLICA DE GOIÁS/>