Engenharia de Software

Faculdade de Tecnologia de Jundiaí - Deputado Ary Fossen

Curso: Defesa Cibernética
Professor Dr. José Roberto Madureira Junior – jose.madureira@fatec.sp.gov.br

2024
Apresentação da Disciplina
Competências Profissionais desenvolvidas neste
componente
• Especificar os requisitos, projetar e documentar soluções de software baseadas no
conhecimento apropriado de teorias, modelos e técnicas, observando as
necessidades dos projetos.

• Modelar e implantar processos de negócio, propor soluções de TI a fim de

aumentar a competitividade das organizações.

3
Objetivos de Aprendizagem
• Identificar as características de Sistemas de Informação, seus tipos, viabilidade técnica,
características de custo, valor e qualidade da informação.

• Explicar as características de um sistema, seus componentes e relacionamentos.

• Compreender o ciclo de vida utilizando concepções do modelo cascata.

• Utilizar conceitos da UML na análise de requisitos e na elaboração de diagramas

focando na modelagem de sistemas.

4
Ementa
1. Introdução à Análise de Sistemas.
2. Modelos de Ciclo de Vida de Software.
3. Modelos de Processos de Desenvolvimento de Software (Modelo em Cascata, Espiral
e Prototipagem).
4. Definição e classificação de Requisitos de Software (funcionais e não funcionais).
5. Técnicas de Levantamento de Requisitos.
6. Modelo de Negócios aplicado ao levantamento de Requisitos (Canvas).
7. Estudo de Viabilidade.
8. Técnicas de documentação.
9. Metodologias para desenvolvimento de sistemas.

5
Metodologia proposta
• Aulas Expositivas.
• Aprendizagem Baseada em Projetos/Problemas.
• Sala de Aula Invertida.
• Estudo de Caso Real.

6
Instrumentos de avaliação
• Exercícios para prática.

• Análise e Resolução de Problemas acompanhado de rubrica de avaliação.

• Análise da documentação do projeto interdisciplinar.

• Provas.

• Projetos. Avaliação em pares e Trabalhos Interdisciplinares.

• Validação do projeto para inclusão no Portfólio Digital do aluno.

7
Bibliografia
• BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 3 ed. Rio de
Janeiro: Elsevier, 2015.

• PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software. 8 ed. São Paulo: McGraw Hill
Brasil, 2016.

• SOMMERVILLE, Ian. Engenharia de Software. 10 ed. São Paulo: Pearson Brasil, 2019.

8
Datas das avaliações
• Avaliação P1: 10/04/2024;

• Avaliação P2: 19/06/2024;

• Avaliação P3 (EXAME): 26/06/2024.

9
Introdução à Análise de Sistemas
O que é Software?
• Software é:
• Instruções (programas de computador) que, quando executadas, fornecem
recursos, funções e desempenho desejados;
• Estruturas de dados que permitem que os programas manipulem adequadamente
as informações.
• Documentação que descreve a operação e o uso dos programas.
• Software é desenvolvido ou projetado, não é fabricado no sentido clássico.
• O software não "se desgasta", mas se deteriora.
• Embora a indústria esteja caminhando para a construção baseada em
componentes, a maioria dos softwares continua sendo desenvolvida sob
medida.

11
Domínios de Aplicação do Software
• Software de sistema.
• Software de aplicação.
• Software de engenharia/científico.
• Software embarcado.
• Software de linha de produtos.
• Aplicações web/móveis.
• Software de IA (robótica, redes neurais, jogos).

12
Desgaste versus Deterioração
Aumento da taxa de defeitos
devido a efeito colaterais

Taxa de defeitos

Mudança
Curva idealizada

13
Software Legado
• Por que o software precisa mudar?
• O software precisa ser adaptado para atender às necessidades de novos
ambientes ou tecnologias de computação.
• O software precisa ser aprimorado para implementar novos requisitos comerciais.
• O software precisa ser estendido para torná-lo interoperável com outros sistemas
ou bancos de dados mais modernos.
• O software precisa ser reestruturado para torná-lo viável em um ambiente de rede.

14
Gartner Group, 2000
• Questionário aplicado à alta direção de 200 empresas de porte médio/grande,
sobre as principais falhas/dificuldades com a Informática:
• Cumprimento dos prazos 26,3%.
• Custos elevados 25,4%.
• Prioridade desenvolvimento x manutenção 25,4%.
• Manutenção dos sistemas em uso 21,1%.
• Recrutar profissionais qualificados 18,4%.

15
Definindo a Disciplina
• A definição do IEEE - Engenharia de Software:
• A aplicação de uma abordagem sistemática, disciplinada e quantificável para
o desenvolvimento, operação e manutenção de software; ou seja, a aplicação
da engenharia ao software.

