O documento aborda a análise de sistemas e a especificação de requisitos, destacando a interação entre usuários e programadores na resolução de problemas por meio de algoritmos. Ele explora os conceitos de modelagem de objetos, requisitos funcionais e não funcionais, e ferramentas como diagramas de fluxo de dados. Além disso, discute a responsabilidade do analista de sistemas em traduzir as necessidades do usuário em especificações técnicas para desenvolvimento.

1. ANALISE DE SISTEMAS (INFORMÁTICA)
Resumo sobre:
1. Especificação de requisitos;
2. Fluxo de dados;
3. Conceitos básicos de modelagem de objetos.

2. O QUE É UM SISTEMA?
 É um conjunto de elementos que interagem para se atingir um
objetivo ou metas. Segundo a Comissão Nacional de Normas
Americanas (ANSSC) sugere a seguinte definição: Em
processamento de dados, conjunto de pessoas, máquinas e métodos
organizados de modo a cumprir um certo número de funções
especificas.
 Exemplo simples: Um sistema (Curso) que recebe recursos (dados
como nome dos alunos, turmas, disciplina, data da avaliação, nota
etc) como entrada e os processas em produtos (informação Notas
bimestrais, médias, soma das faltas) como saída.

3. TRABALHO: PROGRAMADORES E USUÁRIOS:
 Os programadores e usuários tendem a se concentrar em um único
programa (ou vários). O programador vê um trabalho especifico a ser
realizado enquanto o usuário vê um problema especifico para ser
resolvido.
 Como no exemplo anterior o usuário tem como problema saber as
médias dos alunos, a soma de faltas e outras informações, o
programador tem como trabalho resolver este problema criando os
algoritmos capazes de receber os dados que o usuário possui e
processa-los a fim de obter o resultado (saída) que o usuário
necessita, neste caso especifico as médias e a soma das faltas)

4. RESPONSABILIDADE DO ANALISTA DE SISTEMAS:
 O profissional cuja responsabilidade básica é traduzir as
necessidades do usuário em especificações técnicas necessárias
aos programadores. O Analista de sistemas começa desenvolvendo
uma descrição lógica das necessidades do usuário. É necessário
usar alguns recursos como levantamento dos requisitos funcionais ou
não funcionais do sistema, desenho do projeto com diagramas de
caso de uso, de sequencia, e outros que serão apresentados nos
próximos trabalhos. Deve ter também a habilidade de abstração do
mundo real, ou seja, o entendimento de classe, objetos, polimorfismo
para o bom andamento dos projetos, como veremos nos próximos
slides.

5. 1. REQUISITOS É (SÃO):
 Descrições das funções e das restrições de um sistema;
 Definição detalhada, matematicamente formal, de uma função do
sistema.
Referência: Sommerville p.82

6. ENGENHARIA DE REQUISITOS É:
 O processo de (em relação aos requisitos):
Descobrir Analisar Documentar Verificar

7. ELICITAÇÃO DE REQUISITOS E ANALISE
 Divide-se em duas partes:
1. Elicitação: Técnica de interação com usuários, atores ou envolvidos
em atividades para se obter informações relativas a um processo ou
procedimento que se deseja conhecer. Esta técnica é comumente
utilizada na engenharia de software para definir os requisitos de um
de sistemas de informação ou aplicação.
2. Analise do que foi elicitado: Processo de análise

8. TÉCNICAS DE ELICITAÇÃO
Questionários
Entrevistas
Jogos de Funções
Brainstorming (Tempestade de ideias,
criatividade em equipe)
etc

9. ENTREVISTAS
 Técnica direta: pode ser usada na analise do problema e na elicitação
de requisitos;
 Objetivo: Entender os problemas reais e soluções potenciais das
perspectivas dos usuários, clientes etc.

10. QUESTIONÁRIOS
 Aplicabilidade a mercados específicos – Onde perguntas são bem
definidas;
 Hipóteses: Perguntas relevantes podem ser decididas
antecipadamente
 Leitor ouve da maneira desejada
 Suprime o que é bom sobre análise
 Úteis após uma entrevista inicial

11. JOGOS DE FUNÇÕES
 Engenheiro de requisitos: Assume a função do usuário ou cliente
(entender o domínio do problema)
 Cliente: Assume a função do usuário (entender os problemas que
podem passar)

