ModelagemdeSoftwareSBAv25.4.24_20240425201250

Modelagem de
software
SÃO BERNARDO DO CAMPO
Prof. Edgard L. B. Valderramas

MODELAGEM DE SOFTWARE
Modelagem de software é a atividade de construir modelos que expliquem as

características ou o comportamento de um software ou de um sistema de software.
Na construção do software os modelos podem ser usados na identificação das
características e funcionalidades que o software deverá prover (análise de requisitos), e no
planejamento de sua construção.
PLANO DE AULA
PLANO DE ENSINO
REFERÊNCIAS BÁSICAS
MEDEIROS, Ernani. Desenvolvendo Software com UML 2.0. São Paulo: Pearson Education, 2004.
https://bv4.digitalpages.com.br/?term=uml&searchpage=1&filtro=todos&from=busca&page=-
20&section=0#/legacy/2921
RAMAKRISHNAN, Raghu; GEHRKE, Johannes. Sistemas de Gerenciamento de Bancos de Dados. 3.

edição. Porto Alegre: Bookman, 2007.
https://integrada.minhabiblioteca.com.br/#/books/9788563308771/cfi/0!/4/2@100:0.00
PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software. Uma abordagem profissional. 8a. Ed.
Bookman, 2016.
REFERÊNCIAS COMPLEMENTARES
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
https://bv4.digitalpages.com.br/?term=engenharia%2520de%2520software&searchpage=1&filtro=todos&from=busca&pag
e=_14&section=0#/legacy/276
PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.
https://bv4.digitalpages.com.br/?term=engenharia%2520de%2520software&searchpage=1&filtro=todos&from=busca#/lega
cy/476
LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e
desenvolvimento iterativo. 3. ed Porto Alegre: Bookman, 2007.
FOWLER, Martin; SCOTT, Kendall. UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos.
3ª. ed. Porto Alegre: Bookman, 2004.
https://integrada.minhabiblioteca.com.br/#/books/9788560031382/cfi/6/2!/4/2@0:0.131
HEUSER, Carlos Alberto. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2011.
https://integrada.minhabiblioteca.com.br/#/books/9788577804528/cfi/0!/4/4@0.00:38.0
HORÁRIOS DE AULA
Manhã
08h50m às 09h40m
10h00m às 11h40m
Noite
19h00m às 19h50m
20h10m às 21h50m
EXEMPLO DE HORÁRIO DE AULA
Um dia especial por semana!

-Extensão, monitorias, pesquisa.
AVALIAÇÃO
30 PONTOS
A1- avaliação escrita, saber se expressar de forma escrita, de acordo com a área
30 PONTOS
A2- avaliação de múltipla escolha - ler, interpretar, correlacionar e selecionar a
alternativa correta com base na aprendizagem (citar alguns exemplos da
taxonomia de Bloom). Preparamos os estudantes para concursos e outras
oportunidades.
40 PONTOS
A3- avaliação das competências do profissional para o futuro, o aluno aprende a
solucionar problemas. Apresentação de um produto (evolução de aprendizagem
durante todo o semestre letivo)
Aprovação: 70 PONTOS
Caso não obtenha a pontuação necessária:
AI: substitui A1 ou A2 (a menor nota) e após, somam-se as novas notas
DATAS DAS AVALIAÇÕES
A1
08 e 09 de Maio – 1ª. oportunidade

24 de maio – 2ª. oportunidade
A2
11 e 12 de junho – 1ª. oportunidade

21 de junho – 2ª. Oportunidade
A3
17 a 21 de junho
DEFINIÇÃO
Professor de embasamento científico
Será o professor alocados às aulas teóricas e ele também fará a gestão da turma, em relação a conscientização
dos alunos sobre a importância de participar das rotações bem como também informar sobre a dinâmica. Também
atuará como orquestrador e ficará responsável por garantir que os professores e ambientes estejam integrados de
acordo com os objetivo estabelecidos no planejamento de aula. Este ambiente será virtual no momento de pandemia.
Professor de Aplicação prática
Professor das aulas de práticas profissionais, que acontecerá no ambiente virtual inicialmente, mas
trabalhando mais o hands on com os alunos. Este é o ambiente que primeiro retornará ao presencial, considerando o
momento de pandemia e retorno gradativo. Neste caso é importante o professor estar sincronizado com o professor de
Simulação para o desenvolvimento das mesmas competências. Importante manter as aulas gravadas, para que os alunos
possam aproveitar-se dos recursos gerados e também para que os alunos que forem grupo de risco possam acessar os
recursos gerados.
APRESENTAÇÃO
Edgard Luiz Bernardes Valderramas
edgard.Valderramas@saojudas.br
edgard.valderramas@gmail.com
11 9 8399.5726
http://lattes.cnpq.br/7160289045954459
www.linkedin.com/in/edgard-valderramas-9b6863183
APRESENTAÇÃO
Histórico acadêmico
• Bacharelado e Licenciatura em Matemática com Ênfase em PD - Fundação Santo André

• Pós-Graduação em Metodologia do Ensino Superior - Fundação Santo André
• Mestrado em Administração de Empresas - Universidade Metodista de São Paulo
• Doutorado em Tecnologias da Inteligência e Design Digital – Pontifícia Universidade Católica - SP
APRESENTAÇÃO
Histórico profissional
• Programador de Sistemas - Cofap – Cia Fabricadora de Peças

• Programador, Analista de Sistemas/ Soluções e Supervisor de Sistemas - Volkswagen do Brasil
• Account Manager e Gerente da Business Unit ERP - Finanças e RH - gedas do Brasil Ltda
• Gerente da Business Unit ERP - Finanças e RH - t-Systems do Brasil Ltda
• Professor de Sistemas de Informação, Administração, Logística e da Pós-Graduação - Fundação Santo André
• Professor das Universidade Metodista, Bandeirantes e São Judas Tadeu
• Coordenador do Curso de Sistemas de Informação - Fundação Santo André
• Vice-Diretor e Diretor da Faculdade de Filosofia, Ciências e Letras – Fundação Santo André
• Consultor nas áreas de Tecnologia da Informação, Negócios e Projetos
• Conteudista de Cursos em Educação a Distância (EAD)
• Data Protection Officer (DPO)
APRESENTAÇÃO
Autor de Livros na área de Tecnologia da Informação
• INFORMÁTICA Sem Mistérios

• DOS Sem Mistérios
• COBOL Sem Mistérios
• CLIPPER Sem Mistérios
• TURBO PASCAL Sem Mistérios
• VISUAL BASIC Sem Mistérios
• A TECNOLOGIA DA INFORMAÇÃO e o VISUAL BASIC Sem Mistérios
• A TECNOLOGIA DA INFORMAÇÃO Sem Mistérios
• REDES, SÉRIES E NÓS (CAPÍTULO)
• A COMUNICAÇÃO NO SETOR PÚBLICO E SUAS INTERSECÇÕES COM AS MÍDIAS
Fundador da SAI – SANTO ANDRÉ INFORMÁTICA
“Centro de Excelência em Treinamento de Tecnologia da Informação” ( 1998 a 2004 )
Monografias
Orientação e participação de Bancas de defesa de mais de 300 Monografias.