16
Engenharia de software
• A engenharia de software é importante por duas razões:
1. Cada vez mais os indivíduos e a sociedade dependem de sistemas de software
avançados.
2. Geralmente é mais barato, no longo prazo, usar métodos e técnicas de
engenharia de software para sistemas de software profissionais em vez de
apenas escrever programas como um projeto de programação pessoal.
• A abordagem sistemática utilizada na engenharia de software é, às vezes,
chamada de processo de software, uma sequência de atividades que leva à
produção de um software.

17
Camadas de Engenharia de Software

Ferramentas

Métodos

Processo

Foco na qualidade

18
Atividades do Framework de Processo
• Comunicação.
• Planejamento.
• Modelagem:
• Análise de requisitos.
• Design.
• Construção:
• Geração de código.
• Testes.
• Implantação.

19
Atividades Abrangentes
• Acompanhamento e controle de projetos de software.
• Gerenciamento de riscos.
• Garantia de qualidade de software.
• Revisões técnicas.
• Medição.
• Gerenciamento de configuração de software.
• Gerenciamento de reutilização.
• Preparação e produção de produtos de trabalho.

20
Essência da Prática de Engenharia de Software
• Compreender o problema (comunicação e análise).
• Planejar uma solução (modelagem e design de software).
• Executar o plano (geração de código).
• Examinar o resultado quanto à precisão (testes e garantia de qualidade).

21
Compreender o Problema
• Quem tem interesse na solução para o problema?
• Quem são as partes interessadas?
• Quais são as incógnitas?
• Quais dados, funções e recursos são necessários para resolver
adequadamente o problema?
• O problema pode ser compartimentalizado?
• É possível representar problemas menores que possam ser mais fáceis de
entender?
• O problema pode ser representado graficamente?
• É possível criar um modelo de análise?

22
Planejar uma Solução
• Você já viu problemas semelhantes antes?
• Existem padrões que são reconhecíveis em uma solução potencial?
• Existe software existente que implementa os dados, funções e recursos
necessários?
• Um problema semelhante já foi resolvido?
• Se sim, os elementos da solução são reutilizáveis?
• É possível definir subproblemas?
• Se sim, as soluções para os subproblemas são facilmente identificáveis?
• Você pode representar uma solução de forma que leve a uma implementação
eficaz?
• É possível criar um modelo de design?
23
Executar o Plano
• A solução está de acordo com o plano?
• O código-fonte pode ser rastreado até o modelo de design?
• Cada componente da solução é provavelmente correto?
• O design e o código foram revisados ou, melhor ainda, foram aplicadas provas
de correção ao algoritmo?

24
Examinar o Resultado
• É possível testar cada componente da solução?
• Uma estratégia de teste razoável foi implementada?
• A solução produz resultados que estão de acordo com os dados, funções e
recursos necessários?
• O software foi validado em relação a todos os requisitos das partes
interessadas?

25
Princípios Gerais de Hooker
1. A Razão de Tudo Existir - fornecer valor aos usuários.
2. KISS (Mantenha-o Simples, Estúpido!) - projete o mais simples possível.
3. Manter a Visão - uma visão clara é essencial.
4. O Que Você Produz, Outros Consumirão.
5. Esteja Aberto ao Futuro - não se projete em um canto.
6. Planeje Antecipadamente para Reutilização - reduz custos e aumenta o
valor.
7. Pense! - colocar o pensamento antes da ação produz resultados.

26
Diversidade da engenharia de software
1. Aplicações stand-alone

2. Aplicações interativas baseadas em transações

3. Sistemas de controle embarcados

4. Sistemas de processamento em lotes (batch)

5. Sistemas de entretenimento

6. Sistemas para modelagem e simulação

7. Sistemas de coleta de dados e análise

8. Sistemas de sistemas

27
Engenharia de software para internet
• O reúso de software se tornou a abordagem dominante para construir sistemas
web.
• De maneira geral, hoje reconhece-se que é impraticável especificar todos os
requisitos desses sistemas antecipadamente.
• O software pode ser implementado usando engenharia de software orientada a
serviços, na qual os componentes do software são serviços da web stand-
alone.
• As tecnologias de desenvolvimento de interfaces, como AJAX e HTML5,
surgiram para dar suporte à criação de interfaces dinâmicas dentro de um
navegador web.

28
Referências complementares
Título Link
Guia SWEBOK - descreve o conhecimento geralmente aceito
https://www.computer.org/web/swebok
sobre engenharia de software da sociedade de computadores IEEE

História da Engenharia de Software – Grady Booch https://www.youtube.com/watch?v=QUz10Z1AfLc

IEEE Transações em Engenharia de Software https://www.computer.org/web/tse

Literate Programming – Ferramentas de Software Livre para

http://www.literateprogramming.com/tools.html
documentação

Futuro da Engenharia de Software https://www.youtube.com/watch?v=7T4BmRRlL2k

SimSE - ambiente educacional de simulação de engenharia https://www.ics.uci.edu/~emilyo/SimSE/downloads.ht

de software ml

29
 Modelos de Ciclo de Vida de
