Apostila Tema 1 Primeiro Bimestre

ENGENHARIA DE
SOFTWARE
Unidade 1
Modelagem de requisitos
CEO
DAVID LIRA STEPHEN BARROS
Diretora Editorial
ALESSANDRA FERREIRA
Gerente Editorial
LAURA KRISTINA FRANCO DOS SANTOS
Projeto Gráfico
TIAGO DA ROCHA
Autoria
EVERTON GOMEDE
Everton Gomede
AUTORIA
Olá. Sou formado em ciência da computação, com

mestrado, doutorado e pós-doutorado na mesma área. Tenho
experiência técnico-profissional na área de engenharia de
software de mais de 20 anos. Passei por empresas como bancos,
operadoras de cartão de crédito, fabricantes de software
nacionais e internacionais. Tenho diversas certificações e
publicações na área de computação. Sou apaixonado pelo que
faço e adoro transmitir minha experiência de vida àqueles
que estão iniciando em suas profissões. Por isso fui convidado
pela Editora Telesapiens a integrar seu elenco de autores
independentes. Estou muito feliz em poder ajudar você nesta
fase de muito estudo e trabalho. Conte comigo!
Unidade 1
ENGENHARIA DE SOFTWARE
4
ÍCONES
Unidade 1
5
Princípios que orientam a prática em engenharia de
software............................................................................................. 9
SUMÁRIO
A natureza do software.............................................................................. 9
Tipos de domínios de software............................................................... 13
Software legado.................................................................................................. 16
Engenharia de software........................................................................... 17
Entendendo os requisitos de um software............................... 20

Engenharia de requisitos.................................................................................. 20
Análise de requisitos.......................................................................................... 25
Abordagens de modelagem de requisitos..................................................... 26
Tipos de requisitos............................................................................................. 28
Unidade 1
Modelagem de requisitos de software....................................... 33

Estratégias de modelagem de requisitos....................................................... 33
Modelagem orientada a fluxo........................................................................... 33
Caso de uso......................................................................................................... 37
Diagramas de sequência................................................................................... 39
Conceitos de design de software................................................ 42

Projeto arquitetônico......................................................................................... 42
Decisões de projeto arquitetônico.................................................................. 45
Visões arquitetônicas......................................................................................... 47
Padrões de arquitetura..................................................................................... 50
6
Você sabia que a área de construção de software é uma
das mais demandadas na indústria, e será responsável pela
APRESENTAÇÃO
geração de mais de milhões de empregos nos próximos 10 anos?
Isso mesmo. A área de engenharia de software faz parte da cadeia
de processamento de dados de uma empresa. Sua principal
responsabilidade é permitir o gerenciamento de transações
de negócios bem como a utilização dos dados para tomada de
decisão. O progresso na engenharia de software nos últimos
50 anos foi surpreendente. Nossas sociedades não poderiam
funcionar sem grandes sistemas de software profissional. Serviços
públicos e infraestrutura nacionais – energia, comunicações e
transporte – dependem de sistemas de computador complexos
e confiáveis. O software nos permitiu explorar o espaço e criar
a World Wide Web – o sistema de informação mais importante
Unidade 1
da história. Smartphones e tablets são onipresentes e toda sorte
de aplicativos de software para esses dispositivos surgiu nos
últimos anos. Entendeu? Ao longo desta unidade letiva, você vai
mergulhar neste universo!
7
Olá. Seja muito bem-vindo à Unidade 1. Nosso objetivo
é auxiliar você no desenvolvimento das seguintes competências
OBJETIVOS
profissionais até o término desta etapa de estudos:
1. Definir conceitos e entender os princípios que orientam a

prática em engenharia de software.
2. Compreender os conceitos relacionados a requisitos de

software e suas aplicações.
3. Aplicar a técnica da modelagem de requisitos no processo

de engenharia de software.
4. Entender os conceitos de design e suas aplicações no

processo de engenharia de software, particularmente no
que se refere à usabilidade e experiência do usuário (User
Unidade 1
eXperience – UX).
8
Princípios que orientam a
prática em engenharia de
software
Ao término deste capítulo, você será capaz
de entender como funcionam os princípios
fundamentais de software. Isso será essencial
OBJETIVO para o exercício de sua profissão. As pessoas
que tentaram fazer isso sem a devida instrução
tiveram problemas ao construir um software
de forma profissional. E então? Motivado para
desenvolver essa competência? Vamos lá!
A natureza do software
Unidade 1
O software serve a dois propósitos (PRESSMAN, 2021). Ele
serve como meio de entrega de um produto e como o próprio
produto. Oferece como produto o poder de processamento
representado no hardware do computador ou, de forma
mais ampla, em uma rede de computadores que podem ser
acessados pelo hardware local. O software é um transformador
de informações que pode produzir, gerenciar, adquirir, modificar,
exibir ou transmitir informações.
Essas informações podem ser tão simples quanto um

único bit ou tão complexas quanto uma apresentação multimídia
feita a partir de dados coletados de várias fontes independentes,
dependendo se estão dentro de um telefone celular ou rodando
em um computador mainframe. O software serve como base
para controlar o computador (sistemas operacionais), comunicar
informações (redes) e criar e gerenciar programas adicionais,
além de servir como meio de entrega do produto (ferramentas e
ambientes de software).
9
O produto mais significativo de nosso tempo – a informação
– é fornecido por software (SOMMERVILLE, 2016). Ele gerencia
informações de negócios para aumentar a competitividade,
fornece um portal para redes globais de informações (como
a internet), transforma dados pessoais (como transações
financeiras de um indivíduo) para torná-los mais úteis em um
contexto local e fornece os meios para adquirir informações em
todas as suas formas.
Mas o que é um software? Uma possível definição

seria: (1) instruções (programas de computador)
que, quando executadas, fornecem recursos,
DEFINIÇÃO funções e desempenho desejados; (2) estruturas
de dados que permitem que os programas
manipulem adequadamente as informações e (3)
Unidade 1
informações descritivas em cópias impressas e

virtuais que descrevem a operação e o uso dos
programas (JONES, 2010).
Embora o desenvolvimento de software e a produção de

hardware compartilhem alguns paralelos, são dois processos
bastante distintos. A alta qualidade é alcançada em ambas as
atividades por meio de design, mas, no caso do hardware, podem
surgir problemas de fabricação que não estão presentes (ou são
relativamente simples de corrigir) no caso do software (BIRCHALL,
2016). A Fig. 1 mostra o ciclo de vida tradicional de um hardware.
10
Figura 1 – Ciclo de vida tradicional de um hardware
Unidade 1
Fonte: Elaborada pela autoria (2023).
Ele inicia com uma série de problemas durante o projeto.

Depois disso, ao ser levado para a operação, ele se mantém
estável por um longo período. Com o desgaste natural, ele passa
a apresentar defeitos e deve ser substituído.
A relação, também conhecida como “curva da banheira”,

mostra que o hardware apresenta taxas de falhas relativamente
altas no início de sua vida útil (essas falhas são frequentemente
causadas por falhas de projeto ou fabricação); as falhas são
corrigidas e a taxa de falhas diminui para um nível de estado
estável por um tempo (espera-se que bem baixo). A taxa de
falha, no entanto, aumenta com o tempo, pois os componentes
de hardware suportam os impactos cumulativos de poeira,
vibração, abuso, temperaturas severas e vários outros problemas
ambientais (LONG, 2021). Simplificando, o hardware começa a se
desgastar.
11
As questões ambientais que levam ao desgaste do
hardware não afetam o software. Portanto, teoricamente, a “curva
idealizada” representada na Fig. 2 deve representar a curva de
taxa de falha do software. No início da vida de um programa,
falhas não descobertas resultarão em altas taxas de falha. No
entanto, estes são fixos e, como pode ser visto, a curva achata.
Os modelos reais de falha de software são muito simplificados
pela curva imaginada (DOGLIO, 2022).
A inferência é que o software não se desgasta. No

entanto, se deteriora!
IMPORTANTE
Figura 2 – Ciclo de vida tradicional de um software

Unidade 1
Assim como o hardware, o software inicia com uma

