1. Levantamento de
Requisitos
FEAPA
Análise e Projeto de Sistemas 1
Prof. Osiel Marlon

2. Levantamento de Requisitos
 REQUISITOS:
 Objetivos ou restrições estabelecidas por clientes e
usuários do sistema que definem as diversas
propriedades do sistema
 Condição ou capacidade necessária que o software
deve possuir:
– para que o usuário possa resolver um problema ou
atingir um objetivo
– para atender as necessidades ou restrições da
organização ou de outros componentes do sistema.

3. Engenharia de Requisitos
 É um ramo da [Engenharia de Software] que se dedica
ao estudo de soluções para levantamento,
desambiguação, análise e especificação de requisitos
para projetos de desenvolvimento de software.
 O levantamento e análise de requisitos engloba aquelas
tarefas que procuram determinar as necessidades ou
condições para que um determinado produto (de
software) Seja construído ou alterado.
 Será necessário lidar com requisitos conflituosos ou
contraditórios e os interesses de cada pessoa com
interesse no projeto ("stakeholders").

4. Engenharia de Requisitos
 Os requisitos devem ser mensuráveis (a sua cobertura),
testáveis, relacionados com necessidades identificadas
do negócio ou domínio de aplicação, e definidos a um
nível de detalhe suficiente para serem usados nas
ulteriores atividades da engenharia de software.

5. Requisitos do usuário, do sistema e
do software [Sommerville, 2004]
 Requisitos do usuário
 – Declarações, em linguagem natural e diagramas,
sobre os serviços que o sistema oferece e as restrições
para a sua operação. Escrito para os clientes.
 Requisitos do sistema
 – Estabelecem detalhadamente as funções e restrições
do sistema. O documento de requisitos, chamado de
especificação funcional, pode servir como um contrato
entre cliente e desenvolvedor.
 Especificação de software
 – Especificação abstrata e precisa do software,
indicando o que ele deve fazer (sem dizer como) que
serve de base para o design e implementação.
Acrescenta mais detalhes à especificação funcional e é
escrito para a equipe de desenvolvimento.

6. Problemas Comuns
 Os envolvidos* não sabem o que eles realmente
querem.
 Se expressam num vocabulário diferente dos
desenvolvedores.
 Os envolvidos podem ter requisitos conflitantes.
 Fatores organizacionais e políticos podem influenciar os
requisitos.
 Novos requisitos podem surgir durante o processo de
levantamento/análise/especificação.
 Novos envolvidos podem vir a participar do process.
 Podem haver mudanças externas – ambiente ou regras
de negócios.
 *Stakeholders: Envolvidos ou partes interessadas

7. DIFICULDADES DE COMUNICAÇÃO:
“Sei que você acredita que entendeu o que acha que eu
disse, mas não estou certo de que percebe que aquilo que
ouviu não é o que eu pretendia dizer...”

8. Os projetos de SI fracassam mais freqüentemente por resolverem
certo o problema errado do que propriamente resolver errado o
problema certo.
Levantamento de
Requisitos
Uma compreensão completa dos requisitos do SI é fundamental
para um bem-sucedido desenvolvimento.

9. Importância do Levantamento de Requisitos:
 Projeto e codificação perfeitos são de pouco uso
quando existem erros nos requisitos.
 O analista formaliza as necessidades do usuário,
atuando como ponte entre ele e os implementadores do sistema.
 Custo da Ambiguidade:
Fase em que se encontra Proporção do custo
Requisitos 1
Projeto 3-6
Codificação 10
Testes de desenvolvimento 15-40
Testes de aceitação 30-70
Operação 40-1000

10. Como descrever os requisitos?
 A especificação dos requisitos deve ser:
– Completa – deve descrever tudo o que é
necessário
 – Consistente – não deve haver conflitos e
contradições
 – Não-ambígua – não deve levar a interpretações
diferentes por desenvolvedores e usuários.
 • Depende da precisão da linguagem utilizada
– Linguagem natural, informal – apropriada para os
requisitos do usuário e do sistema.
 – Linguagens gráficas, semi-formais – apropriada
para os requisitos do sistema e do software.
 – Linguagens formais – apropriada para uma
especificação formal de software em métodos
formais.

11. Requisitos funcionais
 Descrição das diversas funções que clientes e
usuários querem ou precisam que o software
ofereça.
 • Exemplos:
 – "o software deve possibilitar o cálculo dos gastos
diários, semanais, mensais e anuais com pessoal".
 – "o software deve emitir relatórios de compras a cada
quinze dias"
 – "os usuários devem poder obter o número de
aprovações,reprovações e trancamentos em todas as
disciplinas por um determinado período de tempo.

12. Requisitos não-funcionais
 Propriedades de um software, como manutenibilidade,
usabilidade, desempenho, custos e várias outras
 São exemplos de requisitos não-funcionais:
 "a base de dados deve ser protegida para acesso apenas de
usuários autorizados".
 "o tempo de resposta do sistema não deve ultrapassar 30
segundos".
 "o software deve ser operacionalizado no sistema Linux"
 "o tempo de desenvolvimento não deve ultrapassar seis meses".

14. TIPOS DE REQUISITOS (revisão)
 Requisitos funcionais – dizem o que o sistema deve
fazer. Exs.:
 Suporte a formatações
 Formatação por parágrafo
 Formatação por caractere
 Requisitos não-funcionais – indicam as limitações no sistema e
em seu desenvolvimento
 Ser executado em várias plataformas
 Funcionar em um computador com 64 Mb de RAM
 Estar pronto em seis meses

15.  Tipos de requisitos não funcionais
 Requisitos de dados
 Requisitos ambientais
 Ambiente físico
 Ambiente social
 Ambiente organizacional
 Ambiente técnico
 Requisitos do usuário
 Requisitos de usabilidade

16. CUIDADOS NA ANÁLISE DE REQUISITOS
.  Se perguntar não sobre COMO deve ser feita alguma
tarefa para construir o sistema, mas sobre O QUE é
exigido
 Estar preparado para ambiguidades:
 “sei que você acredita que entendeu o que acha que eu
disse, mas não estou certo de que percebe que aquilo que
ouviu não é o que eu pretendia dizer…”
 Etapasque antes eram construídas posteriormente
devem ser pensadas em conjunto com a análise:
 Construção do manual do usuário
 Plano dos testes de usabilidade

17. Atividade
 Considerando o Bloco de Notas –
descreva os requisitos funcionais e não-
funcionais para a criação do sistema.