Material usado como apoio aula de engenharia de SW, requisitos

1. Engenharia de Software I
1Prof. Ricardo F. P. Satin, MBA, PMP
CESUMAR – Centro Universitário de Maringá

2. Agenda
• Engenharia de Requisitos
• Atividade
Prof. Ricardo F. P. Satin, MBA, PMP 2

3. Agenda
• Engenharia de requisitos
• Atividade
Prof. Ricardo F. P. Satin, MBA, PMP 3

4. Requisito
• Pesquisa do Standish Group (Chaos 2009):
• Classificação dos Projetos:
– Sucesso: Projeto que terminaram no prazo estipulado,
dentro do orçamento e com escopo completo.
– Mudaram: Projetos que atrasaram, estouraram o
orçamento e/ou tiveram o escopo reduzido.
– Falharam: Projetos que foram cancelados ou nunca foram
usados.
Prof. Ricardo F. P. Satin, MBA, PMP 4

5. Requisito
Prof. Ricardo F. P. Satin, MBA, PMP 5

6. Requisito
Prof. Ricardo F. P. Satin, MBA, PMP 6

7. Requisito
• IEEE Std 830-1998 – Recommended Practice
for Software Requirements Specification
• http://ieeexplore.ieee.org/Xplore/guesthome.jsp
Prof. Ricardo F. P. Satin, MBA, PMP 7

8. Requisito
• SRS definição
• Envolvidos com SRS
• O SRS deve ter:
– Funcionalidades: O que um software deve processar
– Interfaces externas: Como é feita a interação entre as pessoas e o software?
– Performance: Qual é a velocidade, tempo de resposta, tempo de recuperação?
– Atributos: Segurança, atributos de manutenção.
– Restrições de projeto impostas na implementação: políticas de integração de
banco de dados, limites de recursos tecnológicos, ambiente operacional.
Prof. Ricardo F. P. Satin, MBA, PMP 8

9. Requisito
• Requisitos funcionais x não funcionais
– Requisitos funcionais
• descrever quais funcionalidades um sistema deve ter – venda, consulta, compra,
mov. estoque...
Prof. Ricardo F. P. Satin, MBA, PMP 9

10. Requisito
• Requisitos não funcionais
– Existe uma lista grande de itens que se enquadram nesta classificação,
vamos avaliar os mais relevantes para nosso tema:
• Requisitos técnicos (tablet, web, linux, processamento, memória,
armazenamento, link.);
• Requisitos de dados (on-line, tempo de armazenamento, local de armaz.);
• Requisitos ambientais ou contexto de uso;
– Ambiente físico (limpo, iluminado, barulho, necessita usar luvas...)
– Ambiente social (neces. trab. colaborativo, pessoas trab. juntas...),
– Ambiente organizacional (perfil funcional, inventário equipamentos...)
– Ambiente técnico (que tecnologia usar, quais limitações tecnológicas...).
• Requisitos do usuário;
– Usuários novatos ou especialistas, frequentes ou ocasionais, irão evoluir no uso da
ferramenta (haverá necessidade de ajustar perfil mediante aprendizado...)
• Requisitos de usabilidade;
– Metas de usabilidade, quão eficaz, eficiente e segura precisa ser.
Prof. Ricardo F. P. Satin, MBA, PMP 10

11. Requisito
• Requisitos devem estar:
– Corretos,
– Sem ambiguidades
– Completos
– Consistentes
– Priorizado por importância e/ou estabilidade
– Verificável
– Modificável
– Rastreavel
Prof. Ricardo F. P. Satin, MBA, PMP 11

12. Requisito
• A SRS é correta, se e somente se a mesma
retratar o que o software deve fazer.
• Qual a métrica para verificar se SRS é correta?
– Simulação de cenários juntamente com o usuário.
• Caso de uso;
• Digrama de Sequencia.
Prof. Ricardo F. P. Satin, MBA, PMP 12

13. Requisito
• O requisito é não ambíguo se e somente se
quando declarado possuir somente uma
interpretação.
– Leva também considerações aspectos da linguagem utilizada para
especificação dos requisitos.
• Linguagem natural – propícias a questões de ambigüidade.
• Linguagem de especificação de requisitos:
– Processada automaticamente
– Fluxogramas, UML, BPMN
Prof. Ricardo F. P. Satin, MBA, PMP 13

14. Requisito
• SRS é completa se e somente se incluir os
seguintes elementos:
– funcionalidades,
– performance,
– restrições de projeto,
– atributos e interfaces.
– Definições das respostas do software para as entradas. Especificar se entrada
é válida ou não.
Prof. Ricardo F. P. Satin, MBA, PMP 14

15. Requisito
• Exemplo:
– O formato de um relatório em um requisito X é considerado tabular, porém
em outro requisito esse mesmo relatório é textual.
– A interface de acesso é verde em um requisito, essa interface é azul em outro.
– Um requisito cita que o programa A irá adicionar dois número e outro cita que
o programa ira multiplicar.
– Um requisito mostra que o estado A deve ocorrer após o B ou outro mostra
que A e B ocorrem simultaneamente.
Prof. Ricardo F. P. Satin, MBA, PMP 15

16. Requisito
• Requisitos pode ser:
– Essenciais,
– Críticos.
– Desejável.
• O cliente pode priorizar os requisitos.
• O desenvolvedor pode corrigir a classificação
de prioridade do cliente
Prof. Ricardo F. P. Satin, MBA, PMP 16

17. Requisito
• A SRS deve possuir mecanismo de verificação em
relação se o produto de software.
• Exemplo: A saída do programa deve produzir em 20 s a
emissão 60% dos registros.
• Alguns requisitos não funcionais são difícil de serem
verificados, por exemplo: a interface deve ser
agradável.
• O que é agradável para você?
Prof. Ricardo F. P. Satin, MBA, PMP 17

18. Requisito
• O gerenciamento de mudanças de um
requisito deve ser contemplado, pois alguns
requisitos mudam constantemente.
• Quando há mudanças o impacto nos demais
requisitos deve ser considerado.
Prof. Ricardo F. P. Satin, MBA, PMP 18

19. Requisito
Prof. Ricardo F. P. Satin, MBA, PMP 19
Requisito A
analisado
Implemen.
projetado
testado
Funcionalidade A
Funcionalidade B
Funcionalidade C

20. Matriz de impacto de requisitos
Matriz de análise de
impacto
Módulos
Estoque Financeiro
Posições de estoque Custo de produto CP CR CNAB Flx. Caixa Cheque
Módulo
Comercial
Formação de Preço
Pedido de Venda X X X
Emissão de nota X X X X X
Emissão de ECF X X X X X
Compras
Cotação de compra X X
Pedido de Compra X X X
Nota de entrada X X X X X
Conhecimento de Frete X X X
Produção
Ficha técnica
Planejamento de Produção X
Apontamento
Prof. Ricardo F. P. Satin, MBA, PMP 20