quantidade considerável de erros. Depois disso, ele vai para a
operação e suas modificações começam a ocorrer. No entanto,
12
a cada nova mudança, uma quantidade de erros acaba sendo
inserida como efeito colateral. O trabalho de um engenheiro de
software é manter a curva de erros dentro de um valor aceitável.
O desgaste também demonstra a distinção entre

hardware e software. Uma peça sobressalente é usada para
substituir um componente de hardware desgastado. Não há peças
sobressalentes para o software. Cada falha de software aponta
para uma falha no projeto ou no método usado para converter
o projeto em código legível por máquina. Como resultado, em
comparação com a manutenção de hardware, as operações de
manutenção de software que acomodam solicitações de mudança
são muito mais difíceis.
Tipos de domínios de software
Unidade 1
Atualmente, sete grandes categorias de software de
computador apresentam desafios contínuos para engenheiros
de software.
•• O software de sistema é um grupo de aplicativos

criados para dar suporte a outros aplicativos.
Compiladores, editores e utilitários de gerenciamento
de arquivos são exemplos de software de sistema que
processa estruturas de informação complicadas, porém
fixas (PRESSMAN, 2021). Outros aplicativos de sistemas
processam principalmente dados mal definidos,
como drivers, software de rede e processadores de
telecomunicações. Em qualquer um dos cenários,
o setor de software de sistemas é caracterizado por
muita conexão de hardware, alto uso de usuários,
operação simultânea que exige compartilhamento de
recursos, agendamento e gerenciamento de processos
13
sofisticados, estruturas de dados complicadas e
inúmeras interfaces externas.
•• Aplicativos independentes que atendem a determinadas

necessidades de negócios. Os aplicativos neste campo
processam dados comerciais ou técnicos de uma forma
que apoia a tomada de decisões gerenciais ou técnicas
ou as operações da empresa (SOMMERVILLE, 2016). O
software aplicativo é usado para controlar as operações
da empresa em tempo real, além dos aplicativos padrão
de processamento de dados (por exemplo, controle do
processo de fabricação em tempo real).
•• O software para engenharia e ciência tem sido referido

como tendo algoritmos de “processamento de números”.
Unidade 1
As aplicações abrangem desde biologia molecular até

fabricação automatizada, análise de estresse automotivo
até dinâmica orbital de ônibus espaciais e desde
astronomia até vulcanologia (JONES, 2010). A engenharia
moderna e as aplicações científicas, no entanto, estão
evitando as técnicas numéricas tradicionais. Modelagem
de sistema, projeto auxiliado por computador e outras
aplicações interativas começaram a se assemelhar a
software de sistema em tempo real.
•• O software incorporado é usado para implementar

e controlar recursos e funções para o usuário final,
bem como para o próprio sistema. Está contido em
um produto ou sistema (BIRCHALL, 2016). O software
incorporado pode executar um pequeno número de
tarefas especializadas (como controlar um forno de
micro-ondas com um teclado) ou pode oferecer uma
ampla gama de recursos (como recursos automáticos
digitais, incluindo controle de combustível, visores do
painel e sistemas de frenagem).
14
•• O software de linha de produtos é criado para
oferecer um determinado recurso para uso por uma
variedade de clientes. Os produtos de controle de
estoque, por exemplo, se enquadram na categoria de
software de linha de produtos (LONG, 2021). Outras
categorias incluem processamento de texto, planilhas,
computação gráfica, multimídia, entretenimento,
gerenciamento de banco de dados e aplicativos de
finanças pessoais e comerciais.
•• Aplicativos Web, às vezes conhecidos como “WebApps”,

são uma ampla categoria de aplicativos de software
centrados em rede. WebApps podem ser nada mais do que
uma coleção de arquivos de hipertexto conectados que
Unidade 1
usam principalmente texto e pouco visual para comunicar
informações. As WebApps estão se desenvolvendo em
ambientes de computação complexos, no entanto, à
medida que a Web 2.0 se consolida (DOGLIO, 2022), esses
ambientes não apenas fornecem ao usuário final recursos
autônomos, recursos de computação e conteúdo, mas
também integração com bancos de dados corporativos e
aplicativos de negócios.
•• Para resolver questões complicadas que não são

suscetíveis ao cálculo ou análise básica, o software de
inteligência artificial usa métodos não numéricos.
Robótica, sistemas especialistas, reconhecimento de
padrões (voz e imagem), redes neurais artificiais, prova
de teoremas e jogos são exemplos de aplicações nesse
campo.
Em projetos de software em uma ou mais dessas áreas,

milhões de desenvolvedores estão atualmente trabalhando di-
ligentemente. Novos sistemas estão sendo criados em determi-
15
nadas situações, enquanto, em muitas outras, programas já exis-
tentes estão sendo corrigidos, modificados e aprimorados.
Software legado
Um dos sete grandes campos de aplicação cobertos
na parte anterior tem centenas de milhares de programas
de computador. Um software moderno que acaba de ser
disponibilizado ao público, à comunidade empresarial e ao
governo está entre eles. Mas alguns outros aplicativos são
consideravelmente mais antigos do que eles.
Grande parte dos orçamentos direcionados à

produção e distribuição de software acaba sendo
consumido pela manutenção. Isso se deve ao
Unidade 1
VOCÊ SABIA? motivo de grande parte dos programas atuais

serem legados. Isso faz com que sua manutenção
seja complexa e, consequentemente, custosa.
Infelizmente, ocasionalmente programas desatualizados

também podem ter outra falha: baixa qualidade. A lista de
problemas com sistemas legados pode ser bastante longa e incluir
arquiteturas inextensíveis, códigos complicados, documentação
inadequada ou inexistente, casos de teste e resultados que nunca
foram armazenados e históricos de mudanças mal gerenciados
(PRESSMAN, 2021). No entanto, essas tecnologias “atendem
a importantes processos de negócios e são essenciais para a
empresa”, de acordo com o comunicado.
16
Engenharia de software
Você deve estar ciente de algumas realidades básicas
para criar um software preparado para lidar com as dificuldades
do século XXI:
•• O software permeou quase todos os aspectos de nossas

vidas e, como resultado, um número crescente de
indivíduos está interessado nos recursos e serviços que
um determinado aplicativo oferece. Muitas opiniões
devem ser consideradas quando um novo aplicativo ou
sistema embarcado está sendo desenvolvido (BIRCHALL,
2016). Além disso, às vezes parece que cada um deles
tem um ponto de vista um pouco diferente sobre os
Unidade 1
recursos e serviços que o programa deve oferecer.
Portanto, antes de criar uma solução de software, um
esforço deliberado deve ser feito para compreender o
problema.
•• A cada ano que passa, os requisitos de tecnologia da

informação necessários para pessoas, organizações e
governos tornam-se mais sofisticados. Programas de
computador que antes eram criados por uma única
pessoa agora são criados por grandes equipes de
indivíduos. Hoje tudo, desde gadgets de consumo a
equipamentos médicos e sistemas de armas, contém
um software sofisticado que antes era implementado
em um ambiente de computação previsível e autônomo
(LONG, 2021). Devido à sua complexidade, todas as
interações do sistema para esses novos sistemas
e produtos baseados em computador devem ser
cuidadosamente consideradas. Consequentemente, o
design torna-se uma atividade crucial.
17
•• O software está se tornando cada vez mais importante
para as operações e controles diários, bem como para a
tomada de decisões estratégicas e táticas por pessoas,
corporações e governos. Pessoas e grandes corporações
podem sofrer desde um leve incômodo até falhas
catastróficas se o programa falhar (DOGLIO, 2022). O
software deve, portanto, ser de excelente qualidade.
•• É provável que a base de usuários e o tempo de vida de

um determinado aplicativo aumentem à medida que as
percepções de seu valor aumentam. A necessidade de
adaptação e melhoria aumentará conforme sua base de
usuários e o tempo de uso. Portanto, o software deve ser
mantido.
Unidade 1
A técnica de engenharia de software é em camadas.