12. BRAINSTORMING
 Estabelecer o objetivo da sessão;
 Gerar quantas ideias for possível
 Deixar sua imaginação livre
 Não admita crítica ou debates
 Ajuste e combine as ideias.

13. VISÃO DOS REQUISITOS
 Requisitos do Usuário: Declarar em linguagem natural com diagramas
de serviços que o sistema oferece e suas restrições operacionais.
Escrito para os clientes;
 Requisitos do Sistema: Documentar de forma estruturada com
descrições detalhadas sobre os serviços do sistema. Contrato entre
cliente e fornecedor.

14. ORGANIZAÇÃO:
 Casos de uso;
 Manutenção de conceitos (Entidades)
 Consultas/Relatórios

15. REQUISITOS
 Requisitos funcionais: correspondem à listagem de todas as coisas –
primitivas ou atômicas – que o sistema deve fazer para bem gerir o
negócio do usuário;
 Requisitos não funcionais: são restrições que se colocam sobre como
o sistema deve realizar seus requisitos funcionais

16. EXEMPLOS DE REQUISITOS FUNCIONAIS
 [RF001] Usuário pode pesquisar todo ou um subconjunto do banco de
dados
 [RF002] Sistema deve oferecer visualizadores apropriados para o
usuário ler documentos armazenados
 [RF003] A todo pedido deve ser associado um identificador único
(PID), o qual o usuário pode copiar para a área de armazenamento
permanente da conta.

17. REQUISITOS NÃO FUNCIONAIS
 Definem propriedades e restrições do sistema (tempo, espaço, etc);
 Requisitos de processo também podem especificar o uso de
determinadas linguagens de programação, método de
desenvolvmento.

18. EXEMPLO DE REQUISITOS NÃO FUNCIONAIS.
 RFN. 3: Hardware A máquina servidora do banco de dados será a
utilizada no Laboratório de Inteligência Artificial e Automação.
 RNF.4: O sistema não pode demorar mais de 5s para realizar a
consulta a base do banco de dados.
 RNF 5: Coletar o Máximo de dados para formação da informação de
forma coerente para tomadas de decisão e estratégia de marketing
digital.

19. 2. FLUXO DE DADOS;
 O fluxo de dados é o conceito de que a mudança de
uma variável deve automaticamente forçar o recálculo dos valores de
todas as variáveis dependentes do valor da primeira.
Usa-se também o Diagrama de Fluxo de Dados (DFD) que é uma das
principais ferramentas utilizadas no projeto de sistemas de informação.
O DFD é um diagrama gráfico, baseado apenas em quatro símbolos,
que mostra a estrutura do sistema e sua fronteira, ou seja, todas as
relações entre os dados, os processos que transformam esses dados e
o limite entre o que pertence ao sistema e o que está fora dele.

20. OS SÍMBOLOS UTILIZADOS NA ELABORAÇÃO DE UM DIAGRAMA
DE FLUXO DE DADOS:

22. DIAGRAMAS:
 Diagramas de
Classe;
 Diagrama de
Objetos;
 Diagrama de caso
de uso;
 Diagrama de
Sequencia;
 Diagrama de
colaborações;
 Diagrama de
gráficos de
estados;
 Diagrama de
atividades;
 Diagrama de
Componentes
 Diagramação de
implantação
Diagrama é a
apresentação gráfica de
um conjunto de elementos
para permitir a
visualização de um
sistema sob diferentes
possibilidades:
Os principais diagramas são:

23. 3. CONCEITOS BÁSICOS DE MODELAGEM DE OBJETOS
 O paradigma da orientação a objetos, ou seja, Programação Orientada a
Objetos (POO ou OOP) eleva a programação e o desenvolvimento de
sistemas para um novo patamar.
 Vantagens:
a) Aproveitar códigos sem alterar os demais;
b) Utilização de métodos
c) Novas classes;
d) Segurança ao código;
e) Construtores próprios;
f) Portabilidade;
g) Polimorfismo.

24. ORIENTAÇÃO A OBJETOS INTRODUZ E ENFATIZA OS
CONCEITOS:
Objeto;
Classe
Mensagem
Abstração
Encapsulamento (Objetos)
Herança
Polimorfismo

25. OBJETO
 Um objeto é uma ocorrência especifica (instancia de uma classe)
Pessoa Carro Região

26. CLASSE
 Classe é a representação de um conjunto de coisas reais ou abstrata