G1 G2 G3 G4 G5 G6
Matheus Caua Maysa Rachel Rafael Enzo
Souza Silva Silva Nunes Ferreira Lang
Brandon Vinicius Carlos Giovana Pedro Erick
Danny Teixeira Souza Amorim Vieira Gustavo
Breno Lucas Gustavo Maria Joao Pedro
Silva Henrique Silva Mendonça Ferrarezi Rafael
Kaua Andre Joao V. Rodrigo Leonardo Thomaz
Araujo Maia Carmo Perrota Fernandes Serpa
Welton Gabriel Gabriel Ryan Arthur Michel
Enocencio Maia Mendonça Faria Cruz Silva
Matheus Felipe Yasmin Giovana Andrews
Pedreti Canteiro Panteri Pereira Santos
Beatriz Angelo Joao Marcela Pietro
Muniz Almeida Gama Nonato
Lunna Caua Nicolas Murilo
Queiroz Ferreira Presença Herrera
Gabriela
Duarte
Edgard Edgard Edcleysson Edgard Edgard Edgard

G7 G8 G9 G10 G11 G12
Nathalia Tayna Giovanni Caio Lucas Lucas
Valverde Alcantara Maroni Felix Biffi Lira
Vinicius Luciana Marcio Rafael Paulo Tcharles
Irmao Maria Borba Luan Alves Ferreira
Matheus Vitor Bernardo Murilo Paulo Euller
De Lima Mutton Bruni Freitas Ricardo Venancio
Vinicius Ingrid Kaique Tomaz Erik Fernando
Alves Correia Almeida Nunes Alves Barbi
Nayara Guilherme Eduardo Gabriel Vinicius Raphaela
Barros Oliveira Lopes Santos Almeida Elias
Paulo Arthur Carlos
Amaral Turatti Benedetti
Rafael
Correa
Ok Ok
Edgard Edgard Edgard Edcleysson Edgard Edcleysson

G13 G14 G15 G16 G17 G18
Bruna de Guilherme Carlos Bruna Tiago
Oliveira Petian Eduardo Tony Pereira
Ingrid Caio de Eduardo Fernando Luiz
Lopes Oliveira Santos Todaro Felipe
Bruno Pedro Gyovana Maycon Felipe
Venancio Ricci Issoppo Gonçalves Gimenes
Miller Lucas Luiz Cibele Eduardo
Felix Ambrosio Bonitao Almeida Morales
Giovana Andre Miguel Gustavo
Perimetro Evangelista Semensato Ticianelli
Andre de Vinicius Lucas
França Coppede Nunes
Rodrigo
Mendola
Ok Ok
Edgard Edcleysson Edcleysson Edcleysson Edgard

G19 G20 G21 G22 G23 G24
Fred Andre Nathaly Ana Aleksander
Henrique Tomazoni Souza Almeida Antelo
Theo Alexandre Vitor Emily Angelo
Alves Rocha Leal Cabral Takeo
Paulo Kelvin Rodrigo Luiz Gabriel Arthur
Vinicius Rocco Roberto Fernandes Oliveira Martinoni
Matheus Daniel Victor Manuela Nycolas
Simoes Tavela Guilherme Puga Kauan
Karina Enzo Lucas Caio Kaiky
Padilha Pegarotti Cavalcante Souza Monteiro
Karoline Lorena Anthony Gabriel Lucas
Silva Pegarotti Fregoleite Climaco
Otavio Ana
Nogueira Ferreira
Maria
Pompolo
Ok Ok
Edcleysson Edcleysson Edcleysson Edcleysson Edgard Edgard

G25 G26
Henrico Alex de
Carvalho Castro
Matheus Bruno
Andre Bispo
Murilo Lucas da
Proença Silva
Victor Isabella
Melo Alves
Abdo Gustavo
Rachid
Anna C. Arthur
Silva Trindade
Edcleysson Edcleysson
Importância de um software
construído com qualidade
e erros de software
DEFINIÇÃO
“...abordagem de desenvolvimento de software

elaborada com disciplina e métodos bem definidos”
processos = paradigmas
Importância de um software construído com qualidade
Alguns exemplos...
• fácil de usar;
• funciona corretamente;
• fácil manutenção;
• mantém a integridade dos dados;
• não gera impacto econômico negativo;
• imagem.
Erros comuns na construção de um software
Alguns exemplos...
• Planejamento ineficiente;
• Não se basear em decisões técnicas;
• Desconhecer modelos
• Desconhecer ferramentas;
• Estar despreparado para mudanças
• Não dar o devido valor ao suporte;
• Não planejar as evoluções e mudanças;
• Desconhecer políticas de licenciamento;
• Interfaces com sistemas legados;
• Infraestrutura;
• Segurança.
Tipos de
software
TIPOS DE SOFTWARE
TIPOS DE SOFTWARE
Software básico ou de sistema
São programas escritos para fornecer serviços a outros programas. Geralmente executam funções de carga do
Sistema Operacional, como também o próprio Sistema Operacional. Representa a integração do Hardware e do Software.
São compostos por carregadores de inicialização, sistemas operacionais, controladores diversos e ferramentas de
diagnóstico;
Exemplos:
BIOS (Basic Input/Output System) ou Sistema Integrado de Entrada e Saída;

Interface gráfica;
Sistemas operacional Windows;
Sistemas operacional MacOs (Osx);
Sistemas Operacional Linux;
Android;
iOS;
Windows Phone;
Meego.
TIPOS DE SOFTWARE
Software utilitário
São programas que foram criados para uma demanda específica do mercado, como editores de
texto, planilhas eletrônicas, antivírus, automação de escritórios, entre outros.
Exemplos:
Notepad;
Paint;
Word;
Excel;
Powerpoint;
Avast;
McAfee
Panda.
TIPOS DE SOFTWARE
Software de linguagens de programação
São programas que permitem a criação de sistemas computacionais para atender às necessidades de
mercado. São compostos por editores específicos, compiladores, interpretadores, depuradores e ambientes IDE
(Integrated Development Environment).
Exemplos:
Cobol;
Clipper;
Visual Basic;
Java;
C#;
Python.
TIPOS DE SOFTWARE
Software aplicativo
Programas independentes que solucionam uma necessidade específica de negócio. Aplicações nessa área
processam dados comerciais ou técnicos de uma forma que facilite operações comerciais ou tomadas de decisão
administrativas/técnicas.
Exemplos:
Sistemas legados;
Aplicativos de uso geral em desktop como:
Contabilidade;
Folha de pagamento;
Contas a Pagar;
Contas a Receber;
Produção;
Compras.
Enterprise Resource Planning (ERP).
TIPOS DE SOFTWARE
Aplicações Web
Programas focados em rede, abrangendo um grande número de aplicações acessadas por uma navegador a
partir de computadores e dispositivos móveis. Também aqui se incluem as redes sociais (também denominadas de
softwares sociais por alguns autores).
Exemplos:
Home-pages;
Apps;
Orkut;
Facebook;
Instagram;
Linkedin.
TIPOS DE SOFTWARE
Softwares de Inteligência Artificial
Programas que usam algoritmos para resolver problemas complexos e interpretar dados que não podem ser
resolvidos por técnicas convencionais de computação. Aqui são utilizados conhecimento de processar grande massas de
dados (ciência da computação) e a capacidade de interpretar os seus resultados (estatística).
Exemplos:
Machine Learning;
Deep Learning.
Robótica;
Reconhecimento de padrões (imagem e voz);
Veículos autônomos;
Redes neurais.
TIPOS DE SOFTWARE
Softwares embutidos
Programas instalados nos mais variados dispositivos para que possam ser utilizados em conexões
independentemente de um computador tradicional. Residente num produto ou sistema e utilizado para implementar e
controlar características e funções para o usuário e para o próprio sistema. Executa funções limitadas e específicas (por
exemplo, controle do painel de um forno micro-ondas) ou fornece função significativa e capacidade de controle (por
exemplo, funções digitais de automóveis, tal como controle do nível de combustível, painéis de controle e sistemas de
freio).
Exemplos:
Eletrodomésticos utilizando o conceito de Internet of Things (IoT);

