O documento discute a evolução da preocupação com a qualidade do software ao longo dos anos, desde os erros conhecidos após o término do programa na década de 1950 até os processos de testes estruturados e padrões de qualidade nas décadas seguintes. Além disso, destaca que 80% dos custos de desenvolvimento são gastos para identificar e corrigir defeitos de programação e que mais de 30% dos projetos de software são cancelados.

2. A PREOCUPAÇÃO COM QUALIDADE DO SOFTWARE
Período Características
Anos 50 -Erros conhecidos, APÓS término do programa
Anos 70 -Análise/programação estruturada.
-Falta de consenso: teste ANTES do término
Anos 80 - Primeiras preocupações e PADRÕES com QUALIDADE
de software
Anos 90 -Primeiros processos de testes.
-Motivação: Bug do milênio.
Anos
2000
-Estruturação dos procedimentos de testes dentro do
processo de desenvolvimento.
-Surgem excelentes ferramentas de testes.
-QUALIDADE Total no processo de desenvolvimento e
produto de software

3. A CRISE DO SOFTWARE
Fatos reais - Projetos de Software
+ 30% dos projetos – CANCELADOS
+ 70% dos projetos – FALHAM as funcionalidades
Custos e Prazos EXTRAPOLAM a Previsão
Custos – em mais de 180%
Prazos – em mais de 200%
Custos do DESENVOLVIMENTO
80% - identificar e corrigir defeitos de programação

4. Acúmulo
de trabalho
Abandono de
planos e
procedimentos
Sucesso depende muito do
esforço heróico das pessoas Pouca
repetibilidade
Produto funciona, mas
com defeitos; prazo e
custo maiores; e menos
funcionalidade
Clientes e
funcionários
insatisfeitos
Situação atual da maioria das empresas de SW

5. Vídeo: EmpresaFazSite - Problemas processo de
desenvolvimento de software
https://www.youtube.com/watch?v=QPiR8jTMLdI

6. ASPECTOS RELEVANTES sobre SW e processo de desenvolver
• Software NÃO é tangível. Requer muita ABSTRAÇÃO para desenvolvê-lo.
• O processo de desenvolvimento é executado e gerenciado por pessoas,
sendo portanto SUBJETIVO.
•Discute-se idéias, necessidades e desejos dos usuários (também
pessoas).
• ABSTRAÇÃO E SUBJETIVIDADE conferem dificuldades ao processo de
desenvolvimento.
• O software em si é consequência direta da forma (processo) pelo qual foi
desenvolvido. PROCESSO MANUFATURADO
•Processo de desenvolvimento eficiente  Software eficiente.
Na medida em que os softwares crescem em tamanho e
complexidade, ABSTRAÇÃO e COMPLEXIDADE conferem cada
vez mais DIFICULDADES ao processo de desenvolvimento

7. ONDE ESTÃO OS DEFEITOS ?
• A maior dificuldade esta na fase
INICIAL, de entendimento do sistema
- Requisitos – ALTO grau de
ABSTRAÇÃO + Comunicação com
pessoas
• A segunda maior abrangência está
na modelagem – ALTO Grau de
ABSTRAÇÃO + domínio das técnicas
• O erros de codificação em si,
representam um % pequeno,
mostrando que o foco do problema
não é da Implementação.

8. Processo de Desenvolvimento de SW
•Conjunto de atividades, métodos,
práticas e tecnologias que as pessoas
usam para desenvolver e manter
softwares
•O processo adequado garante que o
software será desenvolvido de maneira
organizada, disciplinada e previsível.
•O processo descreve formalmente e de
forma organizada as atividades que
devem ser seguidas para a obtenção
segura de um produto de software.
•A dificuldade está no gerenciamento do
processo (existem vários modelos), que
geralmente está dividido em fases.

9. Engenharia de Requisitos
9
Processo de descobrir, analisar, documentar
e verificar serviços requeridos para um
sistema e suas restrições operacionais.

10. O que é um requisito?
10

11. Para que levantar Requisitos?
11

12. Níveis de requisitos
12
Alto Nível Requisitos do usuário
Baixo Nível Requisitos de Sistema

13. Tipos de requisitos
1) Requisitos de usuário
Declarações em linguagem natural
Escritos para os usuários
Quais serviços o Sistema deverá fornecer a seus
usuários
Quais restrições com as quais o sistema deverá operar
13

