O documento discute requisitos de software, incluindo a importância de definir claramente o problema, visão do produto e requisitos funcionais e não funcionais. Também aborda processos de engenharia de requisitos como obter, verificar e validar requisitos para garantir que o sistema atenda às necessidades do usuário.
3. NOSSA AULA
• Parte 1 - Requisitos de software
• Parte 2 - Processos de engenharia de requisitos
• Parte 3 - Modelos de sistema
• Parte 4 - Especificação de sistemas críticos
• Parte 5 - Especificação formal
5. PROBLEMA
O primeiro pré-requisito que deve ser cumprido antes do
início da construção de um sistema é a exposição clara do
problema que o sistema deve resolver.
Aprimoramentos
Construção “VISÃO do PRODUTO”
Arquitetura
Requisitos
Definição do Problema
6. VISÃO DO PRODUTO
Exposição simples, talvez uma ou duas páginas, e deve
parecer-se com um problema.
“Preciso realizar o controle sobre a postagem dos trabalhos enviados por
alunos; pois não sabemos ao fim do período estipulado ao exercício
quantos o enviaram ou não.”
linguagem do usuário
Não usa termos técnicos
7. REQUISITOS
“Os requisitos descrevem em detalhes o que um sistema de
software deve fazer , sendo o primeiro passo rumo a uma
solução”
-Steve McConnell
http://www.flickr.com/photos/melilab/2436615256/
8. REQUISITOS EXPLÍCITOS
•Ajudam a garantir que o usuário, e não o programador, determine a
funcionalidade do sistema.
•Permite ao usuário examinar e concordar.
•Em softwares de qualidade deve-se evitar
adivinhar o que o usuário deseja.
http://www.flickr.com/photos/sscafephotos/
9. REQUISITOS FUNCIONAIS
“São as declarações de serviços que o sistema deve
fornecer, como o sistema deve reagir a entradas específicas
e como o sistema deve se comportar em determinadas
situações”. - SOMMERVILE
http://www.flickr.com/photos/sgoralnick/2087136920/
10. REQUISITOS NÃO
FUNCIONAIS
“São restrições sobre os serviços ou as funções oferecidos
pelo sistema” - SOMMERVILE
http://www.flickr.com/photos/sgoralnick/2763358685/in/set-72157603372329154/
12. É VIÁVEL ?
No início de cada projeto, iteração ou ciclo deve ser
verificado se vale a pena ou não prosseguir com a
construção das soluções para os requisitos, verificando se:
1.O sistema contribui com os objetivos da
organização;
2.Se a tecnologia atual, custo e prazo são
suficientes para produzir uma solução
satisfatória;
13. ELICITANDO REQUISITOS
Seja em reuniões de planejamento, ou por meio de outras
estratégias um ponto em comum é a necessidade de
conhecer o domínio e as reais necessidade do nosso cliente.
Obter Validar
requisitos requisitos
14. OBTENDO REQUISITOS
Existem atualmente no mercado centenas de milhares de
estratégias para obtenção de requisitos, sobre as quais cada
processo de software apresenta a sua preterida.
Planning Poker Brainstorm
JAD
Jogo do Planejamento
Entrevista
15. VERIFICANDO REQUISITOS
•Se seus requisitos não estiverem bons o bastante para todo um
projeto ou um ciclo, interrompa oque você estiver fazendo,
retroceda e corrija-os antes de prosseguir.
•O QUE FAZER ?
http://www.flickr.com/photos/sgoralnick/3463349433
16. VALIDANDO REQUISITOS
A validação de requisitos atesta que os requisitos realmente
definem o sistema que o usuário deseja para aquele
momento. São averiguados neste ponto:
Validade Completeza
Facilidade de
verificação
Consistência
Realismo
17. REQUISITOS FUNCIONAIS
•Todas as entradas para as funcionalidades conhecidas do sistema
estão especificadas ? Incluindo origem, precisão, intervalo de valores
e freqüência ?
•Todas as saídas do sistema estão especificadas, incluindo seu
destino, precisão, intervalo de valores, freqüência e formato ?
•Todos os formatos de saída estão especificados para páginas web,
relatórios, webservices e etc ?
•Todas as tarefas que o usuário deseja executar estão especificadas?
18. REQUISITOS Ñ FUNCIONAIS
•O tempo de resposta esperado, do ponto de vista do usuário, está
especificado para todas as operações necessárias ?
•Outras considerações de cronometragem estão especificadas, como
tempo de processamento, taxa de transferência e desempenho do
sistema ?
•O nível de segurança está especificado?
•A confiabilidade está especificada ?
•A definição de sucesso está incluída? e de falha ?
21. NOSSA AULA
• Parte 1 - O que são testes de software
• Parte 2 - Quais são os tipos de testes
• Parte 3 - Testes automáticos
• Parte 4 - Test Driven Development
• Parte 5 - Testes de Interface
• Parte 6 - Testes de Desempenho