Smart Cities;
Computação embarcada em automóveis;
Conceito e importância dos modelos
de processo de software
Modelo de Processo Cascata

Modelo de Processo de Prototipação
Modelo de Processo Incremental
Modelo de Processo Espiral
PROCESSOS DE SOFTWARE
Conjunto de atividades que leva à produção de um produto de software (SOMMERVILLE, 2007).
Roger S. Pressman define processo de software como um arcabouço para as tarefas que são necessárias para
construir software de alta qualidade (PRESSMAN, 2006).
Processos de softwares são complexos e como todos os processos intelectuais e criativos dependem de
julgamento humano. A existência de um processo de software não garante que o software será entregue no prazo, de
que ele irá satisfazer as necessidades do cliente, ou exibirá os atributos arquiteturais que manterão as características de
qualidade em longo prazo. Um processo deve ser acoplado a uma sólida prática de engenharia de software e deve ser
avaliado para garantir que satisfaça a um conjunto de critérios básicos de processo que demonstram ser essenciais para
uma engenharia de software bem sucedida (PRESSMAN, 2006).
MODELOS DE PROCESSOS DE SOFTWARE
1. Cascata (Waterfall);
2. Evolutivo espiral;
3. Evolutivo incremental;
4. RAD (Rapid Application Development);
5. Desenvolvimento formal de sistemas;
6. Desenvolvimento evolucionário;
7. Desenvolvimento orientado a reuso;
8. Modelo em “V”;
9. Processo unificado;
10. Praxis;
11. Prototipação.
PROCESSOS DE SOFTWARE
Não existe um processo ideal. As organizações devem criar, verificar, validar e aperfeiçoar seus próprios
métodos (CMMI, 2006).
Várias destas desenvolvem abordagens inteiramente diferentes, adequadas à sua realidade, para o
desenvolvimento de software. No caso de alguns sistemas, como os sistemas críticos, é necessário um processo de
desenvolvimento muito bem estruturado. Nos sistemas de negócios, com requisitos que mudam rapidamente, um
processo flexível e ágil é provavelmente mais eficaz (SOMMERVILLE, 2007).
Existem vários processos, porém algumas atividades fundamentais são comuns a todos (SOMMERVILLE, 2007):
Especificação: define a funcionalidade do software e as restrições sobre sua operação;

Projeto e implementação: o software que atenda a especificação deve ser produzido;
Validação de software: o software deve ser validado para garantir que ela faça o que o cliente deseja;
Evolução: o software deve evoluir para atender aos novos requisitos que naturalmente surgirão.
MODELO DE PROCESSO CASCATA
Representa o desenvolvimento gradual com uma sequência ordenada de passos que devem ser seguidos
rigorosamente, no qual uma fase é executada apenas quando a anterior termina sua execução. Nesse modelo os
resultados não podem ser alterados após a fase terminar sua execução, tornando-o menos flexível que os demais
modelos.
Neste modelo não se dá inicio a fase seguinte antes que a anterior tenha sido terminada. As vantagens do
modelo cascata consistem na documentação produzida em cada fase e sua aderência a outros modelos de processos de
engenharia. Seu maior problema é a divisão inflexível do projeto em estágios distintos. Os compromissos devem ser
assumidos no estágio inicial do processo, o que torna difícil reagir às mudanças de requisitos. Este modelo pode ser
usado quando os requisitos forem bem compreendidos e houver pouca probabilidade de mudanças radicais durante o
desenvolvimento do sistema (PRESSMAN, 2006).
Engenharia
de sistemas
Análise
Projeto
Codificação
Teste
Manutenção
A origem do termo cascata (waterfall) é frequentemente citado como sendo um artigo publicado
em 1970 pelo cientista da computação W. W. Royce.
O modelo cascata também é conhecido por linear ou clássico.
W. W. Royce
1929 - 1995
MODELO DE PROCESSO ESPIRAL
Modelo que trabalha o tempo todo com riscos, dividindo o projeto em outros menores. O movimento em
espiral possui uma estrutura que dá base para se tentar chegar ao fim do projeto com todos os riscos sob controle ou
eliminados. Este modelo procura sempre dar as bases para que todos os requisitos do projeto estejam bem definidos e
entendidos por todos da equipe do Projeto. Com essa estrutura o produto vai sendo desenvolvido e com o tempo
surgem versões do software durante o seu desenvolvimento.
O modelo espiral foi desenvolvido para abranger as melhores características tanto do ciclo de vida clássico
como da prototipação, acrescentando, ao mesmo tempo, um novo elemento, a análise de riscos que falta a esses
paradigmas. O modelo define quatro importantes atividades representadas por quatro quadrantes:
1. Planejamento: determinação dos objetivos, alternativas e restrições;
2. Análise de riscos: análise de alternativas e identificação/resolução de riscos;
3. Engenharia: desenvolvimento do produto no “nível seguinte”;
4. Atualização feita pelo cliente: avaliação dos resultados da engenharia.
O modelo de ciclo de vida espiral apresentado pelo engenheiro de software Barry Boehm em 1988 combina as
características positivas da gerência (documento associado às fases do ciclo) do modelo de cascata com as fases
sobrepostas encontradas no modelo incremental e, também, com as versões anteriores de um sistema do modelo de
prototipação. O modelo em espiral parte do princípio de que a forma do desenvolvimento de software não pode ser
completamente determinada de antemão. (Pressman, 2006).
Barry Bohen
1935 -
MODELO DE PROCESSO INCREMENTAL
O Modelo Incremental surge como uma melhoria do Modelo em Cascata. Ao invés de especificar e
desenvolver tudo de uma só vez, este modelo trabalha com incrementos, ou seja, pequenos pedaços de software
entregues de cada vez. Este modelo combina elementos do Modelo em Cascata aplicados de maneira iterativa, ou seja,
de forma que o progresso aconteça através de sucessivos refinamentos, melhorados a cada iteração (PRESSMAN, 2006).
O modelo incremental segundo Pressman (2006) combina elementos do modelo cascata sendo aplicado de
maneira interativa. O modelo de processo incremental é interativo igual à prototipagem, mas diferente da prototipagem
o incremental tem como objetivo apresentar um produto operacional a cada incremento realizado. Esse modelo é muito
útil quando a empresa não possui mão de obra disponível no momento para uma implementação completa, dentro do
prazo estipulado.
SCRUM – ARTEFATOS
MODELO DE PROCESSO PROTOTIPAÇÃO
Um protótipo é uma versão inicial de um software, que é utilizada para mostrar conceitos, experimentar
opções de projeto e, em geral, para conhecer mais sobre os problemas e suas possíveis soluções.
O desenvolvimento rápido de um protótipo é essencial para que os custos sejam controlados e os usuários
possam fazer experiências com o protótipo no início do processo de software, sendo baseado nos requisitos iniciais para
o sistema.
O desenvolvimento é feito obedecendo à realização das diferentes etapas de análise de requisitos, o projeto,
a codificação e os testes.
Todos os requisitos de sistema não tem que ser completamente determinados antecipadamente e pode
mesmo ser trocada durante o curso do projeto e a entrega de prototipação clara, definições de sistema entendível e
especificações para o usuário final, tendo assim o envolvimento e satisfação do usuário final são fortemente
aumentados.
VÍDEO
https://www.youtube.com/watch?v=6_fVcpC0cxE
Conceito de Requisitos.
Requisitos Funcionais e Não-Funcionais.
A importância de Requisitos Funcionais e Não-
Funcionais em sistemas computacionais.
Elicitação, Levantamento e Análise de Requisitos.
Especificação de Requisitos.
Validação de Requisitos.
Gestão de Requisitos.
REQUISITOS DE SOFTWARE
Requisitos e funções de um Sistema computacional são coisas diferentes.
Requisitos de um software são:
a. funções;
b. objetivos;
c. propriedades;
d. restrições;
e. condições;
f. premissas.
que um Sistema deve possuir para satisfazer contratos, padrões ou especificações de acordo com o Ciente.
REQUISITOS FUNCIONAIS
Requisitos que descrevem a funcionalidade (funções que o sistema deve realizar) ou os serviços que se espera
que o sistema faça.
Os requisitos funcionais, normalmente, estão relacionados às funções de negócios do dia a dia que os usuários
executam no sistema.
Requisitos funcionais são em geral descritos por meio de diagramas de Casos de Uso e de Especificação de
Casos de Uso. Contudo, algumas vezes também são descritos na forma declarativa.
Exemplo:
O sistema de compras on-line deverá informar, por e-mail, o número do pedido ao comprador quando este
finalizar a compra.
REQUISITOS NÃO FUNCIONAIS
Os Requisitos não-funcionais não estão relacionados diretamente às funcionalidades e objetivos ao qual o
sistema que está sendo desenvolvido deve conter.
São Requisitos relacionados ao uso da sua aplicação, mas considerando outras características, como: por
exemplo:
• desempenho;
• usabilidade;
• confiabilidade;
• segurança;
• disponibilidade e;
• tecnologias empregadas;
Exemplo:
O Sistema de Conta Corrente Online deverá permitir que o usuário de Internet acesse a sua conta corrente em
menos de 5 segundos.
TAXONOMIA DE REQUISITOS NÃO FUNCIONAIS
ELICITAÇÃO
DOS REQUISITOS
ELICITAÇÃO DOS REQUISITOS
ELICITAÇÃO DOS REQUISITOS
A elicitação (levantamento) dos Requisitos ocorre durante a fase inicial do desenvolvimento de um software,
sendo repetida em todas as outras etapas da Engenharia de requisitos, que variam de acordo com a organização,
devido à sua maturidade, cultura e domínio da aplicação, mas que de uma forma geral compreende:
a. elicitação e análise de requisitos;