Software / Modelos de Processos de
Desenvolvimento de Software
Modelo Genérico de Processo
Processo de software
Metodologia de processo
Atividades de apoio
atividade metodológica no 1
ação de engenharia de software no 1.1

tarefas de trabalho
artefatos
Conjuntos de tarefas
fatores de garantia de qualidade
marcos do projeto

ação de engenharia de software no 1.k

tarefas de trabalho
Conjuntos de tarefas artefatos
fatores de garantia de qualidade
marcos do projeto

atividade metodológica no n
ação de engenharia de software no n.1

tarefas de trabalho
Conjuntos de tarefas artefatos
fatores de garantia de qualidade
marcos do projeto

ação de engenharia de software no n.m

tarefas de trabalho
artefatos
Conjuntos de tarefas fatores de garantia de qualidade
marcos do projeto

31
Fluxo de Processo
Entrega

Entrega

Entrega

Entrega

32
Identificar um Conjunto de Tarefas
• Um conjunto de tarefas define o trabalho real a ser realizado para alcançar os
objetivos de uma ação de engenharia de software.
• Um conjunto de tarefas é definido criando várias listas:
• Uma lista das tarefas a serem realizadas.
• Uma lista dos produtos de trabalho a serem produzidos.
• Uma lista dos filtros de garantia de qualidade a serem aplicados.

33
Avaliação e Melhoria de Processos
• A existência de um processo de software não garante que o software será
entregue no prazo, atenderá às necessidades do cliente ou apresentará
características de qualidade a longo prazo.
• Qualquer processo de software pode ser avaliado para garantir que atenda a
um conjunto de critérios básicos de processo que foram demonstrados como
essenciais para o sucesso da engenharia de software.
• Os processos e atividades de software devem ser avaliados usando medidas
numéricas ou análises de software (métricas).

34
Modelos de Processo Prescritivos
• Os modelos de processo prescritivos defendem uma abordagem ordenada
para a engenharia de software.
• Isso leva a duas perguntas:
• Se os modelos de processo prescritivos buscam estrutura e ordem, eles são
apropriados para um mundo de software que prospera com a mudança?
• Se rejeitarmos os modelos de processo tradicionais e os substituirmos por algo
menos estruturado, tornamos impossível alcançar coordenação e coerência no
trabalho de software?

35
Modelo de Processo Cascata
Comunicação
início do projeto
levantamento de requisitos Planejamento estimativa
cronograma
acompanhamento Modelagem
análise
projeto Construção
código
teste Implantação entrega
suporte
feedback

Prós
Contras
• É fácil de entender e planejar.
• Não se adapta bem a mudanças.
• Funciona bem para projetos pequenos e
bem compreendidos. • Os testes ocorrem tarde no processo.

• A análise e os testes são diretos. • A aprovação do cliente ocorre no final.

36
Modelo de Processo de Prototipagem
Prós
• Impacto reduzido de mudanças nos
Comunicação
Planejamento
rápido
requisitos.
• O cliente está envolvido desde cedo e
Modelagem
com frequência.
projeto rápido
• Funciona bem para projetos pequenos.
• Menor probabilidade de rejeição do
produto.
Contras
Entrega e
feedback
• O envolvimento do cliente pode causar
Construção
atrasos. Tentação de "lançar" um protótipo.
de protótipo
• Trabalho perdido em um protótipo
descartado. Difícil de planejar e gerenciar.
37
 Modelo de Processo Espiral
Prós
Modelagem
Planejamento
estimativa
análise
projeto
• Envolvimento contínuo do cliente.
cronograma
análise de riscos • Riscos de desenvolvimento são
gerenciados.
• Adequado para projetos grandes e
complexos.
• Funciona bem para produtos
Construção extensíveis.
Início
código
teste

Contras
• Falhas na análise de riscos podem levar
ao fracasso do projeto.
Comunicação • O projeto pode ser difícil de gerenciar.
Implantação
entrega • Requer uma equipe de desenvolvimento
feedback
especializada.
38
Modelo de Processo Unificado
Elaboração

Prós
Concepção
• Ênfase na documentação de qualidade.

Planejamento • Envolvimento contínuo do cliente.

Modelagem

• Acomoda mudanças nos requisitos.

• Funciona bem para projetos de manutenção.
Comunicação

Contras
Construção
• Os casos de uso nem sempre são precisos.
• Integração de incrementos de software
complicada.
• Fases sobrepostas podem causar problemas.
Entrega Construção

• Requer uma equipe de desenvolvimento

Versão especializada.
Incremento de software Transição

39
Produção
Norma NBR ISO/IEC 12207:2008
• A norma estabelece processos, atividades e tarefas que devem ser aplicados
durante a aquisição, fornecimento, desenvolvimento, operação, manutenção e
descarte de software.
• A ISO/IEC 12207 e suas adaptações apresentam definições e conceitos que
são independentes do ciclo de vida escolhido e, portanto podem ser aplicadas
a variados contextos.