Qualquer estratégia de engenharia, incluindo engenharia de
software, deve ser baseada em um compromisso organizacional
com a qualidade, conforme mostrado na Fig. 3. O gerenciamento
da qualidade total, o Seis Sigma e as teorias relacionadas
promovem uma cultura de melhoria contínua do processo, e é
essa cultura que, no final, resulta na criação de métodos cada vez
mais eficazes para a engenharia de software (BIRCHALL, 2016). O
foco na qualidade é a base da engenharia de software.
Figura 3 – Engenharia de software
QUALIDADE
MÉTODOS
PROCESSOS
FERRAMENTAS
18
Engenharia de software tem como finalidade a produção e
distribuição de software com qualidade. Todo processo de software
deve ser baseado na qualidade como objetivo final. Processos,
ferramentas e métodos suportam o alcance da qualidade.
Em resumo, engenharia de software lida com a produção

e distribuição de software com qualidade.
E então? Gostou do que lhe mostramos? Aprendeu

mesmo tudinho? Agora, só para termos certeza
de que você realmente entendeu o tema de
RESUMINDO estudo deste capítulo, vamos resumir tudo o que
vimos. Você deve ter aprendido que o software,
como qualquer outro produto de engenharia,
apresenta certas características predominantes.
Unidade 1
Por exemplo, software não se desgasta, mas
se deteriora. Além disso, software não possui
peças sobressalentes e qualquer modificação
precisa passar por um novo ciclo de engenharia.
Portanto, você deve considerar esses fatores no
desenvolvimento de qualquer software.
19
Entendendo os requisitos de
um software
Ao término deste capítulo, você será capaz de
compreender os conceitos de requisitos de
software. Isso será fundamental para o exercício
OBJETIVO de sua profissão. As pessoas que tentaram fazer
isso sem a devida instrução tiveram problemas ao
construir software de forma profissional. E então?
Motivado para desenvolver essa competência?
Vamos lá!
Engenharia de requisitos
Unidade 1
O desenvolvimento de software é um empreendimento

exigente, imaginativo e empolgante. Na verdade, o apelo da
criação de software é tão forte que muitos programadores desejam
começar sem compreender totalmente o que é necessário. Eles
afirmam que, à medida que o projeto avança, as coisas ficam
mais claras, por isso as partes interessadas do projeto só serão
capazes de entender as necessidades depois de examinar as
primeiras interações do software. Como as coisas mudam muito
rápido, tentar entender os requisitos em detalhes é inútil, o
mais importante é criar um programa funcional, sendo todo o
resto secundário (SOMMERVILLE, 2016). Esses argumentos são
persuasivos porque algumas de suas afirmações são verdadeiras.
Mas cada um tem uma falha que pode resultar em um projeto de
software errado.
A engenharia de requisitos refere-se à ampla gama

de trabalhos e métodos que ajudam a entender os requisitos
(DOGLIO, 2022). A engenharia de requisitos é uma atividade
significativa de engenharia de software que começa durante
a atividade de comunicação e continua através da atividade
20
de modelagem do ponto de vista do processo de software. Ele
precisa ser modificado para atender aos requisitos do trabalho
que está sendo feito, do projeto, do produto e do processo.
A engenharia de requisitos cria um vínculo entre

o projeto e a construção. Mas de onde vem a
ponte? Pode-se argumentar que começa com as
DEFINIÇÃO partes interessadas do projeto (gerentes, clientes
e usuários finais), que identificam a necessidade
do negócio, explicam os cenários do usuário,
delineiam funções e recursos e determinam as
limitações do projeto (PRESSMAN, 2021). Outros
podem propor começar com uma definição
mais geral de um sistema, em que o software
é apenas um elemento do domínio maior do
sistema. Independentemente do ponto de
Unidade 1
partida, cruzar a ponte eleva você bem acima
do projeto, dando-lhe a chance de examinar
seu contexto, as necessidades específicas que
o projeto e a construção devem atender, as
prioridades que determinam a sequência em
que as tarefas devem ser concluídas e as dados,
funções e comportamentos que influenciarão
significativamente o projeto final.
O mecanismo certo é fornecido pela engenharia de

requisitos para compreender as necessidades do cliente, analisar
os requisitos, determinar a viabilidade, negociar uma solução
viável, definir claramente a solução, validar a especificação
e gerenciar os requisitos à medida que são traduzidos em
um sistema operacional (LONG, 2021). Iniciação, elicitação,
elaboração, negociação, especificação, validação e gerenciamento
são as sete tarefas distintas que ele inclui. É importante observar
que algumas dessas tarefas ocorrem simultaneamente e que
cada uma é personalizada de acordo com os requisitos do
projeto.
21
•• Iniciação – quais são as etapas iniciais de um projeto
de software? A demanda por um novo sistema ou
produto baseado em computador surge de uma só
vez ou se desenvolve com o tempo? Essas perguntas
não têm respostas conclusivas. Às vezes, tudo o que é
necessário para desencadear um esforço significativo de
engenharia de software é uma simples discussão (LONG,
2021). A maioria dos projetos, no entanto, começa
quando uma necessidade da empresa é descoberta ou
um possível novo mercado ou serviço é identificado.
As partes interessadas (como gerentes de negócios,
profissionais de marketing e gerentes de produto)
desenvolvem um caso de negócios para a ideia, tentam
avaliar o tamanho e o escopo do mercado, conduzem
Unidade 1
uma análise preliminar de viabilidade e estabelecem

uma definição de escopo do projeto de trabalho.
Mesmo que todas essas informações possam mudar,
basta iniciar conversas com o grupo de engenharia de
software.
•• Elicitação – perguntar ao cliente, aos usuários e outros

sobre os objetivos do sistema ou produto, o que
precisa ser concluído, como o sistema ou produto se
encaixa nas demandas do negócio e, finalmente, como
o sistema ou produto deve ser utilizado diariamente
parece ser um processo muito simples (DOGLIO, 2022).
Mas não é fácil, realmente é um desafio.
•• Problemas com o escopo – os limites do sistema

não são claros ou os clientes ou usuários fornecem
detalhes técnicos estranhos que podem obscurecer
em vez de explicar os objetivos fundamentais do
sistema.
22
•• Problemas de compreensão – clientes e usuários
frequentemente omitem informações porque
acreditam que sejam “óbvias”, especificam
requisitos conflitantes com os de outros clientes
e usuários ou especificam requisitos que são
ambíguos ou não testáveis. Frequentemente, eles
também carecem de um entendimento completo
das capacidades e restrições de seu ambiente de
computação e do domínio do problema.
•• Problemas de volatilidade – os requisitos mudam

com o tempo.
•• Análise – durante a elaboração, as informações

coletadas do cliente durante o início e a elicitação
Unidade 1
são aprimoradas. O objetivo principal dessa atividade
é criar um modelo mais detalhado de requisitos que
especifique diferentes facetas do comportamento,
função e informação do software (BIRCHALL, 2016). O
desenvolvimento e a melhoria de cenários de usuário
que retratam como o usuário final (e outros jogadores)
irá interagir com o sistema é o que motiva a elaboração.
As classes de análise — itens de domínio de negócios
visíveis para o usuário final — são extraídas de cada
cenário de usuário por meio de análise. As características
de cada classe de análise são especificadas, juntamente
com os serviços que cada classe necessita (DOGLIO,
2022). Vários diagramas suplementares são criados
depois que as ligações e a cooperação entre as classes
são determinadas.
•• Negociação – dados os recursos limitados disponíveis

para a empresa, não é incomum que consumidores e
usuários solicitem mais do que é viável. Além disso,
não é incomum que muitos clientes ou usuários façam
23
solicitações concorrentes, cada um alegando que
sua versão é “importante para nossas necessidades
específicas”. Esses conflitos precisam ser resolvidos
por meio de um processo de negociação (PRESSMAN,
2021). Clientes, usuários e outras partes interessadas
são convidados a classificar os critérios antes de falar
sobre qualquer conflito de ordem. Os requisitos são
excluídos, consolidados e/ou ajustados usando um
processo iterativo que prioriza os requisitos, avalia seu
custo e risco e resolve disputas internas para satisfazer
cada parte até certo ponto.
•• Especificação – o termo “especificação” em relação a

sistemas baseados em computador (e software) pode
Unidade 1
significar coisas diferentes para indivíduos diferentes

(DOGLIO, 2022). Uma especificação pode ser um
relatório escrito, um grupo de representações gráficas,
um modelo matemático formal, uma coleção de casos
de uso, um protótipo ou qualquer combinação destes.
•• Validação – durante um processo de validação, os