b. especificação de requisitos;
c. validação de requisitos;
d. documentação de requisitos.
Em um primeiro momento, identificamos os requisitos com as partes interessadas (stakeholders) por meio de
uma breve descrição, pois os mesmos influenciam direta e indiretamente no sistema que será desenvolvido.
Os requisitos são fundamentais para a modelagem, estimativa de preço, implementação, testes e também
manutenibilidade, portanto são vitais para ao ciclo de vida do software.
RESUMO
Concepção/ Levantamento Análise e Neg. Especificação Validação

Estudo de de Requisitos Requisitos Requisitos Requisitos
Viabilidade (Extração)
Relatório de Compreensão Classificação Documento de RTF

Viabilidade Domínio Requisitos/ Especificação
Prioridade
Coleta de Requisitos
(Entrevistas, Quest, JAD, ...)
- Inf. Entrevistas, Questionários,...

- Modelo de Casos de Uso
- Prototipação
LEGENDA:
Gestão de
Passos Eng. Produto Atividade Requisitos
Requisitos
ESTUDO DE VIABILIDADE
O estudo de viabilidade é um estudo breve, direcionado, que se destina a responder a algumas perguntas:
• O sistema contribui para os objetivos gerais da empresa?
• O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e prazo?
• O sistema pode ser integrado com outros sistemas já em operação?
Após responder essas questões é necessário questionar as fontes de informação (gerentes do negócio, área de TI, usuários finais,
entre outros). Para isso, são realizadas algumas perguntas, como:
• Como a empresa se comportaria, se esse sistema não fosse implementado?
• Quais são os problemas com os processos atuais e como um novo sistema ajudaria a diminuir esses problemas?
• Que contribuição direta o sistema trará para os objetivos da empresa?
• As informações podem ser transferidas para outros sistemas e também podem ser recebidas a partir deles?
• O sistema requer tecnologia que não tenha sido utilizada anteriormente na empresa?
• O que precisa e o que não precisa ser compatível com a empresa?
• Quem vai usar o sistema?

LEVANTAMENTO DE REQUISITOS
Nesta etapa deve-se descobrir mais informações sobre o domínio da aplicação, que serviços o sistema deve
oferecer, desempenho exigido, entre outros. O levantamento e análise de requisitos pode envolver diferentes tipos de
pessoas da empresa.
As técnicas de levantamento de requisitos têm por objetivo encontrar alternativas para facilita a análise e
levantamento de requisitos. As técnicas possuem um conceito próprio e suas respectivas vantagens e desvantagens, que
podem ser utilizadas em conjunto pelo analista. Algumas técnicas utilizadas:
a. entrevista;
b. questionário;
c. brainstorming;
d. JAD (Joint Application Design);
e. levantamento por pontos de vista;
f. etnografia;
g. modelo de caso de uso.
ENTREVISTA
A entrevista é uma das técnicas mais simples e antigas, mas que sempre produz bons resultados na fase inicial
de obtenção de dados.
O objetivo é o de questionar os stakeholders e descobrir quais são as suas necessidades sobre o sistema que
será desenvolvido. Existem entrevistas fechadas, com um conjunto pré-definido de perguntas e abertas, se adaptando
para explorar o conhecimento do stakeholder.
De uma maneira geral, é recomendado:
• Planejar e combinar o tempo da entrevista;
• Conhecer previamente o entrevistado;
• Delimitar o escopo da entrevista;
• Disposição para falar e ouvir;
• Ter um script prévio sobre os itens a serem abordados;
• Dar margem ao entrevistado para expor as suas ideias.
QUESTIONÁRIO
O questionário geralmente é utilizado para agilizar o tempo gasto com a resposta e quando os entrevistados
estão em locais muito distantes.
Também, pode-se utilizar o questionário para facilmente tabular as respostas e obter totais e gráficos de maneira
rápida. O questionário deve ser acompanhado por uma carta explicativa, para enfatizar a importância dessa pesquisa para
a organização.
Em relação aos tipos de questões, pode-se destacar:
• múltipla escolha;
• dicotômico;
• resposta única;
• aberta.
BRAINSTORMING
O brainstorming é uma técnica para geração de ideias, com a presença de várias pessoas em um único espaço e
com o objetivo de expor suas necessidades para que se verifique similaridade ou não com as ideias de seus parceiros de
reunião.
O brainstorming é composto pelas seguintes etapas:
• seleção prévia dos participantes;