40
Lidando com mudanças
• A mudança é inevitável em todos os grandes projetos de software.
• Duas abordagens relacionadas podem ser utilizadas para reduzir os custos de
retrabalho:
• Antecipação da mudança
• Tolerância à mudança
• Duas maneiras de lidar com as mudanças e com as variações nos requisitos
do sistema são:
• Prototipação do sistema
• Entrega incremental

41
Lidando com mudanças
• Desenvolvimento de um protótipo:

42
Lidando com mudanças
• Entrega incremental:

43
Melhoria de processo
• Níveis de maturidade da capacidade:

44
Referências complementares
Título Link
https://hackernoon.com/barriers-to-effective-software-effort-
Estimando o tempo de desenvolvimento de software
estimation-and-how-to-avoid-them-4abd39f09f26/
https://www.forbes.com/sites/quora/2017/12/14/what-are-some-
Melhores práticas para definir o escopo de projetos
best-practices-for-scoping-software-development-
de desenvolvimento de software
projects/#6ce3ad291bca

Modelo de Processo de Software https://www.youtube.com/watch?v=laSrDtYtkXU

Como escolher o modelo de software https://www.youtube.com/watch?v=F5fuUs7oJu0

Bugzilla https://www.bugzilla.org/

Ferramenta de desenvolvimento de software para

https://www.atlassian.com/software/jira
equipes ágeis

45
Definição e classificação de
Requisitos de Software
Finalidade de Requisitos
• Estabelecer e manter concordância com os clientes e outros envolvidos sobre o
que o sistema deve fazer.
• Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos
do sistema.
• Definir as fronteiras do sistema (ou delimitar o sistema).
• Fornecer uma base para planejar o conteúdo técnico das iterações.
• Fornecer uma base para estimar o custo e o tempo de desenvolvimento do
sistema.
• Definir uma interface de usuário para o sistema, focando nas necessidades e
metas dos usuários.

47
Custo
• Os custos relativos para localizar e reparar um erro ou defeito aumentam drasticamente
à medida que vamos da prevenção à detecção, passando pelos custos de falhas
internas e externas.

Software Engineering: A Practitioner’s

Approach, 8/e. (McGraw-Hill, 2014)

48
Engenharia de requisitos
• Requisitos de usuário e requisitos de sistema:

49
Engenharia de Requisitos
• Início - estabelecer uma compreensão básica do problema, das pessoas que
desejam uma solução e da natureza da solução desejada, é importante para
estabelecer uma comunicação efetiva entre o cliente e o desenvolvedor.
• Elicitação - obter requisitos e objetivos de negócio de todos os envolvidos.
• Elaboração - foca no desenvolvimento de um modelo refinado de requisitos
que identifica os aspectos da função do software, seu comportamento e
informações.

50
Engenharia de Requisitos
• Negociação - concordar com o escopo de um sistema entregável que seja
realista para os desenvolvedores e clientes.
• Especificação - pode ser qualquer uma ou todas as seguintes: documentos
escritos, modelos gráficos, modelos matemáticos, cenários de uso, protótipos.
• Validação - os produtos de trabalho da engenharia de requisitos produzidos
durante a engenharia de requisitos são avaliados quanto à qualidade e
consistência.
• Gestão de requisitos - conjunto de atividades de rastreabilidade para ajudar a
equipe do projeto a identificar, controlar e acompanhar os requisitos e suas
alterações à medida que o projeto avança.

51
Engenharia de requisitos
• Leitores dos diferentes tipos de especificação de requisitos:

52
Requisitos funcionais e não funcionais
1. Requisitos funcionais:
• São declarações dos serviços que o sistema deve fornecer, do modo como o sistema
deve reagir a determinadas entradas e de como deve se comportar em determinadas
situações.

2. Requisitos não funcionais:

• São restrições sobre os serviços ou funções oferecidas pelo sistema.

• Os requisitos não funcionais se aplicam, frequentemente, ao sistema como um todo, em

vez de às características individuais ou aos serviços.

53
Requisitos funcionais
• Exemplos de requisitos funcionais, utilizado para manter informações sobre
pacientes recebendo tratamento para problemas de saúde mental:
1. Um usuário deve poder fazer uma busca na lista de consultas de todas as
clínicas.
2. O sistema deve gerar, a cada dia e para cada clínica, uma lista de
pacientes que devam comparecer às consultas naquele dia.
3. Cada membro da equipe que utiliza o sistema deve ser identificado
exclusivamente por seu número de funcionário de oito dígitos.

54
Requisitos não funcionais
• Requisito Não Funcional (NFR) - atributo de qualidade, atributo de
desempenho, atributo de segurança ou restrição geral do sistema.
• Um processo de duas fases é usado para determinar quais NFRs são
compatíveis:
• A primeira fase consiste em criar uma matriz usando cada NFR como
cabeçalho de coluna e as diretrizes do sistema como rótulos de linha.
• A segunda fase é para a equipe priorizar cada NFR usando um conjunto de
regras de decisão para decidir quais implementar, classificando cada par NFR
e diretriz como complementar, sobreposto, conflitante ou independente.