produtos de trabalho criados como resultado da
engenharia de requisitos são avaliados quanto à
qualidade (SOMMERVILLE, 2016). Para garantir que
todos os requisitos de software foram claramente
declarados, que inconsistências, omissões e erros
foram encontrados e corrigidos e que os produtos de
trabalho estão de acordo com os padrões estabelecidos
para o processo, o projeto e o produto, a validação de
requisitos examina a especificação.
•• Gerenciamento – os sistemas baseados em computador

têm requisitos, e esses requisitos continuam a evoluir
durante o curso da existência do sistema. À medida
que o projeto avança, a equipe do projeto pode definir,
24
gerenciar e acompanhar as necessidades e mudanças
nos requisitos por meio do uso do gerenciamento de
requisitos.
Para ajudar a superar esses problemas, você deve

abordar a coleta de requisitos de maneira organizada.
Análise de requisitos
A definição dos recursos operacionais do software, a
identificação de sua interface com outros componentes do
sistema e o estabelecimento de requisitos aos quais o software
deve aderir são resultados da análise de requisitos. Quer você
se considere um engenheiro de software, analista ou modelador,
Unidade 1
a análise de requisitos permite que você elabore os requisitos
fundamentais desenvolvidos durante as tarefas de engenharia de
requisitos de concepção, elicitação e negociação (SOMMERVILLE,
2016). A ação de modelagem de requisitos resulta em um ou
mais dos seguintes tipos de modelos:
•• Modelos de requisitos baseados em cenários do ponto

de vista de vários “atores” do sistema.
•• Modelos de dados que descrevem o domínio de

informação para o problema.
•• Modelos orientados a classes que representam classes

orientadas a objetos (atributos e operações) e a
maneira pela qual as classes colaboram para atingir os
requisitos do sistema.
•• Modelos orientados a fluxo que representam os

elementos funcionais do sistema e como eles
transformam os dados conforme eles se movem pelo
sistema.
25
•• Modelos comportamentais que descrevem como o
software se comporta como consequência de “eventos”
externos.
Um designer de software pode usar o conhecimento

desses modelos para criar projetos de arquitetura, interface e
nível de componente (DOGLIO, 2022). Finalmente, a especificação
de requisitos de software e o modelo de requisitos fornecem
ao cliente e ao desenvolvedor as ferramentas para avaliar a
qualidade do software depois de desenvolvido.
O termo “domínio de aplicação particular” abrange

uma gama de setores, incluindo aviação, bancos, videogames
multimídia e software encontrado em equipamentos médicos.
Encontrar ou desenvolver classes de análise e/ou padrões de
Unidade 1
análise que sejam amplamente aplicáveis para que possam ser

reutilizados é o claro objetivo da análise de domínio.
Abordagens de modelagem de
requisitos
Em um método de modelagem de requisitos conhecido
como análise estruturada, os dados e as operações que os
transformam são tratados como entidades distintas. Os objetos
de dados são modelados para especificar suas propriedades e
conexões (DOGLIO, 2022). Os processos de manipulação de objetos
de dados são modelados para explicar como eles transformam os
dados à medida que os objetos se movem pelo sistema.
O segundo tipo de modelagem de análise, conhecido

como análise orientada a objetos, preocupa-se com a definição
de classes e como elas interagem para atender às necessidades
do cliente (BIRCHALL, 2016). O Processo Unificado e UML são
principalmente sistemas baseados em objetos.
26
As equipes de software frequentemente selecionam uma
técnica e eliminam todas as representações da outra, apesar do
fato de que o modelo de requisitos sugerido neste livro incorpora
elementos de ambas as abordagens (PRESSMAN, 2021). Qual
combinação de representações dará aos interessados o melhor
modelo de necessidades de software e o link mais eficiente
para o design de software é a verdadeira questão, não qual
representação é ideal. Pode-se observar, na Fig. 4, os quatro
tipos de abordagens para requisitos de software, baseado em
cenários, classes, comportamento e fluxos.
Figura 4 – Os quatro tipos de abordagens para requisitos de software, baseado em cenários,
classes, comportamento e fluxos
Baseados em cenários Baseados em classes
Unidade 1
Requisitos de
software
Baseado em
Baseado em fluxos
comportamentos
Eles também podem ser categorizados como estático

(baseado em classes) e dinâmico (baseado em cenários,
comportamentos e fluxos).
Cada componente do modelo de requisitos aborda a

questão de um ângulo diferente. Os componentes baseados
em cenários mostram as interações do usuário com o sistema
e o fluxo preciso de eventos que ocorrem enquanto o produto
está sendo usado (BIRCHALL, 2016). Os objetos que o sistema
controlará, as operações que serão usadas para manipular os
objetos, os relacionamentos (alguns hierárquicos) entre os objetos
e as interações entre as classes definidas são todos modelados
por elementos baseados em classe. O estado do sistema ou as
27
classes que compõem o sistema é alterado por eventos externos,
conforme demonstrado por características comportamentais
(PRESSMAN, 2021). Por fim, os componentes orientados a fluxo
mostram como o sistema transforma as informações à medida
que passam por vários processos do sistema, mostrando como
os objetos de dados passam por essa transformação.
Tipos de requisitos
Os serviços que um sistema deve oferecer e as limitações
de como ele pode operar são descritos nos requisitos de um
sistema. Essas especificações refletem as demandas dos usuários
para que um sistema realize tarefas como fazer um pedido,
gerenciar um gadget ou descobrir informações (DOGLIO, 2022).
Unidade 1
A engenharia de requisitos é a prática de

descobrir, examinar, documentar e verificar
DEFINIÇÃO esses serviços e restrições (RE).
No negócio de software, a palavra “requisito” não é usada

rotineiramente. Em algumas circunstâncias, uma necessidade
é apenas uma descrição abstrata e de alto nível de um serviço
que um sistema deve oferecer ou uma restrição a um sistema.
A definição de uma função de sistema em grande detalhe e
formalmente é o outro extremo.
Os requisitos do sistema de software são frequentemente

classificados como requisitos funcionais, não funcionais ou de
domínio.
1. Requisitos funcionais são declarações de serviços
que o sistema deve fornecer, como o sistema deve
reagir a entradas específicas e como o sistema deve se
comportar em situações específicas. Em alguns casos,
28
os requisitos funcionais também podem declarar
explicitamente o que o sistema não deve fazer.
2. Requisitos não funcionais são restrições aos serviços
ou funções oferecidas pelo sistema. Eles incluem
restrições de tempo, restrições no processo de
desenvolvimento e restrições impostas por padrões.
Os requisitos não funcionais geralmente se aplicam ao
sistema como um todo, em vez de recursos ou serviços
individuais do sistema.
3. Requisitos de domínio são regras que suportam as
decisões oferecidas pelo sistema. Eles incluem as mais
variadas decisões que podem ser expressas no formato
condição/ação. Esses requisitos classificam os sistemas
como sistemas especialistas.
Unidade 1
Grandes sistemas de software têm requisitos em
constante evolução. Esses sistemas são frequentemente criados
para lidar com problemas «perversos» – problemas que não
podem ser totalmente definidos –, o que é uma das razões para
os ajustes contínuos. Os requisitos de software inevitavelmente
estarão incompletos, porque o problema não pode ser
totalmente especificado. A percepção das partes interessadas
sobre o problema evolui constantemente durante o processo de
desenvolvimento de software.
Figura 5 – O ciclo do entendimento de um problema
Mudança no
Entendimento inicial entendimento do
Requisito inicial
do problema problema
Mudança no
Requisito modificado
requisito inicial
29
Partimos de uma visão inicial e, com isso, desenvolvemos
uma primeira versão do requisito. Depois melhoramos o
entendimento do problema, o que afeta o requisito desenvolvido.
Nesse caso, uma mudança é necessária. Quanto menor o
entendimento, maior a quantidade de mudanças.
Os requisitos do sistema devem então se adaptar para re-

fletir esse novo entendimento da situação. Novos requisitos sur-
gem invariavelmente uma vez que um sistema foi implementado
e está sendo utilizado com frequência (PRESSMAN, 2021). Isso
se deve em parte a erros e omissões nas especificações iniciais
que devem ser corrigidas. No entanto, modificações no ambiente
de negócios do sistema são a principal causa de alterações nos
requisitos do sistema.
Unidade 1
1. Após a instalação, o ambiente técnico e comercial do