• conhecimento da técnica a ser explorada;
• geração das ideias;
• tabulação das ideias;
• consolidação;
• divulgação.
ETNOGRAFIA
A etnografia é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais e
organizacionais, ou seja, entender a política organizacional bem como a cultura de trabalho com objetivo de familiarizar-
se com o sistema e sua história.
Nesta técnica, o analista se insere no ambiente de trabalho em que o sistema será utilizado. O trabalho diário é
observado e são anotadas as tarefas reais em que o software será utilizado.
Etnografia é particularmente eficaz nos seguintes aspectos:
• descobrir como as pessoas realmente trabalham;

• descobrir a cooperação e conscientização das atividades de outras pessoas;
• descobrir importantes detalhes que outros métodos omitem.
ANÁLISE E NEGOCIAÇÃO DE REQUISITOS
A análise e negociação categoriza e organiza os requisitos em subconjuntos relacionados. Neste passo as
seguintes perguntas devem ser respondidas.
• Cada requisito está consistente com o objetivo global do sistema?

• Todos os requisitos foram especificados no nível de abstração adequado?
• O requisito é realmente necessário ou representa algo não essencial para o objetivo do sistema?
• Cada requisito é limitado e não-ambíguo?
• Cada requisito tem atribuição? (Será utilizado por alguém)
• Algum requisito conflita com outros requisitos?
• Cada requisito é realizável no ambiente técnico?
• Cada requisito pode ser testado, quando estiver implementado?
• Qual é a prioridade desse requisito?
ESPECIFICAÇÃO DE REQUISITOS
Especificação de Requisitos, geralmente é um documento escrito, que contém o detalhamento do sistema, os
requisitos funcionais e não-funcionais e modelos do sistema que podem ser representados através de modelos (IDEF0,
modelo de casos de uso, diagramas de classes preliminar (modelo de domínio), diagramas de sequência) e prototipação.
DIAGRAMA DE CASO DE USO
A utilização do modelo de caso de uso é muito utilizado no contexto de especificação de requisitos funcionais
durante o processo de análise e levantamento.
O diagrama de caso de uso descreve as funcionalidades propostas para um novo software, sendo considerado
uma excelente ferramenta para o levantamento dos seus requisitos funcionais.
Pode-se dizer que o modelo de caso de uso descreve a sequência de eventos de um ator que usa um sistema
para realizar uma tarefa/processo.
Esse ator, que pode ser humano ou não, interage com o sistema, como por exemplo: incluir o produto, listar
pagamentos, lançar nota do Aluno, entre outros, descrevendo a sua funcionalidade, podendo incluir outra
funcionalidade ou estender outro caso de uso.
https://sites.google.com/site/hospitalprojetompoo/especificacoes-tecnicas/casos-de-uso (2020)
RF 01
RF 02
RF 03
A especificação pode conter requisitos funcionais e não-funcionais. São descritos o passo a passo de cada
funcionalidade bem como as suas devidas restrições e geralmente essa descrição é realizada por um formulário pré-
definido para esta atividade, como por exemplo:
RF 01
Nome Cadastrar funcionário
Descrição O Sistema deve inserir um novo funcionário na Base de Dados
Atores Administrador e funcionário
Prioridade Essencial
Pré-condições (a) Ter efetuado login no sistema e (b) ter permissão
Entradas Chapa, Nome e Salário
RNF associados RNF03, RNF07 e RNF12
Saídas Funcionário cadastrado no Sistema
VALIDAÇÃO DOS REQUISITOS
Após concluídas as etapas de elicitação e especificação, todos os requisitos devem ser revisados, corrigidos (se
for o caso) e validados envolvendo os stakeholders e obtendo uma assinatura de aprovação.
A validação de requisitos examina a especificação de requisitos para garantir que todos os requisitos do
sistema tenham sido identificados e detalhados e que as inconsistências, omissões, erros tenham sido detectados e
corrigidos e prioridades tenham sido estabelecidas.
RESUMO


Prioridade

- Prototipação
LEGENDA:
Gestão de
Requisitos
https://www.catho.com.br/vagas/analista-de-requisitos/
Especificação de
Requisitos
RESUMO


Prioridade

- Prototipação
LEGENDA:
Gestão de
Requisitos
Como
escrever os
requisitos
Sistema de Controle de Bomba de Insulina – exemplo do livro
Especificação em linguagem natural - Recomendações
1. Usar um formato padrão;
2. Usar realce de texto (negrito, itálico ou cor) para destacar partes importantes do
requisito.
3. Não supor que os leitores compreendam a linguagem técnica da engenharia de

software.
Especificação em linguagem natural - Exemplo
Especificação em linguagem estruturada
• quando um template é empregado para especificar requisitos funcionais;

• uma descrição das entradas e suas origens;
• uma descrição das saídas e sua destinação;
• informações sobre os dados necessários para realizar os cálculos;
• uma descrição da ação a ser tomada;
Especificação em linguagem estruturada - exemplo
A especificação pode conter requisitos funcionais e não-funcionais. São descritos o passo a passo de cada
funcionalidade bem como as suas devidas restrições e geralmente essa descrição é realizada por um formulário pré-
definido para esta atividade, como por exemplo:
RF 01
Nome Cadastrar funcionário
Descrição O Sistema deve inserir um novo funcionário na Base de Dados
Atores Administrador e funcionário
Prioridade Essencial
Pré-condições (a) Ter efetuado login no sistema e (b) ter permissão
Entradas Chapa, Nome e Salário
RNF associados RNF03, RNF07 e RNF12
Saídas Funcionário cadastrado no Sistema
VALIDAÇÃO DOS REQUISITOS
Após concluídas as etapas de elicitação e especificação, todos os requisitos devem ser revisados, corrigidos (se
for o caso) e validados envolvendo os stakeholders e obtendo uma assinatura de aprovação.
A validação de requisitos examina a especificação de requisitos para garantir que todos os requisitos do
sistema tenham sido identificados e detalhados e que as inconsistências, omissões, erros tenham sido detectados e
corrigidos e prioridades tenham sido estabelecidas.
Representa um documento no qual há a concordância do cliente em relação aos requisitos aprovados para o
desenvolvimento.
EXEMPLO
APLICADO
ENGENHARIA DE REQUISITOS
ENGENHARIA DE REQUISITOS
Levantamento Analise e negociação Especificação
a) UserId: Código a) UserId: Codigo Linguagem estruturada