14. Tipos de requisitos
2) Requisitos de sistema
Costuma ser chamado de “especificação de requisitos”
 Documento estruturado estabelecendo descrições
detalhadas das funções, serviços e restrições operacionais do
sistema
Define o que deve ser implementado
Pode ser parte de um contrato entre o cliente e o
desenvolvedor.
14

15. Classificação dos
Requisitos
15

16. Classificação dos requisitos
16

17. Requisitos funcionais e não funcionais
Requisitos funcionais
◦ 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.
Requisitos não funcionais
◦ Restrições sobre serviços ou funções oferecidos pelo sistema tais como
restrições de timing, restrições sobre o processo de desenvolvimento,
padrões, etc.
17

18. Requisitos funcionais
Descrevem a funcionalidade ou serviços de sistema
Declarações de serviços que o sistema deve fornecer
 Como o sistema deve reagir a entradas específicas
Como o sistema deve se comportar em determinadas
situações
 Declarações do que o Sistema não deve fazer
18

19. Exemplos de requisitos funcionais
19

20. Requisitos não funcionais
20

21. Requisitos não funcionais
Definem propriedades e restrições de Sistema
 Restrições são capacidade de dispositivos de E/S,
representações de sistema, etc.
Podem ainda estar relacionados a portabilidade, de
SO, de BD, etc.
21

22. Requisitos não funcionais
22

23. Classificações de requisitos não funcionais
Requisitos de produto
◦ Requisitos que especificam que o produto entregue deve se
comportar de uma maneira particular, por exemplo, velocidade de
execução, confiabilidade, etc.
Requisitos organizacionais
◦ Requisitos que são uma conseqüência de políticas e procedimentos da
organização, por exemplo, padrões de processo usados, requisitos de
implementação, etc.
Requisitos externos
◦ Requisitos que surgem a partir de fatores externos ao sistema e seu
processo de desenvolvimento, por exemplo, requisitos de
interoperabilidade, requisitos legais, etc.
23

24. Tipos de requisitos não
funcionais
24

25. Exemplos de requisitos não funcionais
25

26. Métricas requisitos não funcionais
26

27. Questão:
27

28. 28

29. Regras de Negócio
29
Toda organização empresarial realiza negócio, opera em um ou
mais segmentos e possui normas que orientam sua atuação.
Por exemplo:
Qual Banco ou bancos você utiliza? Todos funcionam da mesma
forma?
Uma grande rede de farmácias pode definir que clientes com
amis de 60 anos ou aposentados tenham descontos mínimo de
20% na compra de medicamentos controlados.
Em geral, as regras de negócio definem critérios exclusivos da
empresa, os quais podem afetar o funcionamento do futuro do
sistema.

30. Regras de Negócio
30
Contudo situações dessa natureza, é
fundamental que o analista conheça as
regras de negócio da companhia,
inclusive para definir requisitos claros que
estabeleçam esses detalhes do negócio.
Sem essas especificações, o sistema
NÃO atenderá a organização.

31. Exercícios
1) Os requisitos têm um papel central no processo de
desenvolvimento de software? De que maneira os requisitos
influenciam em outras atividades do processo de software?
2) O que são requisitos funcionais e não funcionais de um sistema? Dê
exemplos.
3) Explique a importância de estabelecer requisitos de Hardware e
Software para um futuro sistema. Dê um exemplo dentro de uma
organização.
4) Explique o significado das regras de negócio em uma organização?
5) Considerando uma empresa de cartões de crédito, faça uma
listagem de 5 regras de negócio em uma organização.
31

32. Exercícios
6) Cite 3 requisitos não funcionais necessários para o desenvolvimento de um
sistema de controle de estoque de uma farmácia. Justifique sua resposta.
7) Pense em um sistema de folha de pagamento de empregados de uma empresa.
Descreva a importância da manutenibilidade para este tipo de sistema.
8) “O gerente de uma loja de material de construção deseja implantar um sistema
na loja para controle de clientes e materiais vendidos.
O novo sistema vai cadastrar e manter os clientes e os produtos vendidos
emitindo um relatório semanal com os itens abaixo do estoque mínimo, além de
controlar a entrada e saída de ´produtos vendidos pela loja. Com base nas
operações citadas, liste 6 possíveis requisitos funcionais para o sistema de
informação a ser implantado.
32