sistema está sempre sujeito a alterações. Tanto o novo
hardware quanto as atualizações do hardware atual
podem ser feitas. O sistema pode exigir uma interface
com outros sistemas. Novas leis e novos regulamentos
que exijam conformidade do sistema podem ser
aprovados, e as metas de negócios podem mudar,
exigindo ajustes no suporte do sistema necessário.
2. Raramente as pessoas que pagam por um sistema e

as pessoas que o utilizam são as mesmas. Os clientes
do sistema colocam requisitos devido a restrições
financeiras e organizacionais. Para que o sistema atinja
seus objetivos, eles podem entrar em conflito com os
requisitos do usuário final, e novos recursos podem
precisar ser incorporados para suporte ao usuário após
a entrega.
3. As partes interessadas em grandes sistemas

normalmente formam um grupo diverso e têm
30
uma variedade de necessidades. Eles podem ter
prioridades opostas ou incompatíveis. Os requisitos
finais do sistema devem sempre ser um compromisso,
e é necessário dar precedência a algumas partes
interessadas. Com o tempo, verifica-se frequentemente
que as prioridades dos requisitos precisam mudar, e o
atendimento prestado aos vários stakeholders precisa
de ser ajustado.
Para avaliar os efeitos das modificações de requisitos,

você deve acompanhar os requisitos individuais e estabelecer
relacionamentos entre os requisitos dependentes (DOGLIO,
2022). Como resultado, você precisa de um procedimento
sistemático para enviar sugestões de modificação e conectá-las às
Unidade 1
necessidades do sistema. Assim que um rascunho do documento
de requisitos estiver disponível, o processo de “gerenciamento
de requisitos” deve começar.
Os requisitos não funcionais são conhecidos e

padronizados. Existe uma norma internacional
para isso. Ela pode ser acessada e utilizada como
SAIBA MAIS referência para os projetos de software. Para
entender mais, acesse o link disponível aqui.
Metodologias de desenvolvimento ágil foram criadas

para acomodar necessidades que mudam ao longo do projeto.
Quando um usuário sugere uma mudança de requisito nesses
processos, essa sugestão não passa por um processo formal
31
de gerenciamento de mudanças (DOGLIO, 2022). Em vez disso,
o usuário deve dar alta prioridade a essa modificação e deve
escolher quais recursos do sistema devem ser descartados na
próxima interação para que a alteração seja implementada.
O problema dessa estratégia é que os usuários nem

sempre são os melhores candidatos para avaliar a relação
custo-benefício de um ajuste de critério. As mudanças afetarão
algumas partes mais do que outras em sistemas com várias
partes interessadas. Frequentemente, é preferível que um
órgão imparcial decida se as mudanças devem ser permitidas,
porque elas podem equilibrar as demandas de todas as partes
envolvidas.
Unidade 1

vimos. Você deve ter aprendido que os requisitos
de software são a base para o início da construção
de qualquer software. Além disso, você deve ter
aprendido os tipos de requisitos e como eles são
desenvolvidos e gerenciados durante o ciclo de
vida do software.
32
Modelagem de requisitos de
software
Ao término deste capítulo, você será capaz de
entender como funciona a modelagem dos
requisitos de software. Isso será fundamental
OBJETIVO para o exercício de sua profissão. A modelagem
é crucial para a construção de um software bem-
feito. Além disso, a modelagem auxilia a resolver
o problema de identificar o que o software precisa
fazer. As pessoas que tentaram fazer isso sem a
devida instrução tiveram problemas ao construir
software de forma profissional. E então? Motivado
para desenvolver essa competência? Vamos lá!
Unidade 1
Estratégias de modelagem de
requisitos
A definição de classes e como elas interagem para
atender às necessidades do cliente são os principais tópicos da
análise orientada a objetos, um método diferente de análise de
modelagem (DOGLIO, 2022).
Identificar o que precisa ser feito é um dos

maiores desafios dos projetos de software. A
maior parte das vezes a dificuldade é identificar o
REFLITA problema. Dessa forma, reflita como o processo
de modelagem pode auxiliar a superar esse
desafio.
Modelagem orientada a fluxo

Embora alguns engenheiros de software vejam a
modelagem orientada a fluxo de dados como um método
ultrapassado, ela é uma das notações de análise de requisitos
33
mais populares em uso atualmente (PRESSMAN, 2021). Apesar
de não ser um componente formal da UML, o diagrama de fluxo
de dados (DFD) e os diagramas e metadados associados podem
ser usados para complementar os diagramas UML e oferecer
mais informações sobre as necessidades e o fluxo do sistema.
Os componentes estáticos do modelo de requisitos são

representados pela notação de modelagem que usamos até este
ponto. Agora é hora de mudar para o comportamento dinâmico
do sistema ou produto. Para fazer isso, você pode modelar o
comportamento do sistema em função de momentos específicos
no tempo (DOGLIO, 2022). O modelo comportamental prevê
como o software reagirá a eventos ou estímulos fora de seu
controle. Você deve executar as seguintes ações para construir
Unidade 1
o modelo:
1. Avalie todos os casos de uso para entender

completamente a sequência de interação dentro do
sistema.
2. Identifique os eventos que conduzem a sequência de

interação e entenda como esses eventos se relacionam
com objetos específicos.
3. Crie uma sequência para cada caso de uso.
4. Construa um diagrama de estado para o sistema.
5. Revise o modelo comportamental para verificar

precisão e consistência.
Os modelos são empregados durante o processo de

engenharia de requisitos para auxiliar no desenvolvimento dos
requisitos específicos de um sistema, durante a fase de projeto
para descrever o sistema aos engenheiros que o implementarão
e, após a implementação, para registrar o projeto e a
34
funcionalidade do sistema (PRESSMAN, 2021). Você pode criar
modelos do sistema atual e do que será criado.
•• Durante o processo de engenharia de requisitos,

modelos do sistema atual são empregados. Eles
ajudam a esclarecer o que o sistema atual faz e podem
ser usados para centralizar as discussões das partes
interessadas sobre suas vantagens e desvantagens.
•• Durante o processo de engenharia de requisitos, os

modelos do novo sistema são utilizados para ajudar
outras partes interessadas do sistema a entender as
necessidades propostas. Esses modelos são usados
por engenheiros para discutir ideias de projeto e para
descrever o sistema antes de colocá-lo em uso. Uma
Unidade 1
implementação de sistema completa ou parcial pode
ser criada a partir de modelos de sistema se você
empregar um processo de engenharia orientado a
modelo.
É crucial perceber que um modelo de sistema não é uma

descrição precisa do sistema. Para tornar as coisas mais simples
de entender, ele omite propositalmente algumas informações
(DOGLIO, 2022). Em vez de ser outra representação do sistema
em estudo, um modelo é uma abstração dele. Todos os detalhes
sobre o sistema que está sendo representado devem ser
mantidos na representação. Uma abstração destaca os recursos
mais importantes de um projeto de sistema e o simplifica
propositadamente.
Você pode desenvolver diferentes modelos para

representar o sistema de diferentes perspectivas. Por exemplo:
•• Uma perspectiva externa, em que você modela o

contexto ou ambiente do sistema.
35
•• Uma perspectiva de interação, em que você modela as
interações entre um sistema e seu ambiente ou entre
os componentes de um sistema.
•• Uma perspectiva estrutural, em que você modela a

organização de um sistema ou a estrutura dos dados
processados pelo sistema.
•• Uma perspectiva comportamental, em que você modela

o comportamento dinâmico do sistema e como ele
responde a eventos.
Frequentemente, você pode ser versátil em como a

notação gráfica é empregada ao criar modelos de sistema. Nem
sempre é necessário aderir estritamente às especificidades de
Unidade 1
uma notação (LONG, 2021). Dependendo de como você deseja

usar um modelo, ele variará em detalhes e rigor. Os usos mais
comuns de modelos gráficos são os seguintes:
1. Diagramas de atividades, que mostram as atividades

envolvidas em um processo ou no processamento de
dados.
2. Diagramas de caso de uso, que mostram as interações

entre um sistema e seu ambiente.
3. Diagramas de sequência, que mostram as interações