b) UserId: e-Mail b) UserId: e-Mail
c) UserId: CPF c) UserId: CPF a) UserId: Codigo
d) UserId: case sensitive d) UserId: case sensitive b) Password: letras
e) Password: letras e) Password: letras c) Password: números
f) Password: números f) Password: números d) Password: case sensitive
g) Password: case sensitive g) Password: case sensitive
h) Password: @ h) Password: @
i) Password: forte/media/fraca i) Password: forte/media/fraca Linguagem natural
j) Password: troca 30 dias j) Password: troca 30 dias
k) Password: dois fatores k) Password: dois fatores a) Back-up: diário
l) Back-up: diário l) Back-up: diário b) Recovery: imediato
m) Recovery: imediato m) Recovery: imediato
RESUMO


Prioridade

- Prototipação
LEGENDA:
Gestão de
Requisitos
Perfil do usuário. Personas.
Prototipação. Fidelidade.
Ferramentas de prototipação.
ELICITAÇÃO DOS REQUISITOS DO USUÁRIO
Como coletar dados dos usuários?
• Entrevistas
• Questionários
• Grupos de Foco
• Brainstorming de Necessidades e Desejos dos Usuários
• Classificação de Cartões
• Estudos de Campo
• Investigação Contextual
PERFIL DE USUÁRIO
Podemos agrupar usuários que possuem características semelhantes, por exemplo: idade (criança,
jovem, adulto, terceira idade etc.); experiência (leigo/novato, especialista); atitudes (gosta de tecnologia,
não gosta de tecnologia); e tarefas principais (compra, venda).
A categorização de usuários em determinados perfis destaca algumas características e abstrai

outras.
PERSONA
As personas são documentos que descrevem pessoas fictícias, baseadas nos resultados de uma
pesquisa com usuários reais.
Elas podem ter perfis extremos (que trazem posições tanto positivas como negativas à proposta de
valor do seu produto ou serviço) e também médios (que refletem grupos majoritários de usuários)
representando, assim, a amplitude de características do público, mas também ressaltando particularidades
úteis ao projeto.
PERSONA
PERSONA
PERSONA
PERSONA
VÍDEO - PERSONA
https://www.youtube.com/watch?v=ylpAPNyFUPM
PROTOTIPAGEM
Demonstra as ideias e as características de funcionamento do sistema por meio de desenhos, sejam

eles rascunhos em papel ou interfaces bem próximas do real, feitas com ferramentas que permitem esboçar
a interface de uma maneira semelhante ao sistema final.
O uso de protótipos possibilita mostrar a interface, o processo de interação com funcionalidades e

botões, de uma maneira fácil de se compreender. Por meio dessa informação concreta o usuário poderá não
apenas entender, mas também contribuir com segurança, expressando o que gostou ou não, quais são as
funcionalidades fáceis e eficazes de se utilizar etc.
PROTOTIPAGEM
Segundo PRESSMAN (2002), a Prototipagem é uma estratégia utilizada tanto na área da Engenharia
de Software (ES) quanto na Interação Humano-Computador (IHC), porém para cada uma há uma finalidade
distinta em sua utilização.
Na ES, a preocupação está em como o software será desenvolvido do ponto de vista tecnológico,
compreendendo os requisitos do sistema e as funcionalidades necessárias. Já na IHC a preocupação está
relacionada com o modelo de interação entre o usuário e o sistema, ou seja, quais tarefas serão realizadas
por meio do sistema, como elas serão apresentadas, se as opções existentes estão relacionadas com o
mapeamento natural do usuário etc.
TIPOS DE PROTOTIPAGEM
Baixa fidelidade
Esses protótipos não são semelhantes ao sistema final, na maioria das vezes, são feitos com auxílio
do papel e lápis para esboçar as características iniciais da interface e o seu funcionamento. São usados
também como um auxílio na conversa entre o projetista e os usuários sobre as características desejáveis e as
soluções mais adequadas.
Por causa do tipo de material utilizado para elaborar esses protótipos, eles são mais baratos,
rápidos e fáceis de fazer e, por meio deles, é possível coletar muitas informações a respeito dos requisitos da
interface.
Baixa fidelidade
Baixa fidelidade
Pencil Project
Balsamiq
OmniGraffle
Média fidelidade
Esses protótipos são mais próximos do sistema final, se comparado com os de Baixa-Fidelidade.
Geralmente, são feitos utilizando ferramentas computacionais, embora não precisem ser as
mesmas ferramentas que serão utilizadas para desenvolver o sistema final. Permitem simular o
comportamento de interação da interface e não requerem um mesmo conhecimento técnico necessário
para implementar a interface final.
Média fidelidade
Média fidelidade
Sketch
InVision
Adobe XD
Axure RP
JustinMind
UXPin
Framer
Origami
Proto.io
Alta fidelidade
Esse tipo de protótipo oferece uma interface semelhante à final, pois são utilizadas as mesmas
matérias (software e hardware) que serão utilizadas no sistema. Os protótipos são desenvolvidos
diretamente em linguagem de programação, permitindo apresentar alguns recursos da interface com
interação.
Na prototipagem de Alta-Fidelidade já existe a implementação de algumas partes do sistema. Esse

protótipo oferece alto grau de interatividade e de realismo, pois é possível ver e interagir com uma interface
próxima à final. No entanto, há um custo maior no seu desenvolvimento e já é necessário um conhecimento
técnico semelhante àquele para desenvolver o produto final.
Alta fidelidade
Alta fidelidade
Bootstrap Studio
Pingendo
BootPly
Figma
VÍDEO – IMPORTÂNCIA E TIPOS DE PROTOTIPAGEM
https://www.youtube.com/watch?v=8YbAHNCv9-w
EXEMPLO APLICADO
TELA DE LOGIN
VÍDEO – PENCIL PROJECT
https://www.youtube.com/watch?v=15zqQR81wDQ
UML
Unified Modeling
Language
UML - DEFINIÇÃO
A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira
geração, permitindo que desenvolvedores visualizem os produtos de seus trabalhos em diagramas
padronizados.
A UML é uma linguagem gráfica para visualização, especificação, construção e documentação de

artefatos de softwares ( Furlan, 1998 ).
A UML não é uma metodologia de desenvolvimento, mas auxilia a visualizar seu desenho e a
comunicação entre os objetos da sua aplicação.
A UML recebeu influência de técnicas de modelagem de dados ( diagrama de entidade –

relacionamento ), modelagem de negócio ( workflow ) , modelagem de objetos e componentes, etc.
Visualizar, especificar, construir e documentar sistemas complexos de software são tarefas que
requerem a visualização desses sistemas sob várias perspectivas ( Booch, 2000 ).
O UML é uma representação gráfica da informação do diagrama, apesar que o diagrama

pode existir independentemente da UML.
VISÕES
Stakeholder “A”
Sponsor
Stakeholder “B”
Desenvolvedor
Stakeholder “C”
Usuário
DIAGRAMAS
A UML através de seus diagramas padrões, pode modelar a solução de um problema para a solução
através de uma arquitetura computacional em qualquer nível de complexidade.
Os diagramas demonstram as visões de um projeto de sistema computacional, através de três tipos

diferentes de diagramas :
1. estruturais
2. comportamentais
3. modelos de gerenciamento
DIAGRAMAS
diagrama ( s. m. )
1. Representação de um objecto por meio das suas linhas de contorno.