55
Requisitos não funcionais
• Tipos de requisitos não funcionais:

56
Requisitos não funcionais
• Métricas para especificar requisitos não funcionais:

57
Estabelecendo as bases/fundamentos
• Identificar partes interessadas.
• "Quem mais você acha que eu deveria conversar?"
• Reconhecer múltiplos pontos de vista.
• Trabalhar em direção à colaboração.
• As primeiras perguntas.
• Quem está por trás do pedido deste trabalho?
• Quem utilizará a solução?
• Qual será o benefício econômico de uma solução bem-sucedida?
• Existe outra fonte para a solução que você precisa?

58
Qualidade de Requisitos
• Claro
• Verificável
• Completo
• Rastreável
• Classificável
• Correto
• Consistente

59
Elicitação de requisitos
• Elicitar e compreender os requisitos dos stakeholders no sistema é um
processo difícil por várias razões:
1. Muitas vezes os stakeholders não sabem o que querem de um sistema de
computador.
2. Em um sistema, é natural que os stakeholders expressem os requisitos em seus
próprios termos e com conhecimento implícito de seu próprio trabalho.
3. Diferentes stakeholders, com requisitos distintos, podem expressá-los de
maneiras variadas.
4. Fatores políticos podem influenciar os requisitos de um sistema.

60
Elicitação de requisitos
5. O ambiente econômico e de negócios no qual a análise ocorre é dinâmico.
• O processo de elicitação e análise de requisitos:

61
Coleta de Requisitos Colaborativa
• São realizadas reuniões (presenciais ou virtuais) que contam com a
participação de engenheiros de software e outras partes interessadas.
• São estabelecidas regras para preparação e participação.
• É sugerida uma agenda que seja formal o suficiente para abranger todos os
pontos importantes, mas informal o suficiente para incentivar o livre fluxo de
ideias.
• Um "facilitador" (cliente, desenvolvedor ou pessoa externa) controla a reunião.
É utilizado um "mecanismo de definição" (planilhas, flip charts, adesivos de
parede ou fórum virtual).
• O objetivo é identificar o problema, propor elementos de solução e negociar
abordagens diferentes.
62
Técnicas de elicitação de requisitos
• A elicitação dos requisitos envolve encontros com stakeholders de diferentes
tipos para descobrir informações sobre o sistema proposto.
• Existem duas abordagens fundamentais para a elicitação de requisitos:
1. entrevistas, em que há uma conversa com as pessoas a respeito do que elas
fazem;
2. observação ou etnografia, em que se observa as pessoas executando seu
trabalho para ver quais artefatos elas usam, como usam etc.

63
Histórias e cenários
• Trata-se de uma descrição de como o sistema pode ser utilizado em alguma tarefa em
particular.
• Histórias e cenários descrevem o que as pessoas fazem, quais informações usam e
produzem e quais sistemas podem adotar nesse processo.
• A diferença está no modo como as descrições são estruturadas e no nível de detalhe
apresentado.
• As histórias são escritas como texto narrativo e apresentam uma descrição de alto nível
do uso do sistema; os cenários normalmente são estruturados com informações
específicas coletadas, como entradas e saídas.

64
Especificação de requisitos
• Notações para escrever requisitos de sistema:

65
Produtos de Trabalho da Elicitação
• Declaração de necessidade e viabilidade.
• Declaração delimitada de escopo para o sistema ou produto.
• Lista de clientes, usuários e outras partes interessadas que participaram da
elicitação de requisitos.
• Descrição do ambiente técnico do sistema.
• Lista de requisitos (preferencialmente organizados por função) e as restrições
de domínio que se aplicam a cada um.
• Conjunto de cenários de uso (escritos com as próprias palavras das partes
interessadas) que fornecem insights sobre o uso do sistema ou produto em
diferentes condições de operação.

66
Definição de Caso de Uso
• Uma coleção de cenários de uso que descrevem a sequência de utilização de um
sistema.
• Cada cenário é descrito a partir do ponto de vista de um "ator" - uma pessoa ou
dispositivo que interage com o software de alguma forma.
• Cada cenário responde às seguintes perguntas:
• Quem é o ator principal, os atores secundários?
• Quais são os objetivos do ator?
• Quais pré-condições devem existir antes do início da história?
• Quais tarefas ou funções principais são realizadas pelo ator?
• Quais extensões podem ser consideradas à medida que a história é descrita?
• Quais variações na interação do ator são possíveis?
• Que informações do sistema o ator adquirirá, produzirá ou alterará?
• O ator precisará informar o sistema sobre mudanças no ambiente externo?
• Que informações o ator deseja obter do sistema?
• O ator deseja ser informado sobre mudanças inesperadas?
67
Elementos do Modelo de Análise
• O modelo de análise fornece uma descrição dos domínios informativos, funcionais e
comportamentais necessários para um sistema baseado em computador.
• Elementos baseados em cenários - descrições funcionais são expressas nas próprias
palavras dos clientes e histórias de usuário, bem como nas interações dos atores com o
sistema, expressas usando diagramas de caso de uso da UML. Elementos baseados em
classes - coleções de atributos e comportamentos implicados pelas histórias de usuário
e expressos usando diagramas de classe da UML (domínio de informações).
• Elementos comportamentais - podem ser expressos usando diagramas de estado da
UML como entradas que causam mudanças de estado.

