Requisitos: Indica o que o sistema fará e com que restrições, é uma necessidade única que

detalhe o que um produto ou serviço em particular deve fazer.

- Levantamento de Requisitos: Etapa de comunicação com cliente e obtenção das

funcionalidades do sistema terá.

- Análise de Requisitos: Envolve verificar se a especificação dos requisitos dos

requisitos é correta, completa, consistente, unívoca e realista.

Documentos de Requisitos: Declaração oficial daquilo que se requer dos desenvolvedores do

sistema, deve incluir definição dos requisitos de usuário e especificação de requisitos do
sistema.

Requisitos de usuário: São aqueles feitos no mais alto nível de abstração, feito para usuário
leigo em computação par entendimento geral do sistema, o mesmo é feito para o cliente em
linguagem natural.

Requisitos de sistema: São versões mais expandidas (detalhadas) dos requisitos de usuário
destinado a desenvolvedores/Engenheiros de Software, trata-se de um documento
estruturado com descrições detalhadas sobre funções, serviços e restrições operacionais do
sistema, além de definir o que deve ser implementado de uma forma que lhe permite ser
parte do sistema.

Especificação de Software: é o processo de descrever um sistema considerando as suas

propriedades desejadas.

Requisitos Funcionais: São requisitos que representam funcionalidades exigidas pelo cliente,
mas não com restrições de como fazê-lo, condiz com o comportamento do sistema, por
exemplo: O Sistema deve cadastrar usuário.

Requisitos Não-Funcionais: São aqueles requisitos onde há declarações das restrições sobre
serviços ou funções oferecidos pelo sistema incluindo restrições temporais, restrições no
processo de desenvolvimento, padrões a seguir.

- Requisitos de Produto: Especificação de como o sistema tem de se comportar de

determinada forma, como o mesmo deve ser feito/implementado exemplo: velocidade de
execução ou confiabilidade, o sistema deverá ser implementado em Java.

- Requisitos Organizacionais: São consequências de políticas e procedimentos

organizacionais, tais como, seguir as regras de um banco, a regra de uma locadora, enfim
regras de negócio específicos de cada particularidade, podem ser também padrões, modelos
que o cliente exija que sejam aplicados, exemplo: o sistema deve utilizar o padrão x para
desenvolver o software

- Requisitos Externos: São aqueles que tem origem em fatores externos ao sistema e
ao seu processo de desenvolvimento, como exemplo política de privacidade, requisitos legais
ou de interoperabilidade, são aqueles também que devem obedecer legislações como de
direitos autorais.

Requisitos de Domínio: Tem origem no domínio da aplicação e refletem características desse

domínio, como por exemplo um sistema de solução de sistemas lineares tem um método
específico para resolver sistemas como gauss-seidel que é um requisito do domínio.
Métricas de Requisitos: São medidas que se pode obter baseando-se em:

-Velocidade: Transações processadas por segundo, tempo de resposta ao

usuário/evento, tempo de atualização da tela.

-Tamanho: Tamanho máximo em MB

-Facilidade de Uso: Tempo de treino, número de telas de ajuda

-Confiabilidade: Tempo médio entre falhas, taxa de ocorrência entre falhas,

-Robustez: Tempo de reinicio após falha, Percentagem de eventos que causaram a

falha, probabilidades de dados corrompidos pós falhas

-Portabilidade: Percentagem de instruções dependendo do sistema alvo, número de

sistemas alvo

Teste de software: Processo de exercitar um programa com o objetivo específico de encontrar

erros antes da entrega final ao usuário, os mesmo devem revelar presença de erros e não
ausência, além de ser a única técnica de validação de requisitos não funcionais.

Estratégias de Teste (Passos):

- Conduzir revisões do software regularmente

- Conduzir testes primeiro em nível de componente e prosseguir em direção à

integração completa.

- Envolver tanto o desenvolvedor quanto os especialistas.

Importância de Teste de Software: Mostrar erros, conformidades com requisitos,

desempenho e indicação de qualidade.

Teste de Unidade: Tem por objetivo testar a menor unidade do projeto (um componente de
software que não pode ser subdividido), procurando identificar erros de lógica e de
implementação em cada módulo separadamente. No paradigma estruturado, a menor
unidade refere-se a um procedimento ou função. No paradigma orientado a objetos pode-se
considerar uma classe ou um método;

Teste de Integração: Visa descobrir erros associados a interfaces entre outros módulos
quando esses são integrados para formar a estrutura do produto de software, focando assim
na arquitetura de software.