2. Delineamento.
3. Esboço.
4. Demonstração geométrica por meio de linhas.
( Priberam, 2017 )
diagrama ( sm (gr diágramma) )
Inform: técnica de diagramação usada para representação de um programa estruturado, que

mostra de uma maneira natural a visão geral do programa. D. de blocos, Inform: representação
gráfica da forma como os principais componentes de um sistema estão conectados, mas sem
detalhes
( Michaelis, 2017 )
DIAGRAMAS
Tipo de Diagrama Diagramas

1. Estruturais 1.1 Classes
1.2 Objetos
1.3 Componentes
1.4 Implantação
2. Comportamentais 2.1 Caso de Uso

2.2 Sequências
2.3 Colaboração
2.4 Estados
2.5 Atividades
3. Modelos de Gerenciamento 3.1 Pacotes

3.2 Interação
3.3 Tempo
3.4 Estrutura Composta
UML – UNIFIED MODELING LANGUAGE
https://www.youtube.com/watch?v=2dSq0Vu1GFo
SOFTWARES PARA GERAÇÃO DE DIAGRAMAS UML
1. Lucid Chart
Permite a criação de
diagramas, incluindo o UML.
A plataforma é gratuita, mas
com limitações. Fácil de usar,
com ferramentas e menus
em português. Suportando
vários tipos como diagrama
de estados, de atividades, de
casos de uso e outros. Possui
uma robusta biblioteca de
conectores.
Preços para assinantes
variam de US$ 4,95 por mês
a até US$ 20 por mês,
dependendo das funções
disponibilizadas.
2. eDraw UML
Possui ferramentas para

facilitar a criação de
diagramas UML de aparência
profissional. São
extremamente fáceis de
manusear, e possui
templates para diagrama do
modelo UML, de casos de
uso, de sequência, de
atividades, de colaboração,
de estados, de componentes,
entre muitos outros.
3. Draw.io
O Draw.io é uma ferramenta

totalmente gratuita para
criação de vários tipos de
diagramas, incluindo os
diagramas UML. O site
apresenta componentes que
se adequam à criação de
vários tipos de diagramas,
como o de sequência, de
atividades, de estados e o
tradicional caso de uso.
4. Gliffy
A disponibilidade de formas
e conectores é ampla e os
recursos oferecidos também
surpreende. Não é gratuito
(apenas versão teste por 14
dias). Seu custo varia de US$
4,99 a US$ 7,99 mensais,
dependendo do tamanho da
equipe. Disponível apenas
em inglês. Possui interface
semelhante aos programas
da suíte Office, da Microsoft.
5. yUML
Destaca-se pela forma de

construir os diagramas, pois
não é muito intuitiva, mas
pode ser útil para quem quer
complexidade e gerar
rapidamente imagens
baseadas no esquema
criado. Suporta basicamente
três tipos de diagrama: de
classes, de atividades e de
caso de uso. Possui uma
versão gratuita que atende
bem à maioria dos usuários.
A versão paga começa em
£4,70 por mês.
6. Creately
É uma ferramenta 100%

gratuita e conta com vários
recursos totalmente
disponíveis. O ambiente é
user-friendly e lembra muito
os programas da suíte Office,
da Microsoft. Embora não
tenha uma versão em
português, é fácil se achar
entre os menus e opções de
ferramentas disponibilizadas.
7. Cacoo
Permite criar vários tipos de

diagramas, incluindo os do
modelo UML. Seus preços
variam de US$ 4,95 a US$ 18
por mês. A variedade de
recursos é realmente grande,
não ficando limitado apenas
aos da especificação UML.
Possui uma grande
quantidade de templates, o
que facilita o trabalho de
quem está começando do
zero, como por exemplo:
diagrama de caso de uso, de
classes e de sequências.
8. Visual paradigm
Também possui versão

gratuita e planos pagos para
os usuários que quiserem
desfrutar de recursos
avançados. O foco não é
necessariamente os
diagramas UML, pois há
outros formatos suportados.
Porém, a variedade para o
padrão UML é bastante
grande. Possui suporte para
diagrama de caso de uso, de
classes, de sequências, de
atividades, de componentes,
de pacotes e de muitos
outros.
9. Astah
O Astah, anteriormente
denominado JUDE, é uma
ferramenta UML criado pela
empresa japonesa Change
Vision. O JUDE recebeu o
prêmio "Software Product Of
The Year 2006", pela
Information-Technology
Promotion Agency. O nome
do programa é um acrônimo
de Java and UML
Developers Environment (Am
biente para Desenvolvedores
UML e Java).
10. UMLetino
UMLetino é uma ferramenta

UML baseada em Java de
código aberto projetada para
ensinar a Unified Modeling
Language e para criar
diagramas UML
rapidamente. É uma
ferramenta de desenho em
vez de uma ferramenta de
modelagem, pois não há
dicionário ou diretório
subjacente de objetos de
design reutilizáveis. UMLet é
distribuído sob a GNU
General Public License.
11. ARGOUml
ArgoUML é uma ferramenta

UML open source para
modelar o desenho de
software de computador. A
aplicação é multiplataforma,
pois está implementada em
Java. Providencia suporte
para quase todos os tipos de
diagrama da UML padrão e
inclui suporte cognitivo.
e, sugestão de uso...
Star UML
Originalmente escrita em
Delphi, migrou para Java a
partir de 2014. A StarUML é
uma ferramenta do MKLab,
compatível com os diagramas
tradicionais: Classe, Objeto,
Caso de Uso, Componente,
Implantação, Estrutura
Composta, Sequência, entre
outros.
DIAGRAMA
DE CASO DE USO
VISÃO DE CASO DE USO
Descreve a arquitetura do sistema através do uso de Diagramas de casos de uso. Cada diagrama descreve
sequências de interações entre os objetos e processos. São usados para identificar elementos de arquitetura e ilustrar e
validar o design de arquitetura. Contém casos de uso e cenários que englobam comportamento arquiteturalmente
significativo, classes ou riscos técnicos. Ela é um subconjunto do Modelo de Caso de Uso.
Características:
a. Descreve o sistema como um conjunto de transações (funcionalidades): atores;

b. Mapeia o relacionamento das demais visões, mostrando como seus elementos interagem.
DIAGRAMA DE CASO DE USO 2. Comportamentais 2.1 Caso de Uso

2.2 Sequências
2.3 Colaboração
2.4 Estados
2.5 Atividades
Descrevem as funcionalidades do sistema percebida por atores externos , como um usuário, por exemplo
(Furlan, 1998).
Utiliza uma linguagem simples e de fácil compreensão, para que as pessoas possam ter uma ideia geral
de como o sistema irá se comportar. Identifica os atores e os serviços que o sistema disponibilizará.
(Guedes, 2004 ).

2.2 Sequências
2.3 Colaboração
2.4 Estados
2.5 Atividades

2.2 Sequências
2.3 Colaboração
2.4 Estados
2.5 Atividades
Include (Inclusão)
Quando o caso de uso A “inclui” o caso de uso B, significa que sempre que o caso de uso A for executado o
caso de uso B também será executado. A direção do relacionamento é do caso de uso que está incluindo para
o caso de uso incluído.
Extend (Extensão)
Quando o caso de uso B estende o caso de uso A, significa que quando o caso de uso A for executado o caso
de uso B poderá ser executado também. A direção do relacionamento é do caso de uso extensor (aqui o caso
de uso B) para o caso de uso estendido (aqui o caso de uso A).
Generalization (Generalizaçao ou Herança)