33. Exercícios
33
Estudo de Caso: Fábrica Nacional de Peças para Automóveis LTDA.

34. Engenharia de Requisitos
34

35. Engenharia de requisitos?
35
É um processo que engloba todas as atividades
que contribuem para a produção de
um documento de Requisito.

36. Engenharia de Requisitos
1. Estudo de viabilidade
2. Elicitação/Levantamento e análise de
requisitos
3. Especificação e documentação
4. Validação
36
Resultado:
DOCUMENTO DE REQUISITOS
4 atividades
( alto nível)

37. Processo de Engenharia de Requisitos
37

38. Processo de Engenharia de Requisitos
38

39. 1) Estudo de Viabilidade
39
Avaliar sob o ponto de vista tecnológico e organizacional se o projeto
é VIÁVEL!

40. 2) Elicitação de Requisitos
40

41. 2) Elicitação /Levantamento de
Requisitos
41

42. 2) Elicitação de Requisitos
42
Atividades envolvidas nesta fase:
 Compreensão do domíneo
 Identificação das partes interessadas
 Captura
 Analise do problema

43. 2) Elicitação de Requisitos
43
Atividades envolvidas nesta fase:

44. 2) Elicitação de Requisitos
44
Dificuldades nesta fase:

45. Visão de um projeto:
Exemplo da diferença de visão de cada profissional envolvido em um
projeto.

47. Definição de um problema

48. 2) Análise de Requisitos
48
Atividades envolvidas nesta fase:
 Classificação:
 Resolução:
 Priorização:
 Confirmação:

49. 2) Análise de Requisitos
 Dificuldades
Fatores externos políticos podem
influenciar os requisitos;
O ambiente (econômico,
organizacional possui fatores
dinâmicos);
Novas partes interessadas são
envolvidas no projeto;
 Negociações
Salientar os benefícios para todos
os envolvidos;
Fomentar a justificação das
exposições;
Saber lidar com ataques pessoais;
49

50. 3) Especificação e Documentação
50
É a produção do:
DOCUMENTO DE ESPECIFICAÇÃO DE REQUISITOS
 Requisitos funcionais
 Requisitos não funcioanais
 Requisitos do Usuário
 Requisitos de Sistema

51. 4) Validação de Requisitos
Pretende-se demonstrar que o documento
produzido corresponde ao que o cliente pretende.
Deve ser especificados os CHECKLISTS:
51

52. 4) Validação de Requisitos
o VALIDADE = se está entre as partes envolvidas
oCONSISTÊNCIA = se há conflito entre os requisitos requisitados
oCOMPREENSIBILIDADE = não está de forma equivoca
oCOMPLETUDE = se possui todas as funcionalidades pretendidas
oREALISMO = se é implementável (tecnologicamente e financeiramente)
oVERIFICABILIDADE = se está descrito de forma evitar discordância
oRASTREABILIDADE = origem dos requisitos
oCONFORMIDADE = obedece as normas de todos os documentos
52

53. 4) Técnicas de Validação
 *Revisão dos requisitos = com equipes de
revisores
*Prototipação = protótipo
Geração de casos consistência automática =
testar de forma automática ferramenta CASE
* PRINCIPAIS E MAIS UTILIZADOS
53

54. 4) Técnicas de Validação
OS TESTES PODE APENAS MOSTRAR A PRESENÇA DE
ERROS E NÃO A SUA AUSÊNCIA.
SOMMERVILLE
54

55. 4) Técnicas de Validação
VERIFICAÇÃO
O software de estar de
acordo com sua
especificação
X VALIDAÇÃO
O software deve fazer
o que o usuário
necessita
55

56. 4) Técnicas de Validação
INSPEÇÕES
Ferramentas baseadas
em documentos e
análise de códigos
# TESTE
O sistema é executado
com dados de teste e seu
comportamento é
observado.
56

57. 4) Técnicas de Validação
57

58. Atividade: Grupo
58

59. Obtenção dos Requisitos
59

60. Obtenção dos requisitos
60

61. Obtenção dos requisitos
Processo que reúne informações sobre o sistema
proposto e os existentes para obter os requisitos de
usuário e de sistema
 Fontes: documentação, stakeholders, especificações