entre os atores e o sistema e entre os componentes do
sistema.
4. Diagramas de classes, que mostram as classes de

objetos no sistema e as associações entre essas classes.
5. Diagramas de estado, que mostram como o sistema

reage a eventos internos e externos.
36
Caso de uso
Um caso de uso pode ser pensado como uma explicação
direta do que um usuário espera de um sistema durante
esse encontro. Cada caso de uso ilustra uma tarefa distinta
envolvendo interação externa com um sistema. Um caso de uso
é representado em sua forma mais básica como uma elipse, com
os atores envolvidos como bonequinhos, representada na figura
seguinte por um caso de uso do sistema. Em vez das informações
detalhadas sobre cada consulta que são mantidas no sistema,
esse sistema mais abrangente preserva dados resumidos sobre
um paciente.
Pode ser um desafio determinar quanto teste
Unidade 1
de sistema é necessário para um determinado
sistema e quando terminar o teste. É impossível
IMPORTANTE realizar testes exaustivos, nos quais todos os
cenários concebíveis de execução do programa
são examinados. O teste deve, portanto, ser
baseado em uma gama limitada de cenários de
teste potenciais. As empresas de software devem,
idealmente, ter diretrizes para selecionar esse
subconjunto. Esses regulamentos podem ser
baseados em regulamentos de teste genéricos,
como a exigência de que cada instrução de
programa seja executada pelo menos uma vez.
Como alternativa, eles podem se basear na
experiência de uso do sistema e se concentrar
em testar os aspectos do sistema operacional.
37
Figura 6 – Caso de uso básico
Registrar
Remover
Visualizar
Recepcionista
Transferir
Contactar
Unidade 1
Uma variedade de construções na UML permite que você

reutilize todo ou parte de um caso de uso em vários diagramas
de casos de uso (SOMMERVILLE, 2016). Apesar do fato de
que essas construções podem ocasionalmente ser úteis para
projetistas de sistemas, em minha experiência, muitos indivíduos,
especialmente usuários finais, acham difícil compreendê-las.
Como resultado, essas estruturas não são descritas aqui.
38
Diagramas de sequência
Na UML, os diagramas de sequência são geralmente
usados para modelar interações entre objetos individuais, bem
como interações entre atores e objetos em um sistema (DOGLIO,
2022).
O rico vocabulário da UML para diagramas de

sequência torna possível modelar uma ampla
variedade de interações. A ênfase estará nos
IMPORTANTE fundamentos desse tipo de diagrama porque
não há espaço suficiente para discutir todas as
possibilidades aqui.
A linguagem unificada de modelagem é um
Unidade 1
padrão internacional utilizado por engenheiros
de software ao redor do mundo. Ela foi criada
VOCÊ SABIA? como uma resposta à forma improvisada de
modelagem de requisitos de software. Para
entender mais, acesse o link disponível aqui.
Um diagrama de sequência, como o nome sugere, retrata

as interações que acontecem na ordem em que acontecem
durante um caso de uso específico ou instância de caso de uso
(DOGLIO, 2022). Um exemplo de diagrama de sequência que
demonstra os fundamentos da notação é mostrado na figura a
seguir. Esse gráfico representa as interações no caso de uso para
visualizar informações do paciente, nas quais um funcionário da
recepção médica pode visualizar alguns dados do paciente.
39
Figura 7 – Exemplo de diagrama de sequência
Unidade 1
Uma linha pontilhada é criada verticalmente a partir da

lista de itens e atores envolvidos na parte superior do gráfico.
Setas com anotações mostram como coisas diferentes interagem
(PRESSMAN, 2021). A linha de vida do objeto é indicada pelo
retângulo nas linhas pontilhadas (ou seja, o tempo que a instância
do objeto está envolvida na computação). Você lê as interações
em ordem, de cima para baixo. As chamadas para os objetos,
seus parâmetros e seus valores de retorno são mostrados pelas
anotações nas setas. A sintaxe usada para indicar alternativas
também é demonstrada neste exemplo. Com opções de
interação alternativas separadas por uma linha pontilhada, uma
caixa chamada “alt” é utilizada com as condições mostradas entre
colchetes.
40
E então? Gostou do que lhe mostramos?
Aprendeu mesmo tudinho? Agora, só para
termos certeza de que você realmente entendeu
RESUMINDO o tema de estudo deste capítulo, vamos resumir
tudo o que vimos. Você deve ter aprendido
sobre como modelar requisitos de software. Isso
tende a ser um desafio, pois no início do projeto
temos pouca informação e a tendência é tentar
escrever código sem entender o problema a ser
resolvido primeiramente. Além disso, você deve
ter aprendido os tipos de abordagem e como eles
são usados e gerenciados durante o ciclo de vida
do software.
Unidade 1
41
Conceitos de design de software
Ao término deste capítulo, você será capaz
de entender como funcionam os princípios
fundamentais de software. Isso será fundamental
OBJETIVO para o exercício de sua profissão. As pessoas
que tentaram fazer isso sem a devida instrução
tiveram problemas ao construir software de forma
profissional. E então? Motivado para desenvolver
essa competência? Vamos lá!
Compreender a melhor maneira de organizar um sistema

de software e criar sua estrutura geral são aspectos do projeto
arquitetônico. A etapa de projeto arquitetônico do processo
de projeto de software é a primeira no modelo do processo de
Unidade 1
desenvolvimento de software (LONG, 2021). Como determina

os principais componentes estruturais de um sistema e seus
relacionamentos, a engenharia de requisitos serve como o elo
crucial entre o projeto e a engenharia de requisitos. A estrutura
organizacional de um sistema como uma coleção de componentes
interconectados é descrita em um modelo de arquitetura, que é
o resultado do processo de projeto de arquitetura.
Projeto arquitetônico
Observe a figura a seguir para ver o que quero dizer quando
falo sobre arquitetura de sistema. Uma representação abstrata
da arquitetura de um sistema de robô de embalagem é mostrada
nesse diagrama. Esse sistema robótico é capaz de embalar
uma variedade de coisas. Ele seleciona itens em uma esteira,
determina o tipo de item e escolhe a embalagem apropriada,
tudo usando um componente de visão (SOMMERVILLE, 2016).
Depois disso, o sistema transporta os itens da esteira de entrega
para embalagem. Ele carrega mercadorias embaladas em um
42
transportador diferente. Esses elementos e as conexões entre
eles são exibidos no modelo arquitetônico.
Figura 8 – Exemplo de arquitetura de software
Sistema de visão
Sistema de Sistema de
Sistema de
identificação de controle de roda
controle braço
objetos
Sistema de controle
de pacotes
Unidade 1
Sistema de
Controle de
pacotes
esteira
Podemos considerar que a arquitetura de software é

a decomposição da solução em partes menores e facilmente
gerenciáveis. Isso é o bom e velho dividir para conquistar. A
dificuldade ocorre quando esses problemas menores interagem.
Isso gera um fenômeno conhecido como comportamento
emergente, que é muito difícil de prever.
O projeto arquitetônico e os procedimentos de

engenharia de requisitos frequentemente se sobrepõem na
prática. Idealmente, uma especificação de sistema não deve
conter nenhum dado de projeto (LONG, 2021). Mas, a menos
que você esteja falando de sistemas muito pequenos, esse ideal
43
não é realista. Os elementos arquitetônicos primários devem
ser reconhecidos, pois representam os recursos de alto nível
do sistema. Como resultado, você pode sugerir uma arquitetura
de sistema abstrata como parte do processo de engenharia de
requisitos, em que você vincula coleções de recursos ou funções
do sistema a componentes ou subsistemas substanciais. As
necessidades e os recursos mais complexos do sistema são
então discutidos com as partes interessadas usando esse
detalhamento.
Enquanto os requisitos estão relacionados ao

lado do problema, a arquitetura está relacionada
ao lado da solução. Grande parte dos custos
REFLITA envolvidos na manutenção de software está
Unidade 1
associada a arquiteturas mal projetadas. Nesse

caso, como um projeto de arquitetura pode
ajudar a resolver esse tipo de problema?
Você pode projetar arquiteturas de software em dois

níveis de abstração, que chamo de arquitetura no pequeno e
arquitetura no grande.
1. A arquitetura de certos programas é a que a arquite-