que são reconhecidas como sendo do mesmo tipo por compartilhar
as mesmas características de atributos, operações, relações e
semântica.
 A classe pode ser representada graficamente da seguinte forma:
Nome da Classe
+Atributos: Tipo=Valor
Inicial
+Processos(Parâmetro
): Tipo Retornado
Aluno
+Nome: Char
+DataNasc: long
+Turma: Char
+Nota: Double
+Media: Double
MostrarNome():Char
CalcularMedia( ): double

27. ATRIBUTOS
 Atributo é a menor unidade que em si possui significância própria e
inter-relacionada com o conceito lógico da classe à qual pertence.
 Apresenta um principio de atomicidade, ou seja, do armazenamento
de um valor simples em célula.
 Exemplo: Um individuo possui NOME, SEXO, IDADE ETC

28. MENSAGEM
 É o estimulo (mensagem) ao objeto, acionando uma determinada
operação fazendo com que o mesmo responda ou assuma um
determinado estado:
Pedido de Venda
Esta Foto de Autor Desconhecido está
licenciado em CC BY-NC-SA
Conferencia no Estoque e entrega
Mensagem
Esta Foto de Autor
Desconhecido está
licenciado em CC
BY-NC-SA
Recebimento do
produto
OBJETO

29. ABSTRAÇÃO
 É utilizada para a definição de entidades do mundo real. Sendo onde
são criadas as classes. Essas entidades são consideradas tudo que é
real, tendo como consideração as suas características e ações
Entidade Característica Ação
Carro, Moto Tamanho, cor, peso, altura Acelerar, parar, Ligar, desligar
Elevador Tamanho, peso máximo,
social, serviço
Subir, descer, escolher andar
Conta Banco Saldo, limite, numero da conta Depositar, sacar, conferir
saldo, empréstimo

30. POLIMORFISMO
 Palavra de origem grega que significa “muitas formas”.
 Tais formas se referem aos vários comportamentos que uma mesma operação
pode assumir.
Aplicação financeira
+CalcularSaldo()
RENDA FIXA POUPANÇA FUNDO DE AÇÕES
+CalcularSaldo() +CalcularSaldo() +CalcularSaldo()

31. HERANÇA
 É a capacidade de um novo objeto tomar atributos e operações de
um objeto existente, permitindo criar classes complexas sem repetir o
código. A nova classe simplesmente herda seu nível base de
características de um antepassado na hierarquia de classe.
AUTOMÓVEL
AUTOMÓVEL
ESPORTIVO
R8 Spyder
Generalização
Especificação

32. ENCAPSULAMENTO
 Na linguagem de Programação Orientada a Objetos é importante
restringir a visibilidade de alguns atributos para garantir o conceito de
encapsulamento.
 O principal propósito do encapsulamento é a organização dos dados
que sejam relacionados, agrupando-os (encapsulando-os) em objetos
(classes), reduzindo as colisões de nomes de variáveis (dado que
variáveis com o mesmo nome estarão em namespaces distintos) e,
da mesma forma, reunindo métodos relacionados às suas
propriedades (ou variáveis de classe). Este padrão ajuda a manter
um programa com centenas ou milhares de linhas de código mais
legível e fácil de trabalhar e manter.

33. REFERÊNCIAS
 Caderno de Atividades e Trabalhos da Disciplina ANALISE e
PROJETOS ORIENTADOS A OBJETOS Professor Edson Alves 4º
Ano do Curso de Sistemas de Informação 2010.
 ftp://vm1-dca.fee.unicamp.br/pub/docs/gudwin/ea976/Requisitos.pdf
 Notas de Aulas do Curso de Pós Graduação Em Sistemas e
Desenvolvimento Web 2017 Professor Mestre Marcelo H. Santos
http://www.marcelohsantos.com.br/aulas/uninove.asp

34. OBRIGADO!
Clayton de Almeida Souza – Analista de Sistemas:
Graduado em Sistema de Informação pela Universidade Bandeirantes
de São Paulo - UNIBAN e Especialista em de Sistemas e
Desenvolvimento Web pela UNINOVE.
Contatos:
Blog: http://professorclaytonsouza.blogspot.com
E-mail: claytonn_Souza@Hotmail.com | Twitter: @claytonnsouza
Site pessoal (em breve) www.claytondeasouza.com.br