de sistemas
 Resultados: cenários, protótipos, modelos
estruturados
61

62. Obtenção dos requisitos
62

63. Documento de Requisitos
de Software
63

64. Documento de Especificação de Requisitos
64

65. Documento de Requisitos
65

66. Quem
utiliza
o Documento
de
Requisitos???
66

67. Documento de Requisitos
67

68. Documento de Especificação de Requisitos
Padrões:
1) Use ‘deve’ para requisitos obrigatórios, e ‘deveria’ para requisitos
desejáveis.
Exemplo:“O sistema deve rodar em microcomputadores da linha IBM PC que
possuam microprocessador 486 DX ou superior.”
2) Os requisitos devem estar organizados logicamente, como por
exemplo, inicialmente todos os requisitos de entrada, depois os de
processamento e por último os requisitos de saída.
68

69. ◦ 3) Cada requisito deve ter um identificador único, por exemplo,
um identificador numérico, para posterior referência.
◦ 4) Os requisitos do software devem estar divididos em
requisitos funcionais e não funcionais (de qualidade).
◦ 5) Evitar o uso de jargões de computação.
69
Documento de Especificação de Requisitos

70. Ex. Documentação de Requisitos
70

71. Gerenciamento de requisitos
Gerenciamento de requisitos, é o processo de gerenciamento
de mudanças de requisitos durante o processo de engenharia
de requisitos e o desenvolvimento de sistema.
Requisitos são, inevitavelmente, incompletos e inconsistentes
◦ Novos requisitos surgem durante o processo, à medida que as
necessidades de negócio mudam e uma melhor compreensão do
sistema é desenvolvida;
◦ Os diferentes pontos de vista têm requisitos diferentes e estes são
freqüentemente contraditórios.
71

72. Gerenciamento de requisitos
 É o processo de Gerenciar as MUDANÇAS
As modificações organizacionais, técnicas e negócios levam a mudanças
nos requisites
No gerenciamento de mudanças as mudanças são analisadas se seu
impacto é válido
72

73. Exercícios
1) Qual a diferença de usuários para Stakeholder?
2) Cite as 4 fases da Engenharia de Requisitos?
3) Diferencie requisitos de usuários de requisitos de sistema: Qual o público alvo desta
documentação?
4) Por que é importante prover modelos de documentos de requisitos?
5) Capturar atributos de qualidade de produto pode ser uma tarefa difícil, sobretudo para analista
menos experientes. Como uma organização pode facilitar a captura desse tipo de requisito?
6) Por quê é importante gerenciar Requisitos? Quais os propósitos da Gerência de Requisitos?
7) Por que é necessário verificar e validar requisitos? Qual a diferença em ter o enfoque verificação e
a validação de Requisitos?
8) Que técnica de levantamento de requisitos é bastante recomendada para apoiar a negociação de
requisitos?
73

74. Exercícios
74
9)
10) Quais são as principais informações sobre o projeto representadas
no Documento de Requisitos?

75. Exercícios:
Atividade em grupo
75

76. 76
Estudo de caso: Pousada

77. 77
Estudo de caso: Pousada
A) Elabore uma lista de requisitos a partir do estudo de caso apresentado.
B) Identifique os requisitos não funcionais na situação exposta.
C) Escola uma técnica de levantamento de requisitos e justifique.
D) Crie a partir de sua técnica escolhida um conjunto de perguntas que
visem esclarecer o maior numero de dúvidas exposta pelo stakeholder.

78. 78
Exercícios
1) Quais as principais técnicas para o levantamento de informações
com o objetivo de definir requisitos para a construção de um sistema?
2) Descreva os procedimentos que o analista de sistemas deve adotar para
conhecer a cultura de uma empresa, a fim de definir requisitos para um sistema
de informação?
3) Quando a utilização de questionários é recomendável?
4) Conceitue estudo etnográfico.
5)Uma entrevista com 2 horas de duração, tendo início logo pela manhã,
quando o entrevistado ainda esta descansado, é produtiva?
Justifique sua resposta.

79. Referência para leitura
SOMMERVILLE, Ian. Engenharia de Software, 8 ed. São Paulo: Pearson
Addison-Wesley, 2007.
◦ Capítulo 6 - Requisitos de Software.
◦ Capítulo 7 – Processos de Engenharia de Requisitos
79