tura no pequeno se refere. Nesse nível, estamos inte-
ressados em como um programa é dividido em suas
partes componentes.
2. Em geral, a arquitetura refere-se ao design de sistemas

corporativos intrincados, que incorporam outros
sistemas, programas e elementos de programas. Esses
sistemas corporativos podem ser distribuídos entre
várias máquinas pertencentes e operadas por várias
empresas.
A arquitetura de software é significativa porque tem

impacto na funcionalidade, resiliência, distribuição e capacidade
44
de manutenção de um sistema. Os componentes individuais do
sistema, de acordo com a Bosch, implementam os requisitos
funcionais do sistema, mas o design do sistema tem um impacto
significativo nos recursos não funcionais do sistema.
Decisões de projeto arquitetônico

No processo criativo do projeto arquitetônico, você cria
uma organização de sistema que satisfaz os requisitos funcionais
e não funcionais de um sistema. O projeto arquitetônico não é um
processo estereotipado. Baseia-se no tipo de sistema que está
sendo projetado, no treinamento e na experiência do arquiteto
do sistema e nos requisitos específicos do sistema (DOGLIO,
2022). Como resultado, acredito que seja melhor ver o projeto
Unidade 1
arquitetônico como uma série de escolhas a serem feitas, e não
como uma série de tarefas a serem concluídas.
Apesar do fato de cada sistema de software

ser diferente, os sistemas na mesma área de
aplicação frequentemente têm arquiteturas
IMPORTANTE semelhantes e representam as ideias centrais
do domínio. As linhas de produtos de aplicativos
são um tipo de aplicativo desenvolvido em torno
de uma arquitetura básica com variações para
atender a determinadas necessidades do cliente
(PRESSMAN, 2021). Você deve decidir o que seu
sistema e as classes de aplicativos maiores têm
em comum ao criar uma arquitetura de sistema,
bem como quanta informação desses projetos de
aplicativos você pode reutilizar.
Você não precisa criar uma arquitetura distribuída para

sistemas embarcados ou programas feitos para computadores
desktop e dispositivos móveis. A maioria dos grandes sistemas,
no entanto, são sistemas distribuídos nos quais o software do
sistema está espalhado por vários computadores (DOGLIO, 2022).
45
Um fator crucial que afeta o desempenho e a confiabilidade do
sistema é a arquitetura de distribuição.
Devido à estreita relação entre as características não

funcionais do sistema e a arquitetura do software, a escolha do
estilo e da estrutura arquitetônica deve depender dos requisitos
não funcionais do sistema.
•• Desempenho: se o desempenho for uma prioridade

máxima, a arquitetura deve ser criada para concentrar
as principais funções em um pequeno grupo de
componentes colocados em uma única máquina, em
vez de serem dispersos pela rede. Isso pode incluir o uso
de alguns componentes grandes, em oposição a muitos
componentes pequenos e refinados. A quantidade de
Unidade 1
comunicações de componentes é diminuída ao usar

componentes grandes, porque a maioria das interações
entre elementos de sistema relacionados ocorre dentro
de um componente. Você também pode levar em
consideração as organizações do sistema de tempo de
execução, que permitem que o sistema seja duplicado
e usado com vários processadores.
•• Segurança: se a segurança é uma prioridade máxima,

a arquitetura deve ser construída em camadas, com
os ativos mais importantes protegidos nas camadas
mais internas, e essas camadas sujeitas a uma
rigorosa validação de segurança. Além de operações
relacionadas à segurança, sendo localizadas em
um único componente ou em um pequeno número
de componentes, e potencialmente permitir o
fornecimento de sistemas de proteção relevantes que
podem desligar o sistema com segurança em caso de
falha, isso reduz os custos e problemas associados à
validação de segurança.
46
•• Disponibilidade: se a disponibilidade for uma
necessidade crucial, a arquitetura deve ser criada com
componentes redundantes, permitindo a substituição
e atualização de componentes sem a necessidade de
desligar o sistema.
•• Capacidade de manutenção: se a capacidade de

manutenção for uma prioridade máxima, a arquitetura
do sistema deve ser criada usando componentes
pequenos e independentes que sejam simples de
modificar. Estruturas de dados compartilhadas devem
ser evitadas, e produtores e consumidores de dados
devem ser mantidos separados.
Nem é preciso dizer que algumas dessas arquiteturas
Unidade 1
podem entrar em conflito. O uso de componentes enormes,
por exemplo, melhora o desempenho, enquanto o uso de
componentes pequenos e refinados melhora a capacidade de
manutenção. No entanto, uma compensação precisa ser feita
se os requisitos do sistema, como desempenho e capacidade
de manutenção, forem importantes (PRESSMAN, 2021). O
uso de vários padrões ou estilos de arquitetura para os vários
componentes do sistema pode ocasionalmente ajudá-lo a
conseguir isso. Hoje em dia, a segurança é quase sempre um
requisito crucial, por isso é importante criar uma arquitetura
que mantenha a segurança e, ao mesmo tempo, atenda a outros
requisitos não funcionais.
Visões arquitetônicas
Um único diagrama pode exibir apenas uma visão ou
perspectiva da arquitetura de um sistema, portanto é difícil
transmitir todas as informações pertinentes sobre seu design.
Poderia demonstrar a modularização de um sistema, as
47
interações entre os processos de tempo de execução ou as várias
estratégias de distribuição de componentes do sistema por
meio de uma rede (DOGLIO, 2022). Normalmente, você precisa
fornecer várias visualizações da arquitetura de software, porque
cada uma delas é valiosa em períodos diferentes para design e
documentação.
Em relação às visões necessárias, existem vários pontos de

vista. Argumenta-se que deve haver quatro visões arquiteturais
fundamentais que podem ser conectadas por casos de uso ou
cenários comuns em seu conhecido modelo de visão 4+1 de
arquitetura de software.
Figura 9 – Tipos de visões
Unidade 1
Visão lógica Visão de

desenvolvimento
Visão de processo Visão física
Usando muitas visualizações simultâneas, o modelo de

visualização 4+1 é usado para descrever o design de sistemas
intensivos em software. As visualizações são usadas para explicar
o sistema a partir das perspectivas de muitos interessados,
incluindo gerentes de projeto, usuários finais, desenvolvedores e
48
engenheiros de sistema. A abordagem tem quatro perspectivas:
lógica, de desenvolvimento, processo e física. A arquitetura que
atua como a visão “mais um” também é ilustrada usando alguns
casos de uso ou situações escolhidas. Consequentemente, o
modelo tem 4+1 perspectivas.
Ela oferece as seguintes visões:
1. Uma visão lógica, que exibe as principais abstrações

do sistema como objetos ou classes de objetos. Nessa
visão lógica, deve ser possível conectar os requisitos do
sistema às entidades.
2. Uma visão de processo, que demonstra como o

sistema é composto de processos interconectados
Unidade 1
durante o tempo de execução. Fazer avaliações de
características não funcionais do sistema, como
desempenho e disponibilidade, fica mais fácil com a
ajuda dessa abordagem.
3. O software é dividido em componentes que são

implementados por um único desenvolvedor ou
uma equipe de desenvolvimento em uma visão de
desenvolvimento, o que demonstra como o software
é decomposto para o desenvolvimento. Para gerentes
de software e programadores, esse ponto de vista é útil.
4. Uma visão física que exibe o hardware do sistema e a

colocação dos componentes de software entre as CPUs
do sistema. Os engenheiros de sistemas que organizam
a implantação de um sistema podem se beneficiar
desse ponto de vista.
5. Uma visão de cenários oferece uma maneira de

mapear o comportamento dos usuários via caso de
uso. Isso permite com que os engenheiros de software
possam se comunicar com os futuros usuários.
49
Na realidade, as concepções conceituais da arquitetura
de um sistema são quase sempre criadas ao longo da fase de
projeto. Eles são usados para informar decisões arquitetônicas
e para descrever a arquitetura do sistema para as partes
interessadas (BIRCHALL, 2016). Algumas das outras perspectivas
também podem ser estabelecidas durante a fase de projeto,
quando vários componentes do sistema são considerados,
embora raramente seja essencial desenvolver uma descrição
abrangente de todos os ângulos. Além disso, pode ser concebível
conectar os vários pontos de vista de um sistema com os padrões
de arquitetura que serão abordados na seção a seguir.
Padrões de arquitetura
Unidade 1
Vários ramos da engenharia de software adotaram a