Quando o caso de uso B generaliza o caso de uso C isso significa que, além de fazer tudo que nele está
especificado (B), ele também executará tudo que está especificado no caso de uso C.
O caso de uso “Solicitar Material” faz include
no caso de uso “Checar Estoque”. Isso se dá
porque sempre que houver a solicitação de
material haverá a consulta ao estoque para
saber se o material está disponível.
O caso de uso “Comprar Material” estende o

caso de uso “Solicitar Material”. Isso se dá
porque quando houver a solicitação de
material, caso o material não exista em
estoque (após consulta via o caso de uso
“Checar estoque”) poderá ser solicitado a
compra do item.
O caso de uso “Comprar Material” generaliza o

caso de uso “Emitir pedido de compra”. Isso se
dá porque no caso de uso “Emitir pedido de
compra” existe especificação de como se
realiza o pedido de compra.

2.2 Sequências
2.3 Colaboração
2.4 Estados
2.5 Atividades
https://www.youtube.com/watch?v=cJyRKM5FbNM
NEXT STEPS
18/04 – Diagrama de Caso de Uso.
25/04 – Diagrama de Classes.
02/05 – Revisão para a A1.
09/05 – A1.
16/05 – Análise e Projeto de BD, Modelo e Diagrama Entidade-Relacionamento (MER e DER).
23/05 - Diagrama de Sequência + Atividades
30/05 – Aula dedicada para junção de todas as entregas em um único documento da A3.
07/06 – Revisão para a A2.
14/06 - Test-drive das apresentações.
21/06 –Expo São Judas Tadeu.
DIAGRAMA
DE CLASSES
DIAGRAMA DE CLASSES 1. Estruturais 1.1 Classes
1.2 Objetos
1.3 Componentes
1.4 Implantação
O diagrama é uma estrutura lógica em uma superfície de duas dimensões, mostrando uma coleção de
elementos declarativos de modelo, classes, tipos e seus respectivos conteúdos e relações (Furlan, 2008).
É o mais utilizado e serve de apoio para a maioria dos outros diagramas, definindo a estrutura das
classes, definindo os atributos e métodos, além de estabelecer como as classes se relacionam
(Guedes, 2004).
Essa estrutura também pode estar organizada em pacotes, mostrando somente o que é relevante,
considerando o contexto que um grupo de classes tem em comum ( estoque, venda, etc ) ou os atores
( vendedor, estoquista, etc. ) ( Lima, 2011 ).
1.2 Objetos
1.3 Componentes
1.4 Implantação
1.2 Objetos
1.3 Componentes
1.4 Implantação
https://www.youtube.com/watch?v=rDidOn6KN9k&t=561s
1.2 Objetos
1.3 Componentes
1.4 Implantação
1.2 Objetos
1.3 Componentes
1.4 Implantação
https://www.youtube.com/watch?v=guH37e4MPLs
1.2 Objetos
1.3 Componentes
1.4 Implantação
Muito
Obrigado !

ModelagemdeSoftwareSBAv25.4.24_20240425201250

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ModelagemdeSoftwareSBAv25.4.24_20240425201250

Enviado por

Direitos autorais:

Formatos disponíveis

Modelagem de

SÃO BERNARDO DO CAMPO

Prof. Edgard L. B. Valderramas

Modelagem de software é a atividade de construir modelos que expliquem as

RAMAKRISHNAN, Raghu; GEHRKE, Johannes. Sistemas de Gerenciamento de Bancos de Dados. 3.

Um dia especial por semana!

08 e 09 de Maio – 1ª. oportunidade

11 e 12 de junho – 1ª. oportunidade

Professor de Aplicação prática

Edgard Luiz Bernardes Valderramas

• Bacharelado e Licenciatura em Matemática com Ênfase em PD - Fundação Santo André

• Programador de Sistemas - Cofap – Cia Fabricadora de Peças

• INFORMÁTICA Sem Mistérios

Fundador da SAI – SANTO ANDRÉ INFORMÁTICA

“Centro de Excelência em Treinamento de Tecnologia da Informação” ( 1998 a 2004 )

Orientação e participação de Bancas de defesa de mais de 300 Monografias.

Edgard Edgard Edcleysson Edgard Edgard Edgard

Edgard Edgard Edgard Edcleysson Edgard Edcleysson

Edgard Edcleysson Edcleysson Edcleysson Edgard

Edcleysson Edcleysson Edcleysson Edcleysson Edgard Edgard

“...abordagem de desenvolvimento de software

BIOS (Basic Input/Output System) ou Sistema Integrado de Entrada e Saída;

Eletrodomésticos utilizando o conceito de Internet of Things (IoT);

Modelo de Processo Cascata

Especificação: define a funcionalidade do software e as restrições sobre sua operação;

O modelo cascata também é conhecido por linear ou clássico.

Requisitos de um software são:

a. elicitação e análise de requisitos;

Concepção/ Levantamento Análise e Neg. Especificação Validação

Relatório de Compreensão Classificação Documento de RTF

- Inf. Entrevistas, Questionários,...

• O sistema contribui para os objetivos gerais da empresa?

• O sistema pode ser integrado com outros sistemas já em operação?

• Como a empresa se comportaria, se esse sistema não fosse implementado?

• Que contribuição direta o sistema trará para os objetivos da empresa?

• O que precisa e o que não precisa ser compatível com a empresa?

• Quem vai usar o sistema?

Em relação aos tipos de questões, pode-se destacar:

O brainstorming é composto pelas seguintes etapas:

• seleção prévia dos participantes;

Etnografia é particularmente eficaz nos seguintes aspectos:

• descobrir como as pessoas realmente trabalham;

• Cada requisito está consistente com o objetivo global do sistema?

Concepção/ Levantamento Análise e Neg. Especificação Validação

Relatório de Compreensão Classificação Documento de RTF

- Inf. Entrevistas, Questionários,...

Concepção/ Levantamento Análise e Neg. Especificação Validação

Relatório de Compreensão Classificação Documento de RTF

- Inf. Entrevistas, Questionários,...

1. Usar um formato padrão;

3. Não supor que os leitores compreendam a linguagem técnica da engenharia de

• quando um template é empregado para especificar requisitos funcionais;

Levantamento Analise e negociação Especificação

a) UserId: Código a) UserId: Codigo Linguagem estruturada

Concepção/ Levantamento Análise e Neg. Especificação Validação

Relatório de Compreensão Classificação Documento de RTF

- Inf. Entrevistas, Questionários,...

Como coletar dados dos usuários?

A categorização de usuários em determinados perfis destaca algumas características e abstrai

Demonstra as ideias e as características de funcionamento do sistema por meio de desenhos, sejam

O uso de protótipos possibilita mostrar a interface, o processo de interação com funcionalidades e

Na prototipagem de Alta-Fidelidade já existe a implementação de algumas partes do sistema. Esse

A UML é uma linguagem gráfica para visualização, especificação, construção e documentação de

A UML recebeu influência de técnicas de modelagem de dados ( diagrama de entidade –