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".
13.
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.