Teste de Validação: Tem por objetivo identificar erros de funções (requisitos funcionais) e
características de desempenho, entre outros, (requisitos não-funcionais) que não estejam de
acordo com as especificações.

Teste de Sistema: Testa o software e os outros elementos do sistema do qual o software faz
parte.

Falta: é o problema, é detectada por teste

Falha: é onde ocorre o erro, é detectada por depuração

Depuração: Processo de diagnóstico e correção de erros, a depuração pode ser: Força bruta,
rastreamento, eliminação de causa.

Técnicas de Teste (Testabilidade): Operabilidade, Observabilidade, Controlabilidade,

Decomponiblidade, Simplicidade, Estabilidade, Compreensibilidade.

Característica de um bom teste:

–Tem alta probabilidade de encontrar um erro

–Não é redundante

–Deve ser “de boa qualidade”

–Não deve ser muito simples nem muito complexo

Estrutura de um plano de teste:

–O processo de teste

–Rastreabilidade de requisitos

–Itens que devem ser testados

–Cronograma dos testes

–Procedimentos de registro de testes

–Requisitos de hardware e software

–Restrições
Técnicas de Teste:
- Exaustivo: Aquele que pode demonstrar que um programa é livre de defeitos, mas é
um teste impossível.
-Seletivo: Aquele onde se escolhe um caminho por onde se vai testando todo o
software.

Gestão de Configuração de Software: Busca alocar recursos específicos para apoio de

desenvolvimento de software e além disso auxilia no controle de diferentes versões do
sistema. Contudo, a GSC é um importante elemento da garantia da qualidade de software.

Problema de Atualização Simultânea: Solução: Biblioteca Central de Recursos Compartilhados

Produto de Software: Programas de computador, procedimentos, documentação relacionada

e informações designadas para serem entregues ao cliente/usuário final.

Processo de GSC: Identificação, Documentação, Controle e Auditoria

Tarefas de GSC: Identificação (Como a organização vai identificar as mudanças de forma

eficiente), Controle de Mudança (Quem tem responsabilidade e quem vai aprovar as
mudanças e quem prioriza as mudanças), Controle de Versão, Auditoria de configuração(pode
ser funcional(preocupa-se com aspectos internos dos arquivos) ou física(determina
características não consideradas durante a revisão), Relato de situação (Mecanismo para avisar
sobre mudanças), Controle de interfaces (Que efeito que alterações externas vão causar ao
sistema), Controle de Subcontratados e fornecedores(Garante que módulos implementados
por terceiros estão corretamente adequados ao sistema).

Conceitos Fundamentais:

-Linhas-Base: Ajuda a controlar as mudanças sem impedir seriamente as mudanças

justificáveis,

-Repositórios: Local onde fica armazenado os itens de configuração geralmente são

locais com controle de acesso (bancos de dados).

-Check-in/Check-out: Quando se deseja fazer alteração em algum item do repositório

Projeto Estruturado – DFD:

Fluxo de dados válidos: ligação direta independente da direção entre entidade externa e
processo, processo ligado a outro processo e processo acessando depósito de dados. A figura a
seguir apresenta alguns fluxos válidos.

Fluxos de dados inválidos: ligação direta entre entidades externas e ligação direta entre
depósito de dados. A figura a seguir ilustra fluxo de dados inválidos.

DFD contexto - são apenas os teminators e o sistema.

DFD nível 0 - são os terminators, nomes dos processos superficialmente, só que aparece o
nome dos fluxos (dados de entrada e saída).
DFD nível 1 - é o de detalhe, aparecem os depósitos e há um detalhamento dos processos.

MODELAR PROCESSOS COM ENTRADA E SAIDA

Diretrizes para Elaborar um DFD

1.Inicie identificando nomes de fluxos de entrada e saída

2.Nomeie todos os fluxos de dados
3.Evite nomes vagos como “Dados“ e ”Informações”
4.Dê nomes antes aos fluxos de dados, depois aos processos
5.Tente nomes de processos comum verbo de ação forte e um objeto direto singular-mais
de um verbo ou objeto pode indicar necessidade de particionar
6.Cuidado com palavras vagas como Processar, manipular...
7.O sistema descrito deve ser suposto em operação normal
8.Retrate fluxo de dado senão de controle - na dúvida
Pergunte -se: que informações fluem pelo tubo? Se nenhuma, remova-o.
9.Todo processo deve ter fluxo de entrada e de saída
10.Evite DFD complexos demais
11.Certificar-se que o DFD seja internamente consistente além de manter consistência com
outros DFD,