noção de padrões como um meio de expressar, compartilhar e
reutilizar informações de sistemas de software. Uma descrição
estilizada e abstrata das melhores práticas que foram testadas
e comprovadas em muitos sistemas e situações pode ser
considerada um padrão de arquitetura (PRESSMAN, 2021).
Existe uma grande quantidade de padrões de

projeto para os mais diferentes problemas
recorrentes em software. Nesse caso, você pode
SAIBA MAIS fazer uso dele sempre que necessário. Para
entender melhor, acesse o link disponível aqui.
50
Consequentemente, uma organização de sistema
que funcionou bem em sistemas anteriores deve ser descrita
em um padrão de arquitetura. Deve delinear as vantagens e
desvantagens do padrão, bem como quando usá-lo e quando
não é apropriado, conforme exibido no quadro a seguir.
Quadro 1 – Exemplo de documentação do padrão de projeto MCV. Pode-se seguir a mesma
ideia para todos
Nome MVC (Model-View-Controller)
Separa os dados do sistema da exibição e do

envolvimento do usuário. O sistema é dividido em três
partes lógicas que se comunicam entre si. O componente
Model supervisiona as atividades nos dados do sistema,
bem como os próprios dados. A experiência do usuário
Descrição
Unidade 1
com os dados é controlada e definida pelo componente
View. Teclas, cliques do mouse e outras interações do
usuário são gerenciados pelo componente Controller,
que então transmite esses eventos para a View e o
Model.
A figura 10 mostra a arquitetura de um sistema de
Exemplo aplicativo baseado na web, organizado usando o padrão
MVC.
Usado durante a visualização e interação com os
dados pode ser feito de várias maneiras. Utilizado
Quando usar adicionalmente quando não está claro que tipo de
interação ou apresentação de dados pode ser necessária
no futuro.
Permite a alteração independentemente dos dados e da
representação dos dados. Permite a apresentação dos
Vantagens
mesmos dados em várias formas, com as atualizações de
uma representação sendo refletidas em todas elas.
Pode envolver código adicional e complexidade de código
Desvantagens
quando os dados do modelo e as interações são simples.
Fonte: Elaborado pelo autor (2023).
O conhecido padrão Model-View-Controller é mostrado na

figura seguinte. Numerosos sistemas baseados na web baseiam
51
seu gerenciamento de interação nesse padrão, que é suportado
pela maioria dos frameworks de linguagem (DOGLIO, 2022). A
descrição estilizada do padrão contém o nome do padrão, uma
explicação sucinta, uma representação gráfica e uma ilustração
do tipo de sistema no qual o padrão é aplicado. Inclua detalhes
sobre as vantagens e desvantagens do padrão, bem como
quando ele deve ser empregado.
Figura 10 – Model-View-Controller (MVC)
Browser
VIEW
Unidade 1
CONTROLLER Form to
Páginas dinâmicas
Requisição via HTTP display
Páginas estáticas
User events
Change
notification
Update Refresh request
request
MODEL
Regra de negócio
Bancos de dados
relacionais e não
relacionais
É um estilo de arquitetura para desenvolvimento de

software que divide a lógica do programa associado em três
partes inter-relacionadas. É frequentemente usado para criar
interfaces de usuário. Ao fazer isso, é possível distinguir entre as
representações internas da informação e as formas pelas quais a
informação é fornecida e recebida pelos usuários.
52
É impossível cobrir todos os padrões gerais que podem ser
aplicados ao desenvolvimento de software neste curto espaço de
tempo. Em vez disso, dou alguns exemplos de padrões populares
que também aderem a princípios sólidos de design arquitetônico.

vimos. Você deve ter aprendido que o projeto de
arquitetura de software está relacionado com o
domínio da solução. Ele trata da decomposição
do problema e problemas menores e mais
facilmente gerenciáveis. Deve ter aprendido
também sobre o comportamento emergente
Unidade 1
que ocorre quando pedaços de software são
utilizados de forma integrada. Dessa forma, o
projeto de arquitetura auxilia a gerenciar esse
comportamento emergente.
53
REFERÊNCIAS
BIRCHALL, C. Reengenharia de software legado. [S.l.]: Editora
Manning, 2016.
DOGLIO, F. Habilidades de um engenheiro de software de

sucesso. [S.l.]: Editora Manning, 2022.
JONES, C. Melhores práticas de engenharia de software: lições

de projetos bem-sucedidos nas principais empresas. [S.l.]: Editora
McGraw-Hill, 2010.
LONG, T. Código bom, código ruim: pense como um engenheiro

de software. [S.l.]: Editora Manning, 2021.
PRESSMAN, R. S. Engenharia de software: uma abordagem

Unidade 1
prática. [S.l.]: Editora McGraw-Hill, 2021.
SOMMERVILLE, I. Engenharia de software. [S.l.]: Editora Pearson,

2016.
54

Apostila Tema 1 Primeiro Bimestre

Enviado por

Direitos autorais:

Formatos disponíveis

Apostila Tema 1 Primeiro Bimestre

Enviado por

Dados do documento

Título original

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

Apostila Tema 1 Primeiro Bimestre

Enviado por

Direitos autorais:

Formatos disponíveis

ENGENHARIA DE

DAVID LIRA STEPHEN BARROS

LAURA KRISTINA FRANCO DOS SANTOS

Olá. Sou formado em ciência da computação, com

Tipos de domínios de software............................................................... 13

Entendendo os requisitos de um software............................... 20

Abordagens de modelagem de requisitos..................................................... 26

Modelagem de requisitos de software....................................... 33

Modelagem orientada a fluxo........................................................................... 33

Conceitos de design de software................................................ 42

Decisões de projeto arquitetônico.................................................................. 45

profissionais até o término desta etapa de estudos:

1. Definir conceitos e entender os princípios que orientam a

2. Compreender os conceitos relacionados a requisitos de

3. Aplicar a técnica da modelagem de requisitos no processo

4. Entender os conceitos de design e suas aplicações no

Essas informações podem ser tão simples quanto um

Mas o que é um software? Uma possível definição

informações descritivas em cópias impressas e

Embora o desenvolvimento de software e a produção de

Ele inicia com uma série de problemas durante o projeto.

A relação, também conhecida como “curva da banheira”,

A inferência é que o software não se desgasta. No

Figura 2 – Ciclo de vida tradicional de um software

Fonte: Elaborada pela autoria (2023).

Assim como o hardware, o software inicia com uma

O desgaste também demonstra a distinção entre

Tipos de domínios de software

•• O software de sistema é um grupo de aplicativos

•• Aplicativos independentes que atendem a determinadas

•• O software para engenharia e ciência tem sido referido

As aplicações abrangem desde biologia molecular até

•• O software incorporado é usado para implementar

•• Aplicativos Web, às vezes conhecidos como “WebApps”,

•• Para resolver questões complicadas que não são

Em projetos de software em uma ou mais dessas áreas,

Grande parte dos orçamentos direcionados à

VOCÊ SABIA? motivo de grande parte dos programas atuais

Infelizmente, ocasionalmente programas desatualizados

•• O software permeou quase todos os aspectos de nossas

•• A cada ano que passa, os requisitos de tecnologia da

•• É provável que a base de usuários e o tempo de vida de

A técnica de engenharia de software é em camadas.

Fonte: Elaborada pela autoria (2023).

Em resumo, engenharia de software lida com a produção

E então? Gostou do que lhe mostramos? Aprendeu

O desenvolvimento de software é um empreendimento

A engenharia de requisitos refere-se à ampla gama

A engenharia de requisitos cria um vínculo entre

O mecanismo certo é fornecido pela engenharia de

uma análise preliminar de viabilidade e estabelecem

•• Elicitação – perguntar ao cliente, aos usuários e outros

•• Problemas com o escopo – os limites do sistema

•• Problemas de volatilidade – os requisitos mudam

•• Análise – durante a elaboração, as informações

•• Negociação – dados os recursos limitados disponíveis

•• Especificação – o termo “especificação” em relação a

significar coisas diferentes para indivíduos diferentes

•• Validação – durante um processo de validação, os