68
Diagrama de Caso de Uso
Arma/desarma
sistema

Acessa
sistema
via Internet

Proprietário

Responde
ao eventos de
alarme

Encontra
uma condição de Sensores
erro

Reconfigura
Administrador sensores e
características
do sistema relacionadas
ao sistema

69
Diagrama de Casos de Uso UML
• Caso de uso: representado graficamente por uma elipse com o nome do caso de uso.

• Ator: representa um papel representado por uma pessoa, sistema ou dispositivo que
interage com o sistema.

70
Diagrama de Casos de Uso UML
• Associação: representa a interação entre um ator e um caso de uso.

71
Diagrama de Casos de Uso UML
• Relacionamento de inclusão: relacionamento entre casos de uso no qual um caso de
uso inclui incondicionalmente outro caso de uso.

72
Diagrama de Casos de Uso UML
• Generalização: relacionamento no qual um ator ou caso de uso possui as mesmas
características de um elemento base, mais suas características específicas.

73
Diagrama de Casos de Uso UML
• Os diagramas de casos de uso visam dois objetivos principais:
• Definição de escopo: permitem que sejam visualizadas as funcionalidades
presentes no sistema;
• Identificação de papéis: permitem identificar quem interage com o sistema e a
que funcionalidades tem acesso.
• Não permitem detalhar os passos necessários para implementação da
funcionalidade.

74
Diagrama de Classe UML
Sensor
Nome
Tipo
Localização
Área
Características

Identificar()
Habilitar()
Desativar()
Reconfigurar()
75
Diagrama de Estado UML

Comandos de Leitura

Estado do sistema = "pronto" Status do sistema = "desligado"

Mostrar msg = “Insira cmd" cmd =
Mostrar status = "estável"
desligado

Subsistemas de entrada pronto

Faça: monitorar comando de
usuário no painel Tela em branco
Faça: ler entrada dos usuário
Faça: interpretar a entrada do
usuário

76
Negociação de Requisitos
• As negociações buscam um resultado "ganha-ganha", em que as partes interessadas
ganham ao obter um produto que satisfaça a maioria de suas necessidades, e os
desenvolvedores ganham ao obter prazos alcançáveis.
• O aperto de mãos é uma forma de alcançar um resultado "ganha-ganha".

• Os desenvolvedores propõem soluções para os requisitos, descrevem seu impacto e

comunicam suas intenções aos clientes.
• Os clientes revisam as soluções propostas, focando em recursos ausentes e buscando
esclarecimentos sobre requisitos novos.
• Os requisitos são considerados suficientemente bons se os clientes aceitarem as
soluções propostas.
• O aperto de mãos tende a melhorar a identificação, análise e seleção de variantes.

77
Monitoramento de Requisitos
• Útil para o desenvolvimento incremental, inclui: Depuração distribuída - descobre erros e
determina sua causa.
• Verificação em tempo de execução - determina se o software corresponde à sua
especificação.
• Validação em tempo de execução - avalia se o software em evolução atende aos
objetivos do usuário.
• Monitoramento de atividades comerciais - avalia se um sistema atende aos objetivos
comerciais.
• Evolução e co-design - fornece informações às partes interessadas à medida que o
sistema evolui.

78
Validação de Requisitos
• Cada requisito é consistente com o objetivo geral do sistema/produto?
• Todos os requisitos foram especificados no nível apropriado de abstração? Ou
seja, alguns requisitos fornecem um nível de detalhe técnico que é inadequado
nesta fase?
• O requisito é realmente necessário ou representa um recurso adicional que
pode não ser essencial para o objetivo do sistema?
• Cada requisito é delimitado e não ambíguo?
• Cada requisito possui atribuição? Ou seja, uma fonte (geralmente, uma pessoa
específica) é indicada para cada requisito?
• Existem requisitos que entram em conflito com outros requisitos?

79
Validação de Requisitos
• Cada requisito é viável no ambiente técnico em que o sistema ou produto será
utilizado?
• Cada requisito é testável após ser implementado?
• O modelo de requisitos reflete corretamente as informações, funções e
comportamento do sistema a ser construído?
• O modelo de requisitos foi "particionado" de forma a expor informações
progressivamente mais detalhadas sobre o sistema?
• Foram utilizados padrões de requisitos para simplificar o modelo de requisitos?
• Todos os padrões foram devidamente validados?
• Todos os padrões são consistentes com os requisitos do cliente?

80
Validação de requisitos
• Uma série de técnicas de validação de requisitos pode ser utilizada individualmente
ou em conjunto:
1. Revisões de requisitos
2. Prototipação
3. Geração de casos de teste
• Não se deve subestimar os problemas envolvidos na validação dos requisitos.
• Os usuários precisam imaginar o sistema em operação e como ele se encaixaria
em seu trabalho; até para os profissionais de informática qualificados é difícil
realizar esse tipo de análise abstrata, e é ainda mais para os usuários do sistema.

81
Mudança de requisitos
• Evolução dos requisitos:

82
Planejamento do gerenciamento de requisitos
• Durante o estágio de planejamento, é preciso decidir sobre uma série de questões:
1. Identificação dos requisitos
2. Processo de gerenciamento de mudança
3. Políticas de rastreabilidade
4. Apoio de ferramentas

83
Planejamento do gerenciamento de requisitos
• É preciso de apoio de ferramentas para:
1. Armazenamento de requisitos
2. Gerenciamento de mudança
3. Gerenciamento da rastreabilidade

84
Gerenciamento de mudança de requisitos
• O gerenciamento de mudança de requisitos deve ser aplicado a todas as
mudanças propostas para os requisitos de um sistema após a aprovação do
documento de requisitos.
• Existem três estágios principais em um processo de gerenciamento de mudança:
1. Análise do problema e especificação da mudança
2. Análise da mudança e estimativa de custo
3. Implementação da mudança

85
Referências complementares
Título Link
https://www.sciencedirect.com/topics/materials-
Modelagem Funcional
science/functional-modeling

Tutorial de Diagrama de Caso de Uso UML https://www.youtube.com/watch?v=zid-MVo7M-E

Como criar um Diagrama de Sequência UML https://www.youtube.com/watch?v=pCK6prSq8aw

Lucid Chart https://www.lucidchart.com/

UML Diagrams https://www.uml-diagrams.org/

86
Técnicas de Levantamento de
Requisitos
Atividades do processo de levantamento e análise
• Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da
aplicação.
• Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para
descobrir seus requisitos.
• Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os
organiza em grupos coerentes.
• Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos
apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos.
• Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais
importantes do que outros. Esse estágio envolve interação com os stakeholders para a
definição dos requisitos mais importantes.
• Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e
consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
88
Levantamento e análise de requisitos
• O levantamento e análise de requisitos é um processo iterativo, com uma
contínua validação de uma atividade para outra.

89
Dificuldades encontradas
• Algumas das razões para o baixo grau de satisfação dos usuários para os
sistemas destacam-se:
• Na fase de levantamento de requisitos do projeto, onde não é utilizada uma técnica
adequada para extrair os requisitos do sistema.
• A falha do analista em não descrever os requisitos do sistema de modo claro, sem
ambiguidades, conciso e consistente com todos os aspectos significativos do
sistema proposto.

Quanto ao levantamento de requisitos inadequado, o resultado é

um diagnóstico pobre com conclusões comprometidas.

90
Técnicas de levantamento de requisitos
• As técnicas de levantamento de requisitos têm por objetivo superar as dificuldades
relativas a esta fase.
• Todas as técnicas possuem um conceito próprio e suas respectivas vantagens e
desvantagens, que podem ser utilizadas em conjunto pelo analista.

91
Levantamento orientado a pontos de vista
• As abordagens orientadas a ponto de vista, na engenharia de requisitos,
reconhecem os diferentes pontos de vista e os utilizam para estruturar e
organizar o processo de levantamento e os próprios requisitos.

92
Etnografia
• A etnografia é uma técnica de observação que pode ser utilizada para
compreender os requisitos sociais e organizacionais.
• O analista se insere no ambiente de trabalho em que o sistema será utilizado,
onde sua função é observar e anotar as tarefas reais em que o sistema será
utilizado.
• Alguns itens importantes que devem ser executados antes, durante e depois
do estudo de observação:
• Antes, é necessário identificar as áreas de usuário a serem observadas; obter
a aprovação das gerências apropriadas para executar as observações.
• Durante, é necessário familiarizar-se com o local de trabalho que está sendo
observado.
• Depois, é necessário documentar as descobertas resultantes das observações
feitas.

93
Workshops
• Ao contrário das reuniões, onde existe pouca interação entre todos os
elementos presentes, o workshop tem o objetivo de acionar o trabalho em
equipe.
• Uma técnica utilizada em workshops é o brainstorming.
• Após os workshops serão produzidas documentações que refletem os requisitos e
decisões tomadas sobre o sistema a ser desenvolvido.
• Alguns aspectos importantes a serem considerados: a postura do condutor do
seminário deve ser de mediador e observador; a convocação deve possuir
dia, hora, local, horário de início e de término; assunto a ser discutido e a
documentação do seminário.

94
Prototipagem
• Protótipo tem por objetivo explorar aspectos críticos dos requisitos de um
produto.
• Implementando de forma rápida um pequeno subconjunto de funcionalidades
deste produto.
• O protótipo é indicado para estudar as alternativas:
• Interface do usuário.
• Problemas de comunicação com outros produtos.
• Viabilidade de atendimento dos requisitos de desempenho.
• Alguns dos benefícios do protótipo são as reduções dos riscos na construção
do sistema.

95
Entrevistas
• Um plano de entrevista é necessário para que não haja dispersão do assunto
principal e a entrevista fique longa, não produzindo bons resultados.
• Pode-se utilizar a confirmação, para tanto o analista deve dizer ao usuário o
que acha que ouviu ele dizer.

96
Questionários
• O uso de questionário é indicado quando há diversos grupos de usuários que
podem estar em diversos locais diferentes do país.
• Existem vários tipos de questionários que podem ser utilizados, entre eles:
múltipla escolha, lista de verificação e questões objetivas.
• A distribuição deve ocorrer junto com instruções detalhadas sobre como
preenchê-lo e ser indicado claramente o prazo para devolução do questionário.

97
Brainstorming
• Brainstorming é uma técnica para geração de ideias.
• Consiste em uma ou várias reuniões que permitem que as pessoas sugiram e
explorem ideias.
• As principais etapas necessárias para conduzir uma sessão de brainstorming
são:
• Seleção dos participantes.
• Explicar a técnica e as regras a serem seguidas.
• Produzir uma boa quantidade de ideias.

98
JAD
• Joint Application Design é uma técnica para promover cooperação, entendimento e
trabalho em grupo entre os usuários desenvolvedores.
• Princípios básicos do JAD: dinâmica de grupo, uso de técnicas visuais,
manutenção do processo organizado e utilização de documentação padrão.
• Participantes do JAD:
líder da sessão, engenheiro de requisitos, executor,
representantes dos usuários, representantes de produtos de software e
especialista.

99
Levantamento de requisitos SecReq
• O objetivo do SecReq é fornecer mecanismos para rastrear os requisitos de
segurança de objetivos de segurança de alto nível para a conceção de um sistema
seguro.
• O processo de levantamento de requisitos SecReq é composto por seis passos:
1. Especificar os objetivos de segurança a partir dos objetivos do sistema e dos
requisitos funcionais.
2. Associar uma classe funcional de segurança para cada um dos objetivos de
segurança.
3. Refinar os objetivos de segurança para objetivos de segurança de maior detalhe.
4. Refinar os objetivos de segurança mais detalhados para elaborar os requisitos de
segurança.
5. Limitar os requisitos de segurança a requisitos de segurança específicos.
6. Analisar os requisitos de segurança usando o UMLsec.
100
Modelo de Negócios aplicado ao
levantamento de Requisitos
Análise de Requisitos
• Compreensão do domínio: os analistas devem desenvolver sua compreensão do domínio da
aplicação;
• Coleta de requisitos: é o processo de interagir com os stakeholders do sistema para
descobrir seus requisitos.
• Classificação: essa atividade considera o conjunto não estruturado dos requisitos e os
organiza em grupos coerentes;
• Resolução de conflitos: quando múltiplos stakeholders estão envolvidos, os requisitos
apresentarão conflitos.
• Definição das prioridades: em qualquer conjunto de requisitos, alguns serão mais
importantes do que outros.
• Verificação de requisitos: os requisitos são verificados para descobrir se estão completos e
consistentes e se estão em concordância com o que os stakeholders desejam do sistema.

102
Análise de Requisitos

103
Business Model Canvas
• O principal resultado esperado do levantamento de requisitos, a busca por
erradicar ao máximo os desalinhamentos entre o que o cliente quer, o que o cliente
precisa.
• A composição de um modelo gráfico representativo sobre o negócio em foco é
capaz de orientar e educar o profissional de forma lúdica e holística.
• Dentre as diferentes técnicas de modelagem, estão:
• BPMN (Business Process Model and Notation).
• ESSO (Environment-Strategy-Structure-Operations).
• CBM (Canvas Business Model).

104
Business Model Canvas
• Aplicado por diversas empresas do cenário mundial como a Intel, Ericsson,
Oracle e NASA.
• Canvas consiste em uma maneira simples e gráfica de descobrir, conciliar e
conectar conceitos e características importantes de um negócio.
• O funcionamento do modelo canvas baseia-se em nove blocos, são eles:
parceiros chave, atividades chave, recursos chave, proposta de valor,
relacionamento com consumidor, segmentos de consumidor, canais,
custo de estrutura e fluxo de receita.

105
Business Model Canvas

106
Preenchendo os blocos
Bloco no Canvas Original Bloco no Canvas-Req
Parceiros chave Parceiros chave
Atividades chave Atividades
Recursos chave Recursos chave
Custos Necessidades
Receita Receita
Canais Canais
Relacionamentos com o
Diferencial
consumidor
Proposta de valor Objetivo
Segmentos de consumidor Consumidor final

107
Business Model Canvas

108