Apostila Engenharia de Software Análise de Requisitos

Prévia do material em texto

APRESENTAÇÃO 
Professora Me. Eduarda Maganha de Almeida 
 
Olá, me chamo, Eduarda Maganha de Almeida, graduada em computação, mestre em 
Computação Aplicada com ênfase em Engenharia de Software ambos pela Universidade 
Tecnológica Federal do Paraná (UTFPR), campus de Cornélio Procópio, e doutoranda em 
Ciência da Computação na Universidade Federal do Paraná (UFPR). Possuo experiência como 
pesquisadora na área de Ciência da Computação, com ênfase em Engenharia de Software, 
pesquisando e atuando principalmente nos temas de: Engenharia de Requisitos, Indústria 4.0 
envolvendo Realidades virtuais, Big Data, Sistemas Inteligentes, IoT. 
Atualmente sou professora do departamento de Ciências Exatas, Agrárias, Tecnológicas e 
Geociências da Universidade Paranaense (UNIPAR) em Umuarama. 
Caso queira me acompanhar: 
● Linkedin: linkedin.com/in/eduardamaganhaalmeida 
● Facebook: https://www.facebook.com/dudamaganha 
● Lattes: http://lattes.cnpq.br/5751112934910095 
● Linktr.ee://linktr.ee/eduardamaganha 
 
 
 
 
 
 
 
 
APRESENTAÇÃO DA APOSTILA 
Prezado (a) aluno (a), 
Vou iniciar com a seguinte pergunta: você já se deparou com um software ruim? Com 
inúmeros erros? Falhas? Inconsistência? 
 Pois é, ao adquirir, “baixar”, experimentar, utilizar um produto ou serviço, o cliente, 
sempre espera recebê-lo com qualidade, sem defeitos e em total condições de uso. 
 E neste contexto, as novas tecnologias estão mudando a maneira como vivemos, 
trabalhamos e nos relacionamos, está caracterizada pelo uso intensivo de tecnologias digitais 
com o intuito de gerar novos produtos de maneira eficaz e rápida. 
 Entretanto, desenvolver novos produtos que atendam às necessidades dos usuários 
não é uma tarefa fácil. Receber um software com defeito causa uma quebra de confiança e 
pode gerar muitos transtornos para o cliente. Desta forma, adotar estratégias que controlem a 
qualidade do software é de extrema importância. 
 A fim de garantir a qualidade do produto de software, serviço e outro, o objetivo de 
nossas aulas é explorar a Análise de Requisitos, apresentando conceitos, exemplos de uso, 
processos, cenários reais e muito mais. 
Espera-se que a disciplina desperte sua atenção! 
Bons estudos! 
 
UNIDADE I 
INTRODUÇÃO - CONTEXTUALIZAÇÃO 
Professora Mestre Eduarda Maganha de Almeida 
 
 
Plano de Estudo: 
● Introdução - Contextualização; 
● Indústria 4.0; 
● Internet Of Things (IoT), Big Data e Computação em Nuvem; 
● O que é IoT? Quais suas aplicações? 
● Fundamentos da Engenharia de Requisitos; 
● Ciclo de Vida de Software. 
 
 
Objetivos de Aprendizagem: 
● Contextualizar alguns elementos que compõem a Indústria 4.0; 
● Compreender as técnicas de Engenharia de Requisitos (ER) que podem amparar 
no desenvolvimento de aplicações; 
● Relatar o ciclo de vida de um projeto de software; 
● Relatar alguns problemas advindos dos requisitos em projetos de 
software; 
● Identificar as etapas da engenharia de requisitos. 
INTRODUÇÃO 
 
Você já percebeu como a nossa vida é rodeada de produtos de software, mesmo 
que poucas pessoas se deem conta disto? Você já reparou nas tecnologias presentes em 
um estacionamento de um supermercado? Aliás, você consegue identificar o que são as 
luzes verdes e vermelhas nesses estacionamentos? Como elas se comunicam? O que é 
isso? Qual tecnologia é utilizada? 
A fim de responder essas questões e muitos outros entendimentos essa unidade 
tem como objetivo definir alguns elementos que compõem a Indústria 4.0, com o intuito 
de gerar insights sobre o cenário atual da indústria, e então compreender as técnicas de 
Engenharia de Requisitos (ER) que podem amparar no desenvolvimento de aplicações. 
Também será evidenciado a importância da engenharia de requisitos no ciclo de 
desenvolvimento de software e sua influência nas atividades de desenvolvimento. Por 
fim, entender como a engenharia de requisitos pode ajudar a eliminar, ou pelo menos 
minimizar, os problemas relacionados a requisitos. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1 INTRODUÇÃO - CONTEXTUALIZAÇÃO 
 
 
Fonte: Freepik https://www.freepik.com/free-vector/instant-information-concept-
illustration_12892958.htm#page=1&query=information&position=0&from_view=keyword 
 
 
Em conjunto com a inovação tecnologia, a estrutura organizacional do processo 
de produção da indústria passou por várias mudanças necessárias para enfrentar os 
mercados cada vez mais dinâmicos. 
 Neste processo, ressalta-se como ponto de partida a 1ª (Primeira) Revolução 
Industrial com aprimoramentos das máquinas a vapor, com o surgimento do tear 
mecânico, posterior a esta a 2ª (Segunda) Revolução Industrial, baseada na produção em 
massa e força hidráulica, e a 3ª (Terceira) Revolução Industrial foi difundida no ambiente 
de TI (Tecnologia da Informação), com o avanço da eletrônica e a digitalização. 
 
 
 
 
 
https://www.freepik.com/free-vector/instant-information-concept-illustration_12892958.htm#page=1&query=information&position=0&from_view=keyword
https://www.freepik.com/free-vector/instant-information-concept-illustration_12892958.htm#page=1&query=information&position=0&from_view=keyword
 
 
 
 
 
Figura 1: Revoluções Industriais 
 
Fonte: A autora (2021) 
 
 E hoje em dia, um novo período no cenário das revoluções industriais, a 4ª 
(quarta) Revolução Industrial ou comumente conhecida por Indústria 4.0 (quatro ponto 
zero - I4) – vamos padronizar por Indústria 4.0 ao longo do texto. De qualquer forma, 
uma variedade de termos diferentes é usada em todo o mundo para descrever a 
Indústria 4.0. Alguns países mantiveram a terminologia “Indústria 4.0”, mas outros 
países como EUA, China e alguns países da Europa definiram termos como “Internet of 
Things”, “Smart Manufacturing”, “Indústria Inteligente” ou "Fábrica Inteligente" para se 
referir especificamente à rede digital de produção que cria sistemas de manufatura 
inteligentes (DOPICO et al., 2016). No Brasil, o termo Indústria 4.0 é também conhecido 
como manufatura avançada. 
 Como explicado em parágrafos anteriores, a indústria sofreu algumas 
modificações ao longo da história e cresceu passo a passo ao longo das descobertas e 
evoluções. 
A vivência da Indústria 4.0 está mudando a maneira como as pessoas vivem, 
trabalham e se relacionam, está caracterizada pelo uso intensivo de tecnologias digitais 
com o intuito de gerar novos produtos de maneira eficaz e rápida, como uma resposta 
ágil à demanda e otimização streaming (tempo real) da produção. Dentre as tecnologias 
destacam-se a Internet of Things (IoT) – “a internet das coisas”, Inteligência Artificial, Big 
Data, Realidade Virtual e Aumentada, Computação em Nuvem, Nanotecnologia entre 
muitas outras que integram este cenário. 
O impacto da Indústria 4.0 traz mudanças nos setores de processos e negócios, 
pois tarefas diárias requerem a colaboração entre um conjunto heterogêneo de 
stakeholders (LU, 2017). Seus princípios de integração e interoperabilidade aumentam a 
demanda pelo desenvolvimento e estudo de aplicações colaborativas em ambientes 
virtuais, além disso, pode oferecer flexibilidade, reduzir prazos de entrega (LASI et al., 
2014). 
As diferentes percepções dos stakeholders em um projeto de IoT tendem a 
aumentar a complexidade do projeto. Muitos usuários diferentes e autônomos que 
divergem sobre um mesmo assunto/objeto podem tornar requisitos mais voláteis e 
acarretar ambiguidades na concepção de projetos. Além disso, neste contexto, os 
responsáveis por determinar e elicitar os requisitos nem sempre estarão fisicamente 
colocados e disponíveis, seja pela própria configuração organizacional ou por força 
maior, como é o caso da pandemia (Covid-19). 
Diante dessa explanação, o objetivo do primeiro capítulo é contextualizar alguns 
elementos que compõem a Indústria 4.0, com o intuito de gerar insights sobre o cenário 
atual da indústria, e então compreenderdireta com os usuários e clientes, a fim 
de identificar quais são as expectativas referentes ao projeto. 
O brainstorming (traduzido, tempestade de ideias), tem como objetivo reunir 
um grupo de envolvidos em um determinado projeto, seja de qualquer área, e coletar 
todas as ideias referente ao projeto. É importante salientar, que as ideias apresentadas 
não podem ser descartadas ou desconsideradas durante o processo de coleta, pois o 
foco do brainstorming é selecionar a melhor ideia, realizando um processo de 
combinação das ideias sugeridas, assim caso alguma ser descartada, esta pode impactar 
na etapa de combinação das ideias. (INFOESCOLA, 2012). 
 
 
 
Figura 2: Brainstorming 
 
 
 
Fonte: Freepik. https://www.freepik.com/free-vector/business-team-brainstorm-idea-lightbulb-from-
jigsaw-working-team-collaboration-enterprise-cooperation-colleagues-mutual-assistance-concept-
bright-vibrant-violet-isolated-
illustration_10780698.htm#page=1&query=brainstorming&position=21&from_view=search 
 
Há outras técnicas tais como workshops, mapas mentais, protótipos etc. 
 
https://www.freepik.com/free-vector/business-team-brainstorm-idea-lightbulb-from-jigsaw-working-team-collaboration-enterprise-cooperation-colleagues-mutual-assistance-concept-bright-vibrant-violet-isolated-illustration_10780698.htm#page=1&query=brainstorming&position=21&from_view=search
https://www.freepik.com/free-vector/business-team-brainstorm-idea-lightbulb-from-jigsaw-working-team-collaboration-enterprise-cooperation-colleagues-mutual-assistance-concept-bright-vibrant-violet-isolated-illustration_10780698.htm#page=1&query=brainstorming&position=21&from_view=search
https://www.freepik.com/free-vector/business-team-brainstorm-idea-lightbulb-from-jigsaw-working-team-collaboration-enterprise-cooperation-colleagues-mutual-assistance-concept-bright-vibrant-violet-isolated-illustration_10780698.htm#page=1&query=brainstorming&position=21&from_view=search
https://www.freepik.com/free-vector/business-team-brainstorm-idea-lightbulb-from-jigsaw-working-team-collaboration-enterprise-cooperation-colleagues-mutual-assistance-concept-bright-vibrant-violet-isolated-illustration_10780698.htm#page=1&query=brainstorming&position=21&from_view=search
https://www.freepik.com/free-vector/business-team-brainstorm-idea-lightbulb-from-jigsaw-working-team-collaboration-enterprise-cooperation-colleagues-mutual-assistance-concept-bright-vibrant-violet-isolated-illustration_10780698.htm#page=1&query=brainstorming&position=21&from_view=search
https://www.freepik.com/free-vector/business-team-brainstorm-idea-lightbulb-from-jigsaw-working-team-collaboration-enterprise-cooperation-colleagues-mutual-assistance-concept-bright-vibrant-violet-isolated-illustration_10780698.htm#page=1&query=brainstorming&position=21&from_view=search
3 COMPONENTES DA ANÁLISE DOS REQUISITOS 
 
Fonte: Freepik 
https://www.freepik.com/free-vector/analysis-concept-
illustration_7069167.htm#page=1&query=analisar&position=1&from_view=search 
 
 A Análise de Requisitos é importante, pois garante a entrega de qualidade, 
permite compreender as reais necessidades dos clientes e diminuir o espaço que 
existe entre suas expectativas e a compreensão de seus desenvolvedores 
(SOMMERVILLE, 2011).. 
 Possibilita um planejamento mais próximo do real, permitindo estimar os 
custos e prazos do projeto muito mais próximos ao real. 
 A diminuição do retrabalho, definindo bem os requisitos, diminuirá as 
chances de retrabalho. Muitas vezes o desenvolver não entende exatamente o 
que está sendo pedido. 
 A Figura 3 apresenta algumas atividades que envolvem o processo de 
análise dos requisitos. É possível notar o design, a qual é relacionada a 
modelagem do que será desenvolvido, essa modelagem pode ser realizada por 
meio de uma linguagem de modelagem, protótipo, no qual é considerado uma 
construção de modelos que representam o software. Protótipos executáveis 
(papel ou software), a fim de auxiliar na validação dos requisitos com o cliente. A 
implementação é o desenvolvimento daquilo que foi elicitado e analisado. A 
atividade de teste é a validação dos requisitos que foram descritos (verificar se 
o desenvolvedor de fato fez o que foi pedido) e a evolução consiste na otimização 
do que foi desenvolvido. 
 
 
Figura 3: Componentes da Análise dos Requisitos 
 
 
Fonte: A autora (2021). 
 
 Algumas dificuldades são encontradas durante a elicitação dos requisitos, como 
stakeholders (partes envolvidas) não sabem o que querem do software; stakeholders não 
sabem explicar o que querem do software; stakeholders podem fazer exigências 
inviáveis; stakeholders utilizam uma linguagem específica; requisitos podem sofrem 
várias alterações e demais (SOMMERVILLE, 2011). A Figura 3, apresenta uma 
exemplificação de um processo de engenharia de requisitos, o qual relata como o cliente 
especifica suas necessidades, como o líder do projeto e envolvidos entendem, e de fato 
como deveria ser o produto final esperado pelo cliente. 
 
 
 
Figura 4: Exemplificação processo de engenharia de requisitos 
 
 
 
Fonte: Adaptado de TEIXEIRA, 2018 
 
Ainda na análise de requisitos, pode-se também destacar a Usabilidade, a qual 
refere-se à qualidade da Interação Humano-Computador (IHC) proporcionada pela 
interface de um sistema computacional (formando pelo menos um processador, 
memória principal e dispositivos de Entrada e Saída). A Engenharia de Usabilidade 
dispõe-se para o desenvolvimento da interação entre usuário e um sistema 
computacional, sendo assim, o conteúdo da disciplina inclui tanto o produto, a própria 
interface, como o processo, compreendendo técnicas e procedimentos utilizados no 
escopo de um ciclo de vida do desenvolvimento de software. Para alcançar um resultado 
satisfatório e de boa qualidade, em questão de usabilidade, no desenvolvimento de 
software é necessário a realização de diversos artefatos que podem ser organizados 
hierarquicamente (SOMMERVILLE, 2011). 
Entender as necessidades do usuário significa compreender e explorar o máximo 
de informações possíveis sobre ele. Estabelecer os requisitos consiste em uma elicitação 
das informações que a aplicação deve ou não fazer, e como devem ser manipuladas, os 
requisitos podem ser classificados em requisitos de usuário e requisitos de sistema. 
Os requisitos de usabilidade é um dos quesitos fundamentais em uma interface, 
uma vez que o sucesso de um sistema dependerá de fatores como a facilidade de 
aprendizado do usuário no uso com a aplicação, flexibilidade e robustez de sua interação 
(SOMMERVILLE, 2011). 
A partir da identificação dos requisitos de design, as personas e cenários podem 
ser criados para auxiliar os projetistas durante o processo de desenvolvimento da 
interface da aplicação. O conceito de persona foi introduzido em 1998 por Alan Cooper 
no livro intitulado “The inmates are running the asylum”, de acordo com o autor, a 
técnica proposta é trivial e eficaz, pois as personas são personagens fictícios que 
possuem certas características de um grupo de usuários, tais características são guiadas 
por dados coletados na fase de elicitação de requisitos (SOMMERVILLE, 2011). 
Similar as personas, os cenários de uso é uma técnica considerada simples, e 
prevê que todo cenário deve envolver no mínimo uma persona e um objetivo. Os 
cenários são importantes para descrever as ações que os usuários deverão realizar, os 
storyboards são uma maneira de ilustrar os cenários. 
A etapa de avaliar tem como propósito verificar se a documentação dos 
requisitos definem o que o usuário realmente necessita, se o protótipo gerado está de 
acordo estes requisitos, é importante salientar que outros tipos de verificações podem 
ser inseridas, como a verificação de completude e consistência (SOMMERVILLE, 2011). 
Essa etapa, na maioria dos casos, conta com a participação do cliente e analista de 
requisitos. Possui o produto como etapa final. 
A fimde analisar os requisitos, são implementadas as técnicas de concepção, são 
destinadas a implementar os requisitos para a interface e a usabilidade de uma 
aplicação, dentre as técnicas de concepção, pode-se ressaltar: 
 
● Brainstorming; 
● Storyboard; 
● Protótipos. 
O Brainstorming é uma expressão inglesa formada pela união das palavras 
“brain”, traduzido significa cérebro, e “storm” significa tempestade, logo 
“brainstorming”, pode ser traduzida como tempestade cerebral, ou tempestade de 
ideias. 
 O termo Brainstorming foi criado pelo publicitário Alex Osborn, nos Estados 
Unidos, com a finalidade de avaliar e analisar a capacidade criativa individual ou de um 
grupo, foi concebida não apenas para a criação de interfaces, mas para qualquer área 
que exija as relações humanas, dinâmicas de grupos. 
 Para aplicar a técnica de brainstorming recomenda-se que um grupo (mínimo 
dois participantes) se reúna e crie ideias para que possam alcançar um denominador 
comum, com objetivo de gerar ideias inovadoras. 
 Uma interface intuitiva pode ter sido gerada por grupo multidisciplinar, reunidos 
para a sua criação . As discussões de um grupo que utiliza a técnica de brainstorming 
são abertas e livres para expor opiniões e sugestões, entretanto, deve existir um líder 
(ou intermediador) para absorver e relatar as ideias, apresentar resultados esperados. 
 Ainda que, brainstorming seja uma técnica interessante e aberta, possui algumas 
desvantagens em sua utilização, entre elas, pode-se destacar: por ser uma discussão 
aberta, quando uma crítica ocorre e não é bem aceito pelo grupo, alguns participantes 
podem ficar intimidados e deixar de expor uma ideia que seja relevante ou não; além 
disso, as ideias podem surgir de uma maneira confusa e impedir que exista um 
alinhamento, refinamento e detalhamento em cada uma, dificultando a avaliação e os 
resultados. 
O storyboard, a utilização de cenários para elicitar requisitos de um projeto 
de software é uma coleção de narrativas que favorecem o levantamento de 
informações, identificação e antecipação de possíveis falhas e problemas. Um 
cenário não possui o objetivo de descrever detalhadamente um projeto, mas 
gerar discussões, permitindo também, documentar as informações coletadas. 
 Semelhante aos cenários encontra-se o storyboard, uma técnica utilizada 
por permitir descrever situações de uso, a fim de envolver a descrição de um 
projeto através de quadros com imagens que ilustram as situações do domínio. 
Cada quadro deve apresentar a cena que descreve a situação, os atores e as 
ações que cada um deve executar (SOMMERVILLE, 2011). 
A utilização das técnicas utilizadas na prototipação é algo frequente no ambiente 
de design e construção de uma aplicação. Um protótipo pode ser definido como uma 
representação parcial do design da interface. 
As técnicas utilizadas para prototipação denotam grande utilidade no processo 
de desenvolvimento de projeto, permitindo extrair informações a respeito da forma 
como o usuário interage com a aplicação. Os protótipos podem ser entendidos como 
representação gráfica, não necessariamente funcional, de sistemas em fase de projeto 
(LAMPERT e BEHNCK, 2009). 
 O método de prototipação rápida é utilizado para demonstrar características e 
comportamentos desejáveis da aplicação final, pois oferece ao usuário e ao projetista a 
possibilidade de analisar e identificar possíveis problemas. A classificação dos protótipos 
de interface é praticada em níveis de fidelidade a interface da aplicação pode ser dividida 
em duas categorias: prototipação rápida e prototipação de alta e baixa fidelidade. O 
Quadro 1 relata uma comparação entre a prototipação de alta e baixa fidelidade. 
 
Quadro 1: Comparação entre as prototipações de alta e baixa fidelidade 
Tipo Vantagens Desvantagens 
Protótipo de 
baixa-fidelidade 
Custo mais baixo; 
Avaliação de Avalia inúmeros 
significados de design; Instrumento de 
comunicação útil; 
Aborda questões de layout de tela; 
Identificação de requisitos 
Verificação limitada de erros; 
Utilidade limitada para testes de 
usabilidade; 
Limitações de fluxo e navegação; 
Protótipo de alta-
fidelidade 
Funcionalidade completa; totalmente 
interativo; 
Desenvolvimento consideravelmente 
caro; 
Uso acompanhado pelo usuário; 
Define claramente o esquema de 
navegação. 
Criação demanda tempo; 
Não serve para coleta de requisitos. 
Fonte: A autora (2021). 
 
 Como apresentado no Quadro 1, os protótipos de baixa-fidelidade são 
desenvolvidos em pouco tempo, e tanto por pessoas experientes na área, quanto sem 
conhecimento de programação. Assim, é importante que a ferramenta de prototipagem 
seja eficiente e intuitiva, a fim de facilitar a construção de protótipos rápidos. 
 
SAIBA MAIS 
 
Para exemplificar a construção de um protótipo, será utilizada a ferramenta 
AXURE (disponível em: www.axure.com), que possui recursos para a criação e alteração 
de telas, componentes de interface, e orientação de navegação. No site do Axure existe 
uma lista de bibliotecas de Widgets, entre as quais se destacam: Yahoo UI, Metro UI, iOS 
Library, Android, etc. A ferramenta AXURE gera executáveis em HTML, assim como sua 
documentação em formato .doc 
 
Fonte: A autora (2021). 
 
#SAIBA MAIS# 
 
 As Figuras seguintes apresentam o passo a passo da prototipação de uma 
interface de e-commerce. 
 
 
Figura 5: Passo 1 - Criar um novo documento 
 
Fonte: A autora (2021). 
 
O requisito funcional “Realizar Compra” é granularizado e gerado os seguintes 
requisitos: 
 
a. O sistema deve permitir a visualização dos produtos disponíveis para 
venda; 
b. O cliente poderá selecionar e visualizar os detalhes do produto; 
c. O cliente deverá informar a quantidade desejada e forma de pagamento, 
antes de finalizar a compra; 
d. Após a finalização da compra, o sistema deverá emitir uma mensagem de 
confirmação ao usuário, exibindo o número do pedido. 
 
O requisito funcional “Realizar Compra” gera os diagramas de caso de uso e de 
classes. 
 
 
Figura 6: Diagrama de Caso de Uso 
 
 
Fonte: A autora (2021). 
Figura 7: Diagrama de classe 
 
 
Fonte: A autora (2021). 
 
Figura 8: Passo 3 - Deixar apenas a página "home" 
 
 
Fonte: A autora (2021). 
 
 
 Prosseguindo para o Passo 4, deve-se Clicar no Widget “Classic Menu Horizontal”, 
arrastar e inserir na área de trabalho. 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 9: Passo 4 
 
Fonte: A autora (2021). 
 
 
 O Passo 5, deve-se alterar os nomes do menu para: Produtos (para visualização 
da lista de produtos, Promoções, Marcas e Meus Pedidos. 
 
Figura 10: Passo 5 
 
 
 
Fonte: A autora (2021). 
 
Já no Passo 6, deve-se inserir o elemento “Placeholder” no cabeçalho da área de trabalho 
(servirá como logo do e-commerce). 
 
Figura 11: Passo 6 
 
 
Fonte: A autora (2021). 
 
 No que diz respeito ao Passo 7, é necessário inserir um elemento chamado 
“Heading” (inserção de textos) com o nome do site. 
 
 
 
 
 
 
 
 
 
Figura 12: Passo 7 
 
 
Fonte: A autora (2021). 
 
 No Passo 8, selecione no menu “Produtos” e insira algumas imagens. 
 Passo 9, inserir o nome dos produtos através do elemento “Label”. Para copiar 
vários elementos: basta selecionar o elemento, pressionar e segurar a tecla “ctrl” e 
arrastar. 
Figura 13: Passos 8 e 9 
 
 
Fonte: A autora (2021). 
 Para visualizar o andamento do protótipo: Clicar em “Publish”, “Generate HTML 
File”. (Observação: talvez a extensão do “Axure RP” tenha que ser instalada no navegador 
para que a visualização do projeto seja possível). 
 
Figura 14: Visualização do protótipo no navegador 
 
 
Fonte: A autora (2021) 
 
Figura 15: Protótipo de uma página detalhada 
 
 
Fonte: A autora (2021). 
 
 O Passo 10, para criar a página de “Confirmação de Compra”, linkar o botão 
“Comprar” da página “Descrição” com essa nova página.Copiar o cabeçalho padrão do 
site para a nova página. Inserir uma mensagem de sucesso na nova página. 
 
Figura 16: Passo 10 
 
 
Fonte: A autora (2021). 
 
 Os protótipos de baixa fidelidade podem ser validados pelos usuários em 
simulações e testes, entretanto é válido salientar na medida em que as interfaces vão 
sendo modificadas as aparências, comportamento das orientações de navegação, os 
botões e outros recursos disponíveis também sofrerão alterações. 
 O uso de protótipos nas fases de desenvolvimento de uma aplicação tende a 
contribuir com a comunicação entre os projetistas e usuários, permitindo testar os 
modelos de maneira satisfatória, fornecendo respostas úteis. Devido ao contínuo 
acompanhamento do desenvolvimento do projeto, os usuários não se surpreendem de 
maneira negativa com o resultado da aplicação final, pois a comunicação entre os 
desenvolvedores e usuários acontece tanto de maneira quantitativa como qualitativa, 
resultando em uma maior quantidade e melhor qualidade do feedback provido pelos 
usuários. 
 Diante de tal explanação, pode-se observar que a participação do usuário é 
importante durante o processo de análise de requisitos e engenharia de usabilidade, são 
consideradas importantes, pois as ideias só serão consideradas válidas se o usuário 
aprovar, o que significa uma redução de custos e trabalhos, evita o desenvolvimento de 
funcionalidades e recursos inviáveis, dado que sempre o usuário realiza um feedback 
referente a evolução do desenvolvimento. 
 
REFLITA 
 
Diante do contexto apresentado nessa Unidade 3, como você avaliaria a 
necessidade da prototipação para os requisitos de um projeto de software? 
 
Fonte: A autora (2021). 
 
#REFLITA# 
 
 
 
 
CONSIDERAÇÕES FINAIS 
 
É comum pensar nas atividades de engenharia de requisitos que focam na 
descoberta e na documentação dos requisitos, pois sabe-se que requisitos que não 
tenham sido adequadamente elicitados podem trazer consequências adversas para os 
projetos e os produtos de software. 
Porém, existem outros aspectos da engenharia de requisitos que merecem igual 
atenção e preocupação por parte da organização desenvolvedora, que são atividades 
relacionadas à análise de requisitos. Requisitos mal gerenciados são tão danosos para o 
produto quanto o requisito mal elicitado. 
Nesse contexto, a área de usabilidade e Interface Humano Computador deve-se 
ser tratada com alta rigorosidade, a mesma conectada à construção de interfaces 
usáveis e intuitivas demandam de atenção para se obter um resultado final satisfatório 
e eficaz. 
Entretanto, construir tais interfaces requer, entre inúmeras atividades, a 
participação efetiva do usuário durante as fases da construção da aplicação e, para tal, a 
aplicação de técnicas de modelagem podem amparar esse processo. 
Assim, a Unidade III teve como objetivo apresentar alguns componentes que 
envolvem a análise de requisitos, a fim de amparar na entrega de um produto final de 
qualidade. 
 
 
 
LEITURA COMPLEMENTAR 
 
● Artigo: The relationship between Requirements Engineering and Virtual Reality 
Systems: A Systematic Literature Review. 
DOS SANTOS, Alinne C. Correa; DELAMARO, Marcio Eduardo; NUNES, Fatima LS. The 
relationship between requirements engineering and virtual reality systems: A systematic 
literature review. In: 2013 XV Symposium on Virtual and Augmented Reality. IEEE, 
2013. p. 53-62. 
Link para acesso: https://ieeexplore.ieee.org/abstract/document/6655762 
 
● Artigo: QualiHM: A Requirement Engineering Toolkit for Efficient User Interface 
Design. 
BOUKHEBOUZE, Mohamed et al. QualiHM: A requirement engineering toolkit for 
efficient user interface design. In: 2014 IEEE Eighth International Conference on 
Research Challenges in Information Science (RCIS). IEEE, 2014. p. 1-11. 
Link para acesso: 
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6861056 
 
 
 
 
 
 
 
 
 
 
 
 
 
https://ieeexplore.ieee.org/abstract/document/6655762
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6861056
 
 
 
 
 
 
 
LIVRO 
 
• Título: Design Centrado no Usuário 
• Autor: Travis Lowdermilk. 
• Ano: 2013. 
• Editora: Independente. 
•Sinopse: “Design centrado no usuário apresenta uma visão única sobre a forma como 
pesquisas junto aos usuários são combinadas com os conceitos de design, focando na 
lógica fundamental e no conhecimento por trás do assunto. O livro é presença 
obrigatória na biblioteca de qualquer pessoa que esteja criando produtos para seus 
usuários, ajudando a compreender por que um foco no usuário é tão importante no 
design.” 
Como fazer o design de aplicativos atraentes, que as pessoas gostem de usar? 
Este livro apresenta várias maneiras de incluir informações valiosas de clientes 
e consumidores em potencial durante o processo. Com diretrizes práticas e 
percepções provenientes de sua própria experiência, o autor Travis Lowdermilk 
mostra como a usabilidade e o design centrado no usuário irão mudar, de forma 
dramática, a maneira como as pessoas interagem com seu aplicativo. Aprenda 
estratégias valiosas para condução de cada um dos estágios do processo de 
design ― da entrevista com prováveis usuários e da descoberta do propósito de 
seu aplicativo à criação de uma experiência rica de usuário, utilizando sólidos 
princípios de design. Design centrado no usuário tem valor inestimável, 
independentemente da plataforma utilizada ou do público-alvo visado. 
 
 
 
FILME/VÍDEO 
 
 
• Título: Ltia - Prototipagem em Papel - Paper Prototyping Tutorial 
• Ano: 2010. 
• Sinopse: O vídeo discorre um Tutorial rápido e simples sobre como desenvolver um 
protótipo em papel para uma interface, feito pelo grupo AIR do Ltia - Laboratório de 
Tecnologia da Informação Aplicada - Unesp, para a oficina "Há mais papel entre um 
homem e sua interface que possa imaginar vossa vã filosofia!" 
• Link do vídeo: https://www.youtube.com/watch?v=k9mTvt0LXgk 
 
 
 
 
 
 
 
 
 
https://www.youtube.com/watch?v=k9mTvt0LXgk
 
 
REFERÊNCIAS 
 
CYBIS, Walter; BETIOL, Adriana Holtz; FAUST, Richard. Ergonomia e usabilidade: 
conhecimentos, métodos e aplicações. Novatec editora, 2017. 
 
IEEE - Institute of Electrical And Eletronics Engineers. Standards Glossary of Software 
Engineering Terminology: Std 610.12, N.Y.,1990. 84p. 
 
INFOESCOLA. Análise de Requisitos. 2012. Disponível em: 
https://www.infoescola.com/engenharia-de-software/analise-de-requisitos/. Acesso 
em: 15 dez. 2021. 
 
LAMPERT, R.; BEHNCK, E. S. Ferramenta de Apoio a Prototipação de Interfaces. p. 
1032–1034, 2009. 
 
PFLEEGER, S. L. Engenharia de Software: Teoria e Prática (2nd ed.). Pearson Education 
do Brasil, 2004. 
 
PRESSMAN, R. S. Engenharia de Software - Uma Abordagem Profissional. 
Development (pp. 42–60), 2007. Disponível em: 
https://doi.org/9788563308337Acesso em: 15 dez. 2021. 
 
ROGERS, Y.; SHARP, H.; PREECE, J. Design de Interação. 3. ed. Porto Alegre - RS: s/d. 
 
SOMMERVILLE, I. Engenharia de Software. Pearson Brasil, 2011. 
 
TEIXEIRA, Danielle. Como escrever requisitos de software de forma simples e garantir 
o mínimo de erros no sistema/app? 2018. Disponível em: https://medium.com/lfdev-
blog/como-escrever-requisitos-de-software-de-forma-simples-e-garantir-o-
m%C3%ADnimo-de-erros-no-sistema-app-74df2ee241cc. Acesso em: 16 dez. 2021. 
 
 
UNIDADE IV 
ABORDAGEM DE ENGENHARIA DE REQUISITOS PARA APLICAÇÕES DE REALIDADE 
AUMENTADA 
Professora Mestre Eduarda Maganha de Almeida 
 
 
Plano de Estudo: 
● Introdução; 
● Realidade Aumentada; 
● Abordagem de Engenharia de Requisitos para Realidade Aumentada; 
● Validação da Abordagem e Discussões; 
● Garantia de Qualidade. 
 
 
 
Objetivos de Aprendizagem: 
● Apresentar as evidências de Realidade Aumentada; 
● Visualizar uma abordagem de Engenharia de Requisitos para o processo 
de especificação e análise de requisitos em aplicaçõesde Realidade 
Aumentada; 
● Definir Testes de Qualidade de Software; 
● Relatar sobre Garantia de Qualidade. 
 
 
 
INTRODUÇÃO 
 
 
Como iniciamos a Unidade I caracterizando a Indústria 4.0 e seus componentes, 
e nada mais justo que finalizar nosso estudo com a associação de uma tecnologia da 
Indústria 4.0 com o processo de Engenharia de Requisitos. 
Hoje em dia, a pluralidade de aplicações da Indústria 4.0 estão revolucionando a 
maneira de se relacionar com a tecnologia. Tal pluralidade de aplicações faz parte da 
rotina, e aos poucos ganhou espaço em atividades e objetos triviais como correr pelo 
parque (rastreamento), relógios, celular, casa, medicina, entre outras inúmeras áreas. 
Partindo desse princípio a Unidade 4, apresenta uma abordagem de engenharia 
de requisitos, elaborada para auxiliar no processo de especificação e análise de 
requisitos em aplicações de Realidade Aumentada (RA), a qual compõe a Indústria 4.0. 
Desenvolvedores de sistemas de RA enfrentam um problema, no estado da arte 
e são identificados poucos guias e sugestões de desenvolvimento, muitas vezes, 
derivados de problemas específicos de cada sistema, e não se adaptam a outros 
desenvolvimento. Diante desse gap (lacuna) na literatura, referente ao processo de 
especificação e análise de requisitos para desenvolvimentos de sistemas de RA, a 
Engenharia de Requisitos (ER) é ressaltada como um ponto fundamental para o sucesso 
de um projeto. 
Assim, nossa quarta unidade trará a visualização de uma abordagem de 
engenharia de requisitos, elaborada para auxiliar no processo de especificação e análise 
de requisitos em aplicações de Realidade Aumentada, bem como relato de suas 
atividades e envolvidos. Ainda nessa unidade, vamos compreender sobre o processo de 
garantia de qualidade e como um plano de teste pode interferir de maneira positiva no 
desenvolvimento e implantação de um software. 
 
 
 
 
1 INTRODUÇÃO 
 
 
Fonte: Freepik - Adaptada (https://www.freepik.com/free-vector/young-people-using-augmented-
reality-
smartphones_11524569.htm#page=1&query=augmented%20reality&from_query=realidade%20aument
ada&position=3&from_view=search) 
 
 
Como vimos na Unidade I, a pluralidade de aplicações da Indústria 4.0 estão 
revolucionando a maneira de se relacionar com a tecnologia. A Unidade 4 apresenta 
uma abordagem de engenharia de requisitos, elaborada para auxiliar no processo de 
especificação e análise de requisitos em aplicações de Realidade Aumentada (RA), a qual 
compõe a Indústria 4.0. 
 Desenvolvedores de sistemas de RA enfrentam um problema, no estado da arte 
são identificados poucos guias e sugestões de desenvolvimento, muitas vezes, derivados 
de problemas específicos de cada sistema, e não se adaptam a outros desenvolvimento 
(DAMASCENO e OLIVEIRA, 2009). 
Diante desse gap (lacuna) na literatura, referente ao processo de especificação e 
análise de requisitos para desenvolvimentos de sistemas de RA, a Engenharia de 
Requisitos (ER) é ressaltada como um ponto fundamental para o sucesso de um projeto. 
O objetivo da ER, segundo Robinson, Pawlowski e Volkov (2003), é aperfeiçoar e 
analisar as modelagens de um determinado projeto, permitindo uma maior 
compreensão das suas características antes da implantação. 
De acordo com Kirner e Salvador (2007), o desenvolvimento de sistemas de 
Realidade Aumentada demanda de um processo de especificação e análise de requisitos 
adequados às suas características específicas, além disso demanda de uma equipe de 
desenvolvimento multidisciplinar para entender todo projeto a ser desenvolvido. 
Para aprimorar o desenvolvimento de aplicações de RA, e preencher essa lacuna 
encontrada na literatura foi desenvolvida uma abordagem de engenharia de requisitos 
que suporte o processo de especificação e análise de requisitos em aplicações de RA 
(ALMEIDA et al., 2018). 
Segundo Almeida (2018, p. 17): 
 
A abordagem proposta de ER é baseada em características específicas de RA 
pode seguir tanto uma abordagem de desenvolvimento iterativa quanto a 
clássica, podendo ser adaptada para o modelo de processo desenvolvimento 
de cada organização. Em cada etapa do possível modelo são definidos 
conjuntos de atividades específicas, cujo intuito é gerar artefatos para auxiliar 
na especificação e análise de requisitos, e também da intersecção dos 
requisitos convencionais e requisitos específicos de RA, além dos requisitos 
de sistema. Com a abordagem é possível estabelecer um conjunto organizado 
de atividades, e técnicas que contribuem e orientam os pesquisadores, 
projetistas, desenvolvedores para a obtenção da completa especificação e 
análise de requisitos e avaliação de um protótipo de interface. 
 
 
 
 
2 REALIDADE AUMENTADA 
 
Fonte: Freepik 
https://www.freepik.com/free-vector/augmented-reality-concept-landing-page-
template_11790753.htm#page=1&query=augmented%20reality&from_query=realidade%20aumentada
&position=16&from_view=search 
 
 
Um dos componentes indispensáveis para o funcionamento de uma 
aplicação de Realidade Aumentada (RA) é o uso da câmera de vídeo, para 
capturar os marcadores e ambientes. 
 Há inúmeros dispositivos que podem ser utilizados para auxiliar na 
identificação dos elementos do ambiente e/ou posicionar os elementos em 
relação ao usuário. O hardware de RA pode utilizar dispositivos também 
inerentes de RV. 
 Entre os dispositivos que podem ser auxiliadores de entrada para uma 
aplicação de RA estão: GPS – sistema de posicionamento global (do inglês 
Global Positioning System); luvas de dados e interfaces tangíveis. (TORI; 
KIRNER e SISCOUTTO, 2006). 
 Para visualizar a captura da cena e/ou elementos virtual, é preciso 
hardware de saída, pois os dispositivos precisam ter a capacidade de misturar o 
ambiente real com o virtual, para tal são utilizadas quatro técnicas distintas: 
 
 
Figura 1: Elementos dispositivos de Saída 
 
 
Fonte: Adaptado de (TORI; KIRNER e SISCOUTTO, 2006) 
 
Um sistema de RA além dos recursos de hardware demanda de software para 
aplicações mais robustas e complexas. 
 O sistema de RA tem como finalidade integrar objetos virtuais ao ambiente real, 
para tal, utilizar elementos para ajudar a captura de posições ou dos próprios elementos 
do ambiente real. 
 Para desenvolver aplicações de RA, três características devem ser ofertadas: 
combinar o real com o virtual; ser interativa em tempo real e registrar objetos virtuais 
com relação aos objetos reais. 
 Diversas ferramentas são desenvolvidas para facilitar o desenvolvimento de 
aplicações de RA, o Quadro 1 apresenta links referentes à bibliotecas, softwares e/ou 
estudos disponíveis para RA. 
 
Quadro 1: Links de Softwares e Estudos de RA 
Biblioteca / Softwares 
/Estudos referentes à RA 
Link 
Artanim http://www.artanim.ch/en/projects-detail.php 
 
ARToolkit * https://www.hitl.washington.edu/artoolkit/documentation/ 
 
Augment. 
 
http://www.augment.com/how-augmented-reality-works/ 
 
Aurasma https://www.aurasma.com/ 
 
Holodeck VR 
 
http://www.holodeckvr.co 
 
Inglobe Technologies 
 
http://www.inglobetechnologies.com 
 
osgART 
 
http://www.osgart.org 
 
Total Immersion 
 
http://www.t-immersion.com/ 
 
Vuforia http://vuforia.com/ 
 
 
Fonte: A autora (2021). 
 
 
 
http://www.artanim.ch/en/projects-detail.php
https://www.hitl.washington.edu/artoolkit/documentation/
http://www.augment.com/how-augmented-reality-works/
https://www.aurasma.com/
http://www.holodeckvr.co/
http://www.inglobetechnologies.com/
http://www.osgart.org/
http://www.t-immersion.com/
http://vuforia.com/
3 ABORDAGEM DE ENGENHARIA DE REQUISITOS PARA REALIDADE AUMENTADA 
 
Fonte: Freepik 
https://www.freepik.com/free-vector/augmented-reality-background-with-
device_2317133.htm#page=1&query=augmented%20reality&from_query=realidade%20aumentada&po
sition=48&from_view=search 
 
 
A abordagem deve ser capaz de realizar a intersecção dos requisitostradicionais 
de software com requisitos específicos de aplicações de RA, além dos requisitos 
convencionais de ambientes exigidos na no desenvolvimento de software. 
O processo de desenvolvimento de especificação e análise de requisitos para 
aplicações de RA baseia-se em duas ações específicas: o ambiente virtual e sua interface 
devem ser adaptados ao ambiente real; e o desempenho do cenário, para que os 
benefícios do uso de RA sejam alcançados à velocidade de execução deve ser adequada 
ao ambiente (TORI; KIRNER e SISCOUTTO, 2006). 
O desenvolvimento de ambientes virtuais requer um esforço compartilhado 
envolvendo tópicos de modelagem, objetos 3D e Interação Homem Computador (IHC), 
visto que a sua construção está relacionada à realidade visual e à interação através de 
sentidos humanos diferentes (SOUZA e KIRNER, 2012). 
A abordagem é composta de quatro elementos, como demonstrado na Figura 2. 
Os objetivos da abordagem são, a participação dos usuários com o ambiente virtual, para 
que possam analisar e experimentar o ambiente e fazer possíveis alterações e/ou 
melhorias; e um cenário de fácil adaptação e manuseio. É importante apontar a 
necessidade de identificar as atitudes, comportamentos e necessidades do usuário, a 
fim de gerar protótipos rapidamente que possam ser analisados e avaliados pelo usuário. 
O fluxo de desenvolvimento da abordagem pode ser adaptado de acordo com 
cada desenvolvedor, podendo ser desde um fluxo iterativo incremental à modelo 
cascata. 
Figura 2: Abordagem de ER para aplicações de RA 
 
 
Fonte: A autora (2021). 
 
A etapa de Elicitação dos Requisitos (Figura 3), pode ser composta por dez 
atividades, com o propósito de identificar e descrever as necessidades de informação do 
ambiente virtual, envolvem ações que visam capturar e registrar o entendimento correto 
das expectativas e necessidades do usuário, nesta etapa é gerado o documento de 
requisitos, também chamado de Especificação de Requisitos de Software, em que inclui 
os requisitos de usuário, sistema, usabilidade e requisitos específicos de RA. Assim como 
em todas as etapas posteriores poderão ser adaptadas para cada cenário específico. 
Nota-se os participantes propostos nessa etapa são o cliente, o qual deve 
informar ao engenheiro de requisitos quais são as suas necessidades; o 
engenheiro de requisitos, que tem objetivo realizar de maneira clara e direta a 
coleta dos requisitos e transmitir para o analista de requisitos, o responsável pela 
análise do problema dos usuários e stakeholders, pela identificação, 
organização, documentação e gerência das mudanças nos requisitos. 
Os requisitos de usuário descrevem o que a aplicação deverá fornecer aos 
usuários e quais serão as restrições com as quais deve operar (SOMMERVILLE, 2011). 
Os requisitos de sistema são as descrições mais detalhadas das funções, serviços 
e restrições operacionais da aplicação. Frequentemente, os requisitos de sistema são 
classificados em requisitos funcionais, os quais apresenta o que o sistema deve fornecer 
e como deve reagir a distintas entradas; e requisitos não funcionais, demonstram 
restrições aos serviços ou funções oferecidos pelo sistema (PFLEEGER, 2004). 
Deve-se ressaltar os fatores de qualidade exigidos pela aplicação como, 
usabilidade, flexibilidade, portabilidade, manutenabilidade, devido as exigências 
advindas da tecnologia de Realidade Aumentada. Pressman (2007) destaca que os 
requisitos de sistemas não apenas especificam as características ou serviços necessários, 
mas também a funcionalidade imposta para garantir que essas características ou 
serviços sejam entregues corretamente. 
Os requisitos de usabilidade é um dos quesitos fundamentais em uma interface, 
uma vez que o sucesso de um sistema dependerá de fatores como a facilidade de 
aprendizado do usuário no uso com a aplicação, flexibilidade e robustez de sua interação. 
Requisitos específicos da tecnologia de RA, advém da identificação das atitudes, 
comportamentos e necessidades do usuário, além de requisitos de ambiente, imersão, 
interação, navegação, sentidos entre outros. 
A plataforma de renderização é o equipamento no qual os objetos são 
desenhados. Uma plataforma gráfica 3D para Realidade Aumentada contém o 
desempenho gráfico necessário, memória de vídeo e textura, biblioteca de suporte 
gráfico (como OpenGL) e entre outros elementos (DE FA OBREGON; BRAGA e FILHO, 
2015). 
Os tipos de displays para aplicações de RA são as tecnologias óticas e vídeo. Entre 
algumas abordagens estão relacionados a capacetes, óculos, marcadores, que permite 
ao usuário ver o mundo real com objetos sobrepostos sobre ele. 
 A tecnologia de Realidade Aumentada exige um rastreamento preciso de posição 
e orientação para alinhar ou registrar as informações virtuais com os objetos físicos. 
As tecnologias de entrada são fundamentais para aplicações de RA, como, luvas, 
capacetes, óculos, câmeras de vídeo, marcadores (coloridos, fiduciais, entre outros), 
além de outros objetos. As tecnologias de saída apresentam as informações dos 
usuários, como dispositivos visuais, fone de ouvido, microfone, dispositivos visuais, 
entre outros. 
A definição de hardware e software apresentam os equipamentos que serão 
utilizados, bem como possa permitir a integração com alguma multimídia, tendo em 
vista que ao fim desta etapa um protótipo deve ser entregue ao usuário. Os 
comportamentos e interações deverão estabelecer os objetos com as características de 
geometria, escala, cor, textura; os comportamentos que esses objetos possam realizar; 
e as interações necessárias para o ambiente virtual (KIRNER e SALVADOR, 2007). 
 
 
 
 
 
 
 
Figura 3: Etapa 01 - Elicitação dos Requisitos 
 
Fonte: A autora (2021). 
 
A etapa de Análise dos Requisitos (Figura 4) consta de 3 etapas, 
classificação dos requisitos, revisão da documentação, e os casos de testes, e 
foram definidos o analista de requisitos e o cliente como principais responsáveis 
por esta etapa. 
A classificação dos requisitos é realizada para organizar e separar os requisitos 
elicitados na etapa anterior, a fim de revisar com o cliente se a documentação elaborada 
está de acordo com suas necessidades. 
Nesta etapa, é planejado como será realizado o caso de teste para validar a 
documentação dos requisitos. Pode conter um ou mais casos de teste para uma 
determinada documentação. 
Com a finalidade de certificar que a documentação de requisitos está de acordo 
com as necessidades do cliente, é incluído nesta etapa o caso de teste. O caso de teste 
é definido por cada equipe, como um checklist, protótipo de interface. 
 
Figura 4: Etapa 02 - Análise dos Requisitos 
 
 
Fonte: A autora (2021). 
 
A etapa de Projeto (Figura 5) tem como finalidade a implementação dos casos de 
teste e dos protótipos. Os responsáveis por esta etapa são o cliente, o design de interface 
e os testers, responsáveis respectivamente pela análise e concordância do que está 
sendo realizado, projetista do protótipo de interface que será apresentado para o 
cliente, e verificação da execução dos casos de testes determinados. 
 
 
 
 
 
 
 
 
 
 
Figura 5: Etapa 03 – Projeto 
 
 
Fonte: A autora (2021). 
 
E por fim, a etapa de Avaliação (Figura 6) como propósito verificar se a 
documentação dos requisitos define o que o usuário realmente necessita, se o protótipo 
gerado está de acordo estes requisitos, e se os casos de testes foram satisfatórios, para 
alcançar essas verificações foram incluídas as atividades de geração de casos de testes, 
e a análise da documentação da especificação de requisitos de software. Porém é 
importante salientar que outros tipos de verificações podem ser inseridas, como a 
verificação de completude e consistência (SOMMERVILLE, 2011). Esta etapa conta com 
a participação do cliente e analista de requisitos. 
 
 
 
 
 
 
Figura 6: Etapa 04 – AvaliaçãoFonte: A autora (2021). 
 
 
4 VALIDAÇÃO DA ABORDAGEM E DISCUSSÕES 
 
 
A validade de qualquer método de estudo evidencia a confiabilidade e 
objetividade dos seus resultados, sendo assim devem ser consideradas as potenciais 
ameaças de validade do estudo. A validação da abordagem proposta utilizou dois 
métodos distintos, um experimento e um estudo de campo. 
O subprocesso de operacionalização do experimento foi composto de três etapas 
básicas de acordo com Wohlin et al. (2012): a preparação, a execução do experimento, 
e a validação dos dados. 
A Etapa de preparação do experimento tem como função organizar o 
desenvolvimento do experimento. Inicialmente, é realizada a caracterização dos 
participantes. Participaram um total de 38 pessoas, os sujeitos selecionados são alunos 
de graduação do curso de Análise e Desenvolvimento de Sistemas. Houve um 
treinamento com todos os participantes com duração de 30 minutos, no intuito de 
apresentar a abordagem que deverá ser utilizada no experimento, contextualizar 
engenharia de requisitos e realidade aumentada, e como será realizado o experimento, 
o qual foi executado uma vez, em um laboratório de informática da universidade, 
realizado no segundo semestre de 2017. Entre treinamento, preparação do ambiente, 
desenvolvimento e coleta dos dados foram gastos aproximadamente dois dias. 
O método de estudo de campo foi realizado em uma empresa de 
desenvolvimento de aplicações de Realidade Aumentada (RA) nacional. A empresa 
denominada de X para este trabalho, opera no ramo de desenvolvimento de software 
de RA para o setor comercial, marketing, e privado. A empresa X, foi fundada por um 
empreendedor há quase 10 anos. A escolha da empresa para o estudo foi baseada na 
disponibilidade de data e hora. A entrevista foi a técnica de coleta de dados escolhida 
para a sua realização. 
A RA é uma área do conhecimento que disponibiliza diversas oportunidades de 
investigação científica e inovação, pois ainda é considerada uma tecnologia em 
constante crescimento, e também por oferecer aos usuários melhores interações com o 
mundo virtual, através de interfaces intuitivas (NAKAMOTO et al., 2012). 
A ausência e limitações de guias na literatura nortearam a necessidade do 
desenvolvimento desta pesquisa, o trabalho relatou a lacuna encontrada no processo de 
especificação e análise de requisitos em desenvolvimento de aplicações de RA, agravado 
por limitações de guias na literatura para auxiliar nesse processo. 
Acredita-se que tal lacuna interfere diretamente no desenvolvimento de uma 
aplicação seja ela convencional ou em ambientes virtuais, supõe-se que os benefícios 
obtidos durante a especificação e análise de requisitos devam recompensar de modo 
significativo no resultado satisfatório da aplicação, dado que a atividade de especificação 
e análise de requisitos serem um fator crítico de sucesso ou fracasso do desenvolvimento 
do projeto. 
Com o estudo e as aplicações de testes experimentais foi possível desenvolver 
uma abordagem baseada em conceitos de Engenharia de Requisitos (ER) e Realidade 
Aumentada para o processo de especificação e análise de requisitos para o 
desenvolvimento de aplicações de RA. Pode ser adaptada por seus usuários e seguir 
desde um ciclo clássico a um ciclo iterativo, dos quais se criam protótipos, que são 
avaliados, refinados, seguindo a documentação de especificação, visando obter o 
produto final desejado. 
A abordagem proposta estabelece um conjunto estruturado de atividades e 
técnicas que contribuem e orientam os engenheiros de requisitos, analista de requisitos, 
desenvolvedores e outros, para a obtenção de uma completa e objetiva especificação, 
análise e avaliação dos requisitos, refinando-os iterativamente, caso necessário. 
As características geradas nas atividades propostas na abordagem poderão 
contribuir para a construção tanto de sistemas virtuais quanto sistemas tradicionais, 
visto que a abordagem pode ser adaptada para cada cenário específico. 
Constatam-se, com base nos objetivos do trabalho, que as afirmações contidas 
neste trabalho, são referentes à literatura disponível estudada, os métodos de pesquisa 
realizados, e como resultado as publicações realizadas durante o desenvolvimento do 
estudo. Este trabalho fornece um referencial teórico refinado sobre o contexto de ER em 
aplicações de RA, que tende a viabilizar a construção do conhecimento. Por todo o 
exposto, é esperado com a pesquisa contribuir para uma visão mais ampla e a 
compreensão do processo de Engenharia de Requisitos em aplicações de Realidade 
Aumentada. 
Diante do supramencionado, é importante destacar a necessidade de utilizar um 
modelo / abordagem para amparar no processo de desenvolvimento de um software. 
Atentando-se às limitações e demandas da organização. Pois requisitos elicitados de 
forma concreta pode resultar no resultado positivo de produto e/ou solução final, 
evitando o retrabalho e consequentemente gerando recursos rentáveis de trabalho. 
 
 
5 GARANTIA DE QUALIDADE 
 
Fonte: Freepik 
https://www.freepik.com/free-vector/product-quality-concept-
illustration_18407468.htm#page=1&query=qualidade&position=1&from_view=search 
 
 
A qualidade de software apresenta uma tendência que cresce na indústria de 
software. E, para que a qualidade seja uma realidade, é necessário que os testes 
de software e os profissionais dessa área sejam cada vez mais qualificados. 
Em busca de mitigar possíveis problemas e impactos negativos em um 
projeto de software, seja para componentes da Indústria 4.0 ou aplicações 
transacionais, um plano de teste deve ser elaborado. 
O teste se tornou uma parte crítica do ciclo de vida de desenvolvimento 
de software, especialmente porque as práticas ágeis e construções funcionais 
se tornaram a norma entre as equipes. O plano de teste é o esquema para cobrir 
a avaliação da funcionalidade do software, detalhando cada etapa que leva ao 
resultado do teste, ao mesmo tempo que destaca os riscos projetados e os 
recursos necessários para os aplicativos de software. 
Um plano de teste refere-se a um documento detalhado que cataloga a 
estratégia, os objetivos, o cronograma, as estimativas, os prazos e os recursos 
necessários para concluir aquele projeto específico. Ou seja, um plano para 
executar os testes necessários para garantir que o software esteja funcionando 
corretamente. Um plano de teste bem elaborado é um documento dinâmico que 
muda de acordo com as progressões no projeto e permanece atualizado o tempo 
todo. É o ponto de referência, com base no qual as atividades de teste são 
executadas e coordenadas entre uma equipe de QA (Quality Assurance – 
garantia de qualidade). 
O plano de teste também é compartilhado com analistas de negócios, 
gerentes de projeto, equipes de desenvolvimento e qualquer outra pessoa 
associada ao projeto. Isso principalmente oferece transparência nas atividades 
de controle de qualidade para que todas as partes interessadas saibam como o 
software será testado. 
O plano é elaborado por gerentes ou líderes de QA com base na entrada 
de membros da equipe de QA (e, às vezes, não-QA). 
 
 
 
SAIBA MAIS 
 
Criar um plano de teste (test plan) não deve demorar mais do que ⅓ do tempo 
alocado para todo projeto. 
 
Fonte: A autora (2021). 
 
#SAIBA MAIS# 
 
Os planos de testes são importantes, pois ajudam indivíduos fora das equipes de 
controle de qualidade (desenvolvedores, gerentes de negócios, equipes voltadas para o 
cliente) a entender exatamente como o site ou aplicativo será testado; oferecem um guia 
claro para os engenheiros de controle de qualidade conduzirem suas atividades de teste; 
detalham aspectos como escopo de teste, estimativa de teste, estratégia e assim por 
diante. 
Além de agrupar todas essas informações em um único documento, facilita a 
revisão pelo pessoal de gerenciamento ou a reutilização em outros projetos.A área de qualidade de software pode ser dividida em dois grandes grupos, 
sendo eles: qualidade de processos e qualidade de produtos. Na parte de qualidade de 
processos, uma das formas utilizadas para garantia da qualidade são os modelos de 
maturidade que medem o quanto a empresa é madura, ou seja, aderente aos processos. 
São exemplos CMMI e MPS.BR. 
A qualidade de produto considera como atividade principal a realização de testes 
de software e esta pode ser dividida em duas partes: testes caixa branca e testes caixa 
preta. Caixa branca é o teste realizado com acesso ao código fonte da funcionalidade em 
teste e; caixa preta, sem acesso a esse código. 
Vamos juntos analisar as Figuras seguintes, referente a síntese das informações 
sobre essas duas subdivisões da área de qualidade de software. 
 
Figura 7: Garantia de Qualidade – Síntese 1 
 
 
Fonte: A autora (2021). 
Figura 8: Garantia de Qualidade – Síntese 2 
 
 
Fonte: A autora (2021). 
Figura 9: Teste de Maturidade 
 
 
Fonte: A autora (2021). 
 
 
Figura 10: Teste de Software 
 
 
Fonte: A autora (2021). 
 
 
 
REFLITA 
 
Diante do contexto apresentado nessa Unidade IV, como você poderia utilizar a 
abordagem proposta para o desenvolvimento de um jogo digital cujo objetivo é inserir a 
Realidade Virtual (RV) em seu contexto? 
Ainda nesse cenário, como você realizaria os testes de software para garantir que 
ao utilizar o jogo de RV seu cliente (usuário) não terá nenhum desconforto? 
 
Fonte: A autora (2021). 
 
#REFLITA# 
 
 
 
CONSIDERAÇÕES FINAIS 
 
A Indústria 4.0 é um conceito que disponibiliza diversas oportunidades de 
investigação científica e inovação 
A abordagem apresentada nesta Unidade IV, estabelece um conjunto 
estruturado de atividades e técnicas que contribuem e orientam os engenheiros de 
requisitos, analista de requisitos, desenvolvedores e outros, para a obtenção de uma 
completa e objetiva especificação, análise e avaliação dos requisitos, refinando-os 
iterativamente, caso necessário. 
Neste contexto, é importante ressaltar que a elaboração de um plano de teste 
pode amparar no resultado positivo do uso da abordagem. A fim de auxiliar em tal 
demanda a inserção de testes de software e maturidade podem ser uma opção para 
determinar se o software atingiu as suas especificações de funcionamento 
corretamente. Esses processos são responsáveis por verificar falhas do sistema antes 
que o desenvolvimento seja concluído. 
Diante do cenário explorado nesta unidade e nas demais unidades, foi possível 
observar a necessidade do levantamento de requisitos, o qual pode ajudar a evitar a 
frustração de clientes ao final de um projeto de software. Em muitos casos, o cliente não 
sabe muito bem do que precisa, tornando mais difícil criar um projeto que satisfaça às 
suas necessidades. A identificação de requisitos no início do projeto é muito importante 
para o bom desenvolvimento do sistema. Requisitos bem definidos e especificados são 
um bom começo rumo à qualidade de um produto de software. Assim, a Análise de 
Requisitos é responsável por coletar dados indispensáveis e necessários para contemplar 
as exigências do usuário, para solucionar um determinado problema e alcançar seus 
objetivos, assim como determinar as suas expectativas para determinado produto. 
 
 
LEITURA COMPLEMENTAR 
 
● Artigo: A busca de uma identidade para a indústria 4.0 
 
NETO, Anis Assad et al. A busca de uma identidade para a indústria 4.0. Brazilian Journal 
of Development, v. 4, n. 4, p. 1379-1395, 2018. 
Link para acesso: https://www.brazilianjournals.com/index.php/BRJD/article/view/183 
 
● Artigo: Conflitos na ER: Proposta de uma Atividade de Narrativa com auxílio de 
Realidade Aumentada 
 
ANDRADE, Camila; LENCASTRE, Maria. Conflitos na ER: Proposta de uma Atividade de 
Narrativa com auxílio de Realidade Aumentada. 2020. 
Link para acesso: http://wer.inf.puc-
rio.br/WERpapers/artigos/artigos_WER20/19_WER_2020_paper_42.pdf 
 
● Artigo: Uma metodologia para teste de Software no Contexto da Melhoria de 
Processo 
 
CRESPO, Adalberto Nobiato et al. Uma metodologia para teste de Software no Contexto 
da Melhoria de Processo. Simpósio Brasileiro de Qualidade de Software, p. 271-285, 
2004. 
Link para acesso: https://www.researchgate.net/profile/Adalberto-Crespo-
2/publication/237497188_Uma_Metodologia_para_Teste_de_Software_no_Contexto_
da_Melhoria_de_Processo/links/54e5d1040cf2cd2e028b338b/Uma-Metodologia-
para-Teste-de-Software-no-Contexto-da-Melhoria-de-Processo.pdf 
 
 
 
https://www.brazilianjournals.com/index.php/BRJD/article/view/183
http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER20/19_WER_2020_paper_42.pdf
http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER20/19_WER_2020_paper_42.pdf
https://www.researchgate.net/profile/Adalberto-Crespo-2/publication/237497188_Uma_Metodologia_para_Teste_de_Software_no_Contexto_da_Melhoria_de_Processo/links/54e5d1040cf2cd2e028b338b/Uma-Metodologia-para-Teste-de-Software-no-Contexto-da-Melhoria-de-Processo.pdf
https://www.researchgate.net/profile/Adalberto-Crespo-2/publication/237497188_Uma_Metodologia_para_Teste_de_Software_no_Contexto_da_Melhoria_de_Processo/links/54e5d1040cf2cd2e028b338b/Uma-Metodologia-para-Teste-de-Software-no-Contexto-da-Melhoria-de-Processo.pdf
https://www.researchgate.net/profile/Adalberto-Crespo-2/publication/237497188_Uma_Metodologia_para_Teste_de_Software_no_Contexto_da_Melhoria_de_Processo/links/54e5d1040cf2cd2e028b338b/Uma-Metodologia-para-Teste-de-Software-no-Contexto-da-Melhoria-de-Processo.pdf
https://www.researchgate.net/profile/Adalberto-Crespo-2/publication/237497188_Uma_Metodologia_para_Teste_de_Software_no_Contexto_da_Melhoria_de_Processo/links/54e5d1040cf2cd2e028b338b/Uma-Metodologia-para-Teste-de-Software-no-Contexto-da-Melhoria-de-Processo.pdf
 
LIVRO 
 
• Título: Introdução a Realidade Virtual e Aumentada 
• Autor: Romero Tori (ed.) Marcelo da Silva Hounsell (ed.) 
• Ano: 2018. 
• Sinopse: Este livro foi elaborado pela Comissão Especial de Realidade Virtual - CE-RV 
da SBC (Sociedade Brasileira de Computação) para difundir os conhecimentos 
fundamentais das áreas de Realidade Virtual e Aumentada. Sua primeira versão foi 
apresentada durante o XX Simpósio de Realidade Virtual e Aumentada (SVR 2017), 
realizado em Gramado-RS. Agora em sua terceira edição, produzida para o SVR 2020, 
ganhou mais três capítulos, totalizando 22. Esta obra foi elaborada com a colaboração 
de vários autores, todos com larga experiência no desenvolvimento, pesquisa, ensino e 
aplicações de realidade virtual e aumentada, no Brasil e no exterior. São abordadas 
tecnologias, conceitos e aplicações, cobrindo desde origens e evolução até as mais 
recentes tendências e desafios, passando por conceitos básicos e avançados, hardware, 
software e aplicações em diferentes áreas. 
Referência: TORI, Romero; DA SILVA HOUNSELL, Marcelo. Introdução a 
realidade virtual e aumentada. Interação, v. 7, p. 11, 2020. 
Disponível em: http://www.de.ufpb.br/~labteve/publi/2018_livroRVA.pdf. Acesso 
em: 15 dez. 2021. 
 
 
http://www.de.ufpb.br/~labteve/publi/2018_livroRVA.pdf
FILME/VÍDEO 
 
 
• Título: O Dilema das Redes 
• Ano: 2020. 
• Sinopse: O vídeo apresenta especialistas em tecnologia e profissionais da área fazem 
um alerta: as redes sociais podem ter um impacto devastador sobre a democracia e a 
humanidade. 
• Disponível em: Netflix 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
REFERÊNCIAS 
 
ALMEIDA, Eduarda Maganha de et al. Uma abordagem de engenharia de 
requisitos para o processo de especificação e análise de requisitos em aplicações de 
realidade aumentada. 2018. Dissertação de Mestrado. Universidade Tecnológica 
Federal do Paraná. 2018. Disponível em: 
http://repositorio.utfpr.edu.br/jspui/handle/1/3272. Acesso em: 15 dez. 2021. 
 
CORREA DOS SANTOS, A. C.; DELAMARO, M. E.; NUNES, F. L. S. The 
Relationship between RequirementsEngineering and Virtual Reality Systems: A 
Systematic Literature Review. Virtual and Augmented Reality (SVR), 2013 XV 
Symposium on, p. 53–62, 2013. 
 
DAMASCENO, E. F. Sistema de Reabilitação baseado em Técnicas de Captura de 
Movimento para Tratamento de Lombalgia Mecânica. p. 131, 2013. 
 
DAMASCENO, E. F.; OLIVEIRA, D. C. de. Análise swot das metodologias de 
sistemas de realidade virtual. VI Workshop de Realidade Virtual e Aumentada., p. 
3–5, 2009. 
 
DE FA OBREGON, R.; BRAGA, K. R.; FILHO, N. S. C. Desenvolvimento De 
Software Baseado Em Realidade Aumentada Para Processos De Aprendizagem 
Software Development Based on Augmented Reality for Learning Process. p. 1–10, 
2015. 
 
GOLDIEZ, B. et al. Advancing Human Centered Augmented Reality Research. 
Proceedings for the Army Science Conference (24th), p. 9, 2004. 
 
KIRNER, C.; KIRNER, T. G. Evolução e tendências da Realidade Virtual e da 
Realidade Aumentada. Realidade Virtual e Aumentada Aplicações e Tendências, v. 
1, p. 151, 2011. 
 
KIRNER, T. G.; SALVADOR, V. F. M. Desenvolvimento de Ambientes Virtuais. 
Fundamentos e tecnologia de realidade virtual e aumentada, p. 90–107, 2007. 
NAKAMOTO, P. T. et al. Estratégia De Engenharia De Requisitos Para 
Ambientes De Realidade Aumentada. Journal of Information Systems and 
Technology Management, v. 9, n. 3, p. 607–626, 2012. 
 
NAKAMOTO, P. T.; CARRIJO, G. A.; CARDOSO, A. Construção De Ambientes 
Educacionais Com Realidade Aumentada: Processo Centrado No Usuário. p. 9, 
2009. 
 
NAKAMOTO, P. T. N. Estratégia de Especificação de Requisitos de Usabilidade para 
Sistemas de Realidade Aumentada. p. 77, 2011. 
 
PFLEEGER, S. L. Engenharia de Software: Teoria e Prática. 2. ed. São Paulo: 
Pearson Education do Brasil, 2004. 
 
PRESSMAN, R. S. Engenharia de Software - Uma Abordagem. Profissional 
Development, 2007. 
 
ROBINSON, W. N.; PAWLOWSKI, S. D.; VOLKOV, V. Requirements interaction 
management. ACM Computing Surveys, v. 35, n. 2, p. 132–190, 2003. 
 
SOMMERVILLE, I. Engenharia de Software. Pearson Brasil, 2011. 
 
SOUZA, R. C.; KIRNER, C. Alternativas de Interação em Ambientes de Realidade 
Aumentada Online. 2012. 
 
THELIN, T.; RUNESON, P.; WOHLIN, C. An experimental comparison of 
usagebased and checklist-based reading. IEEE Transactions on Software Engineering, 
v. 29, n. 8, p. 687–704, 2003. 
 
TORI, R. Desafios para o design de informação em ambientes de realidade 
aumentada. InfoDesign Revista Brasileira de Design da Informação, v. 6, n. 1, p. 46–
57, 2009. 
 
TORI, R.; KIRNER, C.; SISCOUTTO, R. Fundamentos e tecnologia de 
Realidade Virtual e Aumentada. Fundamentos e Tecnologia de Realidade Virtual e 
Aumentada, p. 422, 2006. 
 
WOHLIN, Claes et al. Experimentation in software engineering. Springer Science & 
Business Media, 2012. 
 
 
CONCLUSÃO GERAL 
Diante dos cenários explorados nas quatro unidades, foi possível observar a 
necessidade do levantamento de requisitos, o qual pode ajudar a evitar a frustração de 
clientes ao final de um projeto de software. Em muitos casos, o cliente não sabe muito 
bem do que precisa, tornando mais difícil criar um projeto que satisfaça às suas 
necessidades. 
 A identificação de requisitos no início do projeto é muito importante para o bom 
desenvolvimento do sistema. Requisitos bem definidos e especificados são um bom 
começo rumo à qualidade de um produto de software. 
 Assim, a Análise de Requisitos é responsável por coletar dados indispensáveis e 
necessários para contemplar as exigências do usuário, para solucionar um determinado 
problema e alcançar seus objetivos, assim como determinar as suas expectativas para 
determinado produto.as técnicas de Engenharia de Requisitos (ER) 
que podem amparar no desenvolvimento de aplicações. 
 
2 INDÚSTRIA 4.0 
 
 Independente do contexto a palavra revolução pode ser associada a mudanças 
profundas e à ruptura com uma realidade anterior, como dizia Karl Marx, as revoluções 
são a locomotiva da história, e ao longo dos anos, inúmeras revoluções, desencadeadas 
por novas tecnologias, processos e por novas maneiras de perceber o mundo, 
provocaram mudanças nos sistemas econômicos e nas estruturas sociais (SCHWAB, 
2016). 
Desde a primeira Revolução Industrial, o setor produtivo almeja por soluções que 
otimizem seu desempenho, que busca impulsionar e continuar impulsionando o 
desenvolvimento de várias tecnologias em todas as áreas referentes à produção. A 
Indústria 4.0 é o produto de uma profusão de tecnologias aplicadas ao ambiente de 
produção, o que Schwab (2016) nomeia de “megatendências”. 
Na Indústria 4.0, as fábricas precisam lidar com a necessidade de 
desenvolvimento rápido e flexível da produção em ambientes complexos (SCHWAB, 
2016). Portanto, o primeiro beneficiário é o cliente, pois a manufatura avançada visa 
tornar os produtos mais atraentes e mais acessíveis, através do desenvolvimento de 
personalização de produtos e da redução do tempo de entrega de produtos ao mercado, 
aumentando, ao mesmo tempo, a qualidade e os serviços associados. 
Pode-se dizer que a Indústria 4.0 é um sistema complexo, ou seja, um sistema 
com um grande número de agentes interagentes que exibe comportamentos 
emergentes não triviais e auto organizados. 
 
 
 
 
 
 
 
3 INTERNET OF THINGS (IOT), BIG DATA E COMPUTAÇÃO EM NUVEM 
 
Fonte: Freepik 
https://www.freepik.com/free-vector/connected-living-abstract-concept-
illustration_12291166.htm#page=1&query=internet%20of%20things&from_query=internet%20das%20c
oisas&position=21&from_view=search 
 
 Embora a combinação de hardware e software em um sistema interconectado 
seja a base da indústria 4.0, há outras variáveis que são importantes durante essa 
transição e podem facilitar as diferentes etapas e condições que uma cadeia de produção 
da 4ª Revolução Industrial deve ter (DOPICO et al., 2016). Sendo assim, algumas das 
principais ferramentas utilizadas são: Internet das Coisas (IoT), Big Data e Computação 
em Nuvem, e a Realidade Aumentada conforme apresenta Figura 2. 
 
 
Figura 2: Indústria 4.0 
https://www.freepik.com/free-vector/connected-living-abstract-concept-illustration_12291166.htm#page=1&query=internet%20of%20things&from_query=internet%20das%20coisas&position=21&from_view=search
https://www.freepik.com/free-vector/connected-living-abstract-concept-illustration_12291166.htm#page=1&query=internet%20of%20things&from_query=internet%20das%20coisas&position=21&from_view=search
https://www.freepik.com/free-vector/connected-living-abstract-concept-illustration_12291166.htm#page=1&query=internet%20of%20things&from_query=internet%20das%20coisas&position=21&from_view=search
 
Fonte: Adaptado de: (LU, 2017). 
 
Essas ferramentas são encarregadas de receber, reunir, gerenciar, analisar, 
interpretar e intercomunicar enormes quantidades de informação provenientes de todas 
as partes do sistema de produção. Também são responsáveis por executar decisões 
descentralizadas e permitir a simulação de toda a cadeia de suprimentos e de todos os 
processos nela incluídos, a fim de tomar decisões eficientes (DOPICO et al., 2016). 
A Internet das Coisas (IoT) é um conceito que considera a presença difusa no 
ambiente de uma variedade de coisas e objetos que, através de conexões sem fio e com 
fio e esquemas de endereçamento únicos são capazes de interagir entre si e cooperar 
com outras coisas e objetos para criar novos aplicativos, serviços e alcançar objetivos 
comuns (FRIESS, 2013). 
De acordo com Dopico et al. (2016), a IoT pode ser definida como um sistema de 
rede que suporta as ferramentas de comunicação entre dispositivos inteligentes e sua 
interconectividade. Tendo como objetivo, permitir que as coisas sejam conectadas a 
qualquer momento, em qualquer lugar, com qualquer coisa usando qualquer caminho, 
rede ou serviço (FRIESS, 2013). 
Na configuração da IoT, são necessárias duas variáveis separadas e igualmente 
importantes: por um lado, sensores que são encarregados de capturar as informações 
geradas pelos diferentes estágios e máquinas no processo; e, por outro lado, protocolos 
de software de comunicação que são responsáveis por transferir essas informações para 
um servidor central (DOPICO et al., 2016). 
Outros conceitos fundamentais para o pilar da indústria 4.0 são o Big Data, a 
computação em nuvem, e a Realidade Aumentada que criam um meio capaz de lidar 
com todas as informações gerenciadas pelos sistemas cyber-físicos e pela IoT (DOPICO 
et al.,2016). 
De acordo com Marquesone (2017), o conceito de Big Data faz referência ao 
grande volume, variedade e velocidade de dados, que necessitam de maneiras 
inovadoras e rentáveis de processamento da informação, a fim de melhorar a percepção 
e tomada de decisão. 
Ainda, segundo Marquesone (2017), a definição de Big Data pode ser explicada 
pela teoria dos 3Vs*: 
● Volume: grande volume de dados, de vários tipos, os quais são coletados de 
fontes variadas. 
● Velocidade: o v da velocidade faz referência a transmissão dos dados em tempo 
real, ou transmitidos em uma velocidade tempo hábil. 
● Variedade: refere-se ao formato dos dados coletados, sejam eles estruturados 
(numéricos, em databases tradicionais), não-estruturados (documentos de 
texto, email, vídeo, áudio, mídias digitais, entre outros) e semi-estruturados. 
* Em diversas literaturas é possível encontrar o termo Big Data associado à 5 Vs 
e/ou a 7Vs, entretanto, a base para que haja o projeto Big Data é fundamental para 
atender os 3Vs fundamentais. 
 
 
Figura 3: Os Vs de Big Data 
 
Fonte: A autora (2021). 
 
O Big Data pode ser uma solução para o grande fluxo de informações que existem 
na Indústria 4.0, pois além de contribuir para a mineração de dados, ele aprimora 
variáveis importantes como mobilidade, flexibilidade e eficiência. 
Sabe-se que, o Big Data é um serviço dentro da Indústria 4.0, que tem como 
principal desafio explorar os grandes volumes de dados e extrair informações úteis para 
um prognóstico científico. Mas apesar de estarmos falando em Indústria 4.0, algumas 
indústrias ainda tomam decisões baseadas em informações empíricas e de experiência 
operacional, por isso é de grande importância entender o valor de um sistema de apoio 
à tomada de decisões (MARQUESONE, 2017). 
A tecnologia Computação em nuvem permite acessar arquivos e executar 
diferentes tarefas pela internet sem a necessidade de instalação de programas ou 
armazenamento de dados, fazendo com que os serviços possam ser acessados de 
maneira remota, de qualquer lugar do mundo e a qualquer hora. Basicamente, uma 
unidade de processamento flexível de grande escala e baixo custo, baseada em conexão 
IP para cálculo e armazenamento. Dentro da Indústria 4.0, a necessidade da computação 
em nuvem está fundamentada no fato de que é preciso estabelecer relação entre os 
dispositivos de identificação para um armazenamento de grandes quantidades de 
informação, visto que se trata de um sistema complexo. 
A Realidade Aumentada é uma tecnologia advinda da Realidade Virtual, nas 
quais fazem parte do processo da Indústria 4.0. Seu funcionamento envolve a 
sobreposição de objetos virtuais no mundo real, proporcionando o enriquecimento do 
ambiente real com os objetos virtuais em tempo real (TORI, 2009), o objetivo é que o 
usuário possa interagir com o mundo e os elementos virtuais, de maneira mais natural e 
intuitiva sem necessidade de treinamento ou adaptação. Essa interação pode ser feita 
de maneira direta (com a mão ou com o corpo do usuário) ou indireta (auxiliada por 
algum dispositivo de interação). Enquanto a RV tem como objetivoa imersão do usuário 
em um ambiente virtual, de tal forma que elementos e ocorrências do mundo real 
precisam ser impedidos de interferir no mundo virtual, a fim de que, a sensação de 
imersão do usuário não seja prejudicada, a RA integra as informações virtuais ao 
ambiente físico (NAKAMOTO; CARRIJO e CARDOSO, 2009). 
A RA enriquece o ambiente físico com objetos sintetizados 
computacionalmente, permitindo a coexistência de objetos virtuais e reais em tempo 
real. Para que as aplicações de RA funcionem da maneira mais transparente e intuitiva 
para o usuário, é preciso que se utilize um dispositivo de visualização apropriado que 
reconheça as movimentações entre o ponto de vista do observador em relação ao 
restante do ambiente. 
Neste contexto, pode-se afirmar que IoT, Big Data, Computação em Nuvem e 
Realidade Aumentada, constituem uma solução ideal para desempenho de 
armazenamento e interação, bem como o gerenciamento de informações, o que torna 
tais ferramentas essenciais para o desenvolvimento tecnológico, capaz de suportar, 
processar e analisar grandes fluxos de informações em tempo real. 
 
4 O QUE É IOT? QUAIS SUAS APLICAÇÕES? 
 
Fonte: Freepik 
https://www.freepik.com/free-vector/iot-development-
illustration_18611462.htm#page=1&query=internet%20of%20things&from_query=internet%2
0das%20coisas&position=36&from_view=search 
 
Em meados de 2012, a IoT (Internet of Things) foi considerada como uma 
tecnologia emergente, a qual foi previsto que levaria aproximadamente 10 anos para ser 
adotada pelo mercado, e nos dias atuais, é vivenciado o maior pico de expectativas sobre 
a tecnologia no âmbito acadêmico e industrial (SANTOS et al., 2016). 
A IoT pode ser vista como a combinação de diversas tecnologias, as quais são 
complementares no sentido de viabilizar a integração dos objetos no ambiente físico ao 
mundo virtual. A Figura 4 apresenta os blocos básicos de construção da IoT: 
 
Figura 4: Blocos básicos para construção da IoT 
 
 Fonte: (SANTOS et al., 2016) 
 
De maneira resumida a IoT, é a maneira como os objetos estão conectados e se 
comunicando entre si e com seus usuários, através de sensores inteligentes e softwares 
que transmitem dados para uma rede. É importante destacar, a troca de informações 
entre os objetos. 
Os componentes que envolvem a Indústria 4.0 atraiu atenção da literatura, pois 
está relacionada à IoT, sistemas de virtualização, integração, interoperabilidade, sistemas 
inteligentes e outros, entretanto apesar de uma dinâmica pesquisa sobre Indústria 4.0, 
há componentes emergentes neste cenário com poucos estudos exploratórios (LU, 
2017). 
Assim sendo, a pluralidade de aplicações da Indústria 4.0 revoluciona a maneira 
de se relacionar com a tecnologia. Tal faz parte da rotina, e aos poucos ganha espaço em 
atividades e objetos triviais como correr pelo parque (rastreamento), relógios, celulares, 
casas, medicina, entre outras áreas. A existência da tecnologia em nossas vidas diárias é 
inquestionável. Quando o software não está funcionando apropriadamente, sentimos o 
impacto por meio de inconveniências, como, semáforos nas grandes cidades estão fora 
de sincronia, atrasos de voos, erro de transações, indisponibilidade de serviços e 
inúmeros outros. 
Em virtude de inúmeras áreas de aplicação, e com o objetivo de reduzir riscos e 
falhas na implantação dessas aplicações, é necessário a utilização da Engenharia de 
https://www.proof.com.br/blog/splunk-revolucao-digital/
https://www.proof.com.br/blog/splunk-revolucao-digital/
Requisitos como apoio na elicitação e análise de requisitos concretos e eficazes capazes 
de amparar tais aplicações. 
 
5 FUNDAMENTOS DA ENGENHARIA DE REQUISITOS 
A Engenharia de Requisitos (ER) é uma área da Engenharia de Software, a qual 
pode ser considerada como o ponto crucial de sucesso ou fracasso para o 
desenvolvimento de um produto, serviço, aplicação e outros, fornece ferramentas para 
que os profissionais de computação possam lidar totalmente com os requisitos de 
diferentes estágios do ciclo de vida do produto de software. Entretanto, desenvolver 
projetos de software não é uma atividade trivial e os desafios iniciam-se na parte do ciclo 
de vida: os requisitos. 
 
Figura 5: Elicitação dos Requisitos 
 
Fonte: Freepik 
https://www.freepik.com/free-vector/software-requirement-description-abstract-concept-
illustration_12291093.htm#page=1&query=requirements&from_query=requisitos&position=4&from_vi
ew=search 
 
Antes de tudo, vamos definir os requisitos, o glossário padrão de terminologia 
de engenharia de software do Institute of Electrical and Electronic Engineers (IEEE, 1989, 
p. 634) define requisito como: 
 
 
1. Uma condição ou capacidade necessária para um usuário resolver um 
problema ou alcançar um objetivo. 
2. Uma condição ou capacidade que deve ser atendida ou tida por um sistema 
ou componente do sistema para satisfazer a um contrato, padrão, 
especificação ou outro documento formalmente imposto. 
3. Uma representação documentada de uma condição ou capacidade 
conforme estabelecido em 1 e 2. 
 
Os requisitos representam um dos pontos mais críticos na produção de software. 
Compreensão insuficiente dos requisitos, designação pouco clara e gerenciamento 
inadequado estão entre as principais razões para o fracasso de projetos de tecnologia da 
informação. 
No cotidiano, a consequência mais comum dos problemas em requisitos é o 
aumento do retrabalho, gerando a custos não previstos no planejamento. Quanto mais 
longe do início do projeto ou da sprint* o qual o problema é relatado ou percebido, mais 
caro é para consertar. Quanto mais atividade já tiver sido realizada sobre o requisito 
(especificação, implementação, testes, entrega), mais difícil e trabalhoso é consertar e 
maiores são os impactos negativos para o projeto ou para a sprint. 
 
 
REFLITA 
 
De acordo com Schwaber e Sutherland (2018), o termo sprint (denomina um ciclo 
de desenvolvimento em uma empresa que utiliza o método ágil Scrum. Comumente uma 
sprint possui duração média de duas a quatro semanas, com o intuito de entregar um 
artefato do seu ciclo de desenvolvimento.) 
 
Fonte: Schwaber e Sutherland (2018). 
 
#REFLITA# 
 
Os problemas associados aos requisitos podem ser advindos de distintos fatores, 
entre eles, podem-se destacar: 
 
● O requisito estar em um nível de detalhamento insuficiente para as etapas 
seguintes do ciclo de desenvolvimento; 
● O requisito pode conter ambiguidades ou imprecisões que levem os 
membros da equipe a interpretá-lo de maneira diferente do que o 
esperado, gerando erros em fases e etapas subsequentes do ciclo de 
desenvolvimento; 
● O requisito pode estar incompleto; 
● O requisito pode ser incompatível com outro requisito; 
● O requisito pode ser difícil de testar e validar. 
Tais problemas supramencionados podem ocorrer por n fatores, que variam de 
acordo com o tipo de projeto, contexto de negócio, características das equipes, 
tecnologias e linguagens envolvidas. 
Relembrando o que Frederick Brooks já nos alertava em 1987 (BROOKS, 1987, p. 13): 
 
 
A parte mais difícil ao se construir um sistema de software é decidir 
precisamente o que construir. Nenhuma outra parte do trabalho conceitual é 
tão difícil quanto estabelecer os requisitos técnicos detalhados, incluindo a 
interface com as pessoas, máquinas e outros sistemas de software. Nenhuma 
outra parte afeta tanto o sistema resultante se for feita de forma errada. 
Nenhuma outra parte é tão difícil de consertar depois. 
 
O sucesso no desenvolvimento de um software pode ser medido pela maneira 
com que ele realiza as atividades para qual foi proposto. Os requisitos possuem uma 
função primordial no processo de software, por apresentar a função de identificar os 
requisitos das partes envolvidas, definirem as funcionalidades, restrições e entre outros, 
sendo assim, considerado um fator decisivo para o sucessoou fracasso de um projeto 
(ARRUDA et al., 2014). 
A Engenharia de Requisitos se preocupa com as metas, funções e restrições de 
uma aplicação, sendo apontada com um processo para extrair, descrever, documentar e 
validar os requisitos de um produto de software através da identificação das partes de 
interesse (CORREA; DELAMARO e NUNES, 2013). 
Um processo de ER (Engenharia de Requisitos) é um conjunto de atividades que 
devem ser seguidas para derivar, validar e manter um documento de requisitos, o 
processo envolve criatividade, interação de diferentes grupos, conhecimento e 
experiência para transformar informações diversas em documentos e modelos que 
direcionam o desenvolvimento de software. No entanto, não faz sentido falar em 
processo ideal sabendo que o processo de ER pode variar de uma organização para 
outra, o processo pode ser adaptado atendendo às s necessidades reais de cada 
organização, de maneira generalizada a maioria dos processos de ER podem ser descritos 
em um modelo de atividades de alta granularidade, como apresentado na Figura 6. 
 
Figura 6: Modelo de Processo da Engenharia de Requisitos 
 
Fonte: Adaptado de: SOMMERVILLE (2011) 
 
 
A elicitação de requisitos deve entender a parte interessada, seus processos e 
necessidades, com o objetivo final de comunicar essas necessidades para o 
desenvolvedor da aplicação. Essa atividade de especificação é dada por fatores 
humanos, sociais e organizacionais e envolve pessoas com diferentes conhecimentos e 
objetivos, o que a torna complexa. 
A análise de requisitos é a etapa no qual os requisitos são organizados em 
categorias, com a finalidade de explorar as relações entre os requisitos e classificar sua 
importância de acordo com a necessidade dos stakeholders (um stakeholder é qualquer 
grupo ou indivíduo que pode ser afetado pela obtenção dos objetivos de uma 
determinada organização (SOMMERVILLE, 2011)). Após essa etapa, os requisitos são 
documentados em um nível de detalhamento adequado, de maneira que os 
stakeholders possam compreender. 
A validação dos requisitos examina a especificação do software, de forma a 
assegurar que os requisitos foram definidos sem ambiguidades, inconsistência ou 
omissões, a fim de conseguir identificar os erros e corrigi-los. 
De acordo com (PRESSMAN, 2007) alguns dos problemas que surgem durante o 
processo da ER são os erros em não fazer uma distinção entre os níveis de descrição dos 
requisitos. Devido a isso, há uma separação entre os requisitos de usuários, que 
identificam os requisitos abstratos de alto nível; e os requisitos de sistema para 
descrever o que o sistema deve fazer (PRESSMAN, 2007). Quando a documentação da 
especificação de requisitos é realizada de maneira objetiva, os requisitos documentados 
têm chances de serem corretamente compreendidos pelos desenvolvedores da 
aplicação. 
 
 
6 CICLO DE VIDA DE SOFTWARE 
O ciclo de vida de um produto de software pode ser compreendido como um 
conjunto de etapas pelas quais o produto passa ao longo de sua existência, conforme 
ilustra, de forma simplificada, a Figura 7. 
A concepção é a fase na qual é identificada a viabilidade da construção de um 
produto, solução de software. Na fase de concepção, os primeiros requisitos aparecem 
na forma de objetivos de negócio de alto nível, como: “desejo um software para auxiliar 
no processo de matrícula dos alunos”. Nesse sentido, ainda não é possível medir 
exatamente o que precisa ser construído de fato, até que os requisitos sejam detalhados, 
a fim de representar as funcionalidades do produto e/ou solução, o que significa a 
elicitação dos requisitos funcionais do produto. A partir deste, tem-se afirmações: “o 
sistema deve ter uma função para cadastrar um aluno vinculado apenas a um curso”. 
Ainda na etapa de concepção é esperado os requisitos de projeto e de processo. 
Os requisitos de projeto refletem as restrições do projeto, relacionando-se aos prazos, 
recursos e orçamentos. Os requisitos de processo apresentam restrições referentes à 
maneira de como o projeto será desenvolvido. 
A fase de desenvolvimento é responsável por todas as atividades da produção do 
software. Isso inclui aquelas relacionadas a requisitos, análise e design, implementação, 
testes, homologação e implantação, além de todas as atividades de suporte ao 
desenvolvimento e à gestão do desenvolvimento. 
A fase de manutenção ocorre na maior parte das atividades de gerenciamento 
dos requisitos. Isso significa que a rastreabilidade é a ferramenta mais importante para 
a análise do impacto das solicitações de mudanças. E a fase de descontinuação acontece 
quando o produto de software não atende mais aos seus objetivos. 
 
 
 
 
 
 
Figura 7: Ciclo de vida de um produto de software 
 
Fonte: Adaptado de: SOMMERVILLE (2011) 
 
 
 
 
 
SAIBA MAIS 
 
É possível que um usuário, ao utilizar um determinado sistema pela primeira vez, 
se depare com alguns problemas ou, até mesmo, se decepcione com seu resultado, esse 
fato é dado porque a equipe de desenvolvimento falhou em algum ponto (ARRUDA et 
al., 2014). 
Acredita-se, muito provavelmente, que o envolvimento do usuário e de outros 
stakeholders ao longo do ciclo de desenvolvimento tenha sido ignorado ou mal 
conduzido ou, até mesmo inexistente, pois quando todos os envolvidos participam 
efetivamente de todas as etapas, a chance desse problema ocorrer é muito pequena. 
Para que seja possível entregar um produto de software que realmente satisfaça 
às necessidades de quem vai utilizá-lo, é de extrema importância que as atividades de 
elicitação de requisitos, refinamento do requisitos e validação dos mesmos sejam 
realizadas de forma contínua ao longo de todo ciclo de software (ARRUDA et al., 2014). 
 
Fonte: Arruda et al., 2014. 
 
#SAIBA MAIS# 
 
 
REFLITA 
 
Diante do contexto apresentado nessa Unidade 1, você consegue definir o papel 
/ função de um engenheiro de requisitos? 
 
Fonte: A autora (2021) 
 
#REFLITA # 
 
 
CONSIDERAÇÕES FINAIS 
 
O primeiro capítulo teve como objetivo apresentar uma contextualização acerca 
da Indústria 4.0 e alguns componentes, e Engenharia de Requisitos. Apesar de tanta 
facilidade e benefícios trazidos pela conexão dos objetos que nos cercam, os 
componentes ainda são considerados uma tecnologia recente em constante processo de 
melhorias e crescimento, o que evidencia o uso efetivo e concreto da etapa de ER e suas 
atividades. 
 Assim sendo, a Unidade I é o start para o nosso conteúdo, sobre Engenharia de 
Requisitos: a análise de requisitos. 
 Podemos dizer que nossa disciplina irá abordar todo processo de 
desenvolvimento de um software, seja ele um software transacional, como um software 
da Indústria 4.0, será possível identificar os pontos chaves que envolve a análise de 
requisitos, bem como elicitação, documentação, classificação, validação e implantação. 
Ressaltando, que essas fases vão ocorrer em conformidade às demandas do cliente. 
 
 
 LEITURA COMPLEMENTAR 
 
BESSA, G. C et al. Indústria têxtil 5.0: Novos modelos de gestão organizacional para a 
indústria de confecção. 
Link para acesso: 
https://aprepro.org.br/conbrepro/2020/anais/arquivos/09242020_230954_5f6d54426
7ab5.pdf 
 
CARVALHO, L. A. et al. Indústria 4.0, Cidade Inteligente e Sociedade 5.0: compreensão 
a partir dos diagramas de energia de sistemas. 
Link para acesso: 
http://www.netlogconference.com/proceedings/papers/NETLOG_2020_paper_23.pdf 
 
 
 
 
 
 
 
https://aprepro.org.br/conbrepro/2020/anais/arquivos/09242020_230954_5f6d544267ab5.pdf
https://aprepro.org.br/conbrepro/2020/anais/arquivos/09242020_230954_5f6d544267ab5.pdf
http://www.netlogconference.com/proceedings/papers/NETLOG_2020_paper_23.pdf
LIVRO 
 
• Título: Indústria 4.0: impactos sociais e profissionais 
• Autor: Rodrigo Bombonati de Souza Moraes. 
• Editora: Editora Blucher. 
•Sinopse: A Indústria 4.0 é o termoutilizado no Brasil, e em alguns outros países para 
nomear o atual estágio de desenvolvimento e avanço tecnológico. A complexidade no 
desenvolvimento de integração e interoperabilidade dos elementos que envolve a 
Indústria geram novas configurações no cenário produtivo. A leitura deste irá possibilitar 
uma melhor compreensão desses novos componentes que cercam o nosso cotidiano, 
além de alertar para a necessidade do uso mais humanizado da tecnologia. 
 
 
 
 
FILME/VÍDEO 
 
• Título: Documentário Industria 4.0 
• Ano: 2020 
• Sinopse: Este documentário, gravado antes e após o advento da Covid-19 tem como 
objetivo mostrar uma análise dos impactos que a Indústria 4.0 vem trazendo em sua 
interseção entre os ambientes físico e digital em processos de manufatura. Neste 
também é apresentado de que forma os conceitos da Indústria 4.0 ganharam impulsos 
mesmo com os impactos profundos da crise causada pela pandemia. Realmente um 
documentário para melhor entendimento dos avanços e impactos trazidos pela inovação 
tecnológica. 
• Link do vídeo: https://www.youtube.com/watch?v=QWWQr6TmWGQ 
 
 
 
 
 
 
 
 
 
 
 
https://www.youtube.com/watch?v=QWWQr6TmWGQ
 
 
 
REFERÊNCIAS 
 
ARRUDA, D. et al. Engenharia de Requisitos: Um Survey Realizado no Porto Digital, 
Recife/Brasil. 2014. 
BROOKS JR, Frederick P. Walkthrough—a dynamic graphics system for simulating 
virtual buildings. Proceedings of the 1986 workshop on Interactive 3D graphics. 1987. 
p. 9-21. 
CORREA, A. C., DELEMARO, M. E.; NUNES, F. L. S. The Relationship between 
Requirements Engineering and Virtual Reality Systems: A Systematic Literature 
Review. Virtual and Augmented Reality (SVR), 2013 XV Symposium On, 53–62. 
Disponível em: https://doi.org/10.1109/SVR.2013.52. Acesso em: 15 dez. 2021. 
DOPICO, M.; GOMEZ, A.; DE LA FUENTE, D.; GARCÍA, N.; ROSILLO, R.; PUCHE,J. A vision 
of industry 4.0 from an artificial intelligence point of view. International Conference 
Artificial Intelligence - ICAI'16, Las Vegas, USA, 2016. 
 
FRIESS, Peter. Driving European Internet of Things Research. VERMESAN: Ovidiu, 2013. 
 
FRIESS, Peter (Eds.) Internet of Things: Converging Technologies for Smart 
Environments and Integrated Ecosystems. Denmark: River Publishers, 2013. 
 
IEEE (Institute of Electrical and Electronics Engineers). 802.2-1989 - ISO/IEEE 
International Standard - Information processing systems — Local area networks - Part 
2: Logic Link Control. Technical Report, USA, 1989. 
 
LASI, H.; FETTKE, P.; KEMPER, H.-G.; FELD, T.; HOFFMAN, M. Industrie 4.0 Auslöser. 
Wirtschaftsinformatik, 2014, 56(4), 261–264. Disponível 
em:https://doi.org/10.1007/s11576-014-0424-4. Acesso em: 15 dez. 2021. 
 
LU, Y. Industry 4.0: A survey on technologies, applications and 
open research issues. Journal of industrial information integration, 2017, 6:1–10. 
 
https://doi.org/10.1007/s11576-014-0424-4
MARQUESONE, Rosangela. Big Data: técnicas e tecnologias para extração de valor dos 
dados. São Paulo, SP: Casa do Código, 2017. 245 p. ISBN 9788555192319. 
 
NAKAMOTO, P. T.; CARRIJO, G. A.; CARDOSO, A. Construção De Ambientes 
Educacionais Com Realidade Aumentada: Processo Centrado No Usuário. p. 9, 2009. 
 
NAKAMOTO, P. T.; CARRIJO, G., CARDOSO, A.; LOPES, E.; LIMA, L. Estratégia De 
Engenharia De Requisitos Para Ambientes De Realidade Aumentada. Journal of 
Information Systems and Technology Management, 2012, 9(3), 607–626. Disponível 
em: https://doi.org/10.4301/S1807-17752012000300009. Acesso em: 15 dez. 2021. 
PRESSMAN, R. S. Engenharia de Software - Uma Abordagem Profissional. 
Development, 2007, (p. 42–60). Disponível em: https://doi.org/9788563308337. 
Acesso em: 15 dez. 2021. 
SANTOS, B. P.; SILVA, L. A. M.; Celes, C. S. F. S., Borges Neto, J. B., Peres, B. S., Augusto, 
M., Vieira, M., Vieira, F. M., Goussevskaia, O. N., & Loureiro, A. A. F. (2016). Internet das 
Coisas: da Teoria à Prática. Simpósio Brasileiro de Redes de Computadores e Sistemas 
Distribuídos. Disponível em: 
https://homepages.dcc.ufmg.br/~mmvieira/cc/papers/internet-das-coisas.pdf. Acesso 
em: 15 dez. 2021. 
 
SCHWAB, Klaus. The Fourth Industrial Revolution. Genebra: World Economic Forum, 
2016. 
 
SOMMERVILLE, I. Engenharia de Software. Pearson Brasil, 2011. 
TORI, R. Desafios para o design de informação em ambientes de realidade 
aumentada. InfoDesign Revista Brasileira de Design da Informação, v. 6, n. 1, p. 46–57, 
2009. 
 
 
UNIDADE II 
PROCESSO DE SOFTWARE: REQUISITOS 
Professora Mestre Eduarda Maganha de Almeida 
 
 
Plano de Estudo: 
https://doi.org/10.4301/S1807-17752012000300009
https://doi.org/9788563308337
● Processos de Software: Requisitos; 
● Requisitos; 
● Documento de Requisitos de Sistema; 
● Modelos de Interação; 
● Design de Interação; 
● Análise de Requisitos. 
 
 
Objetivos de Aprendizagem: 
● Contextualizar algumas atividades do processo de software; 
● Descrever os requisitos, bem como, o Documento de Requisitos de 
Sistema, Modelos de Interação, Design de Interação e Análise de Requisitos. 
 
 
 
 
 
 
 
 
 
 
 
 
 
INTRODUÇÃO 
 
Grande parte das atividades que realizamos no nosso dia a dia são amparadas 
por tecnologias que há pouco tempo não existiam. 
Você consegue imaginar sua vida sem uma rede de internet? Sem WhatsApp? E-
mail? Smartphone? Pois é, vivenciamos um mundo onde o software desempenha um 
papel fundamental. 
E para que de fato os softwares sejam úteis, executem as funções esperadas, o 
ponto de partida é identificar o seu objetivo e quais atividades o software deverá auxiliar, 
ou seja, quais são os seus requisitos, quais funcionalidades, como e com quem ele deve 
interagir, como deve se comportar como deve se adaptar em cada situação. 
Neste contexto, é válido mencionar que a definição correta, sem ambiguidades 
dos requisitos são de extrema importância para um produto de qualidade. Diante desse 
cenário, ousamos dizer que os requisitos mal compreendidos e mal definidos levam, ao 
retrabalho, aumento de custos de produção, frustração dos clientes, o desgaste e podem 
gerar o fracasso do projeto de software. 
A fim de mitigar tais frustrações a Engenharia de Requisitos, e suas etapas e 
atividades se tornam o ponto fundamental para amparar nas chances de sucesso de um 
software. 
O objetivo da Unidade II é contextualizar os requisitos, bem como, o Documento 
de Requisitos de Sistema, Modelos de Interação, Design de Interação e Análise de 
Requisitos. 
 
 
 
 
 
 
 
1 PROCESSOS DE SOFTWARE: REQUISITOS 
 
 
Fonte:Freepik https://www.freepik.com/free-vector/processing-concept-
illustration_7126211.htm#page=1&query=processo&position=2&from_view=search 
 
Um sistema computacional é composto no mínimo de três componentes 
fundamentais: processador, memória e dispositivos de entrada e saída, e para tal, sabe-
se que esse sistema deve atender a distintas funções de forma simultânea e concorrente. 
Nesse contexto, é esperado que o sistema atenda, entre inúmeras requisições,às 
necessidades de um cliente, que será o responsável por fazer o uso do sistema e para 
alcançar tais necessidades é preciso realizar a coleta dos requisitos de software. 
Assim, um processo de software passa por fases identificáveis antes que uma 
aplicação seja implantada. Há diversas maneiras de progredir por essas fases, e essas 
maneiras são denominadas de, processo de software. 
As principais fases de um processo de software são: 
● Análise de requisitos – “O que?” – especificar o que a aplicação 
deve fazer; 
● Projeto – “Como” – especificar quais serão as partes e como elas 
irão se ajustar; 
● Implementação – “Codificação” – escrever o código fonte; 
● Testes – “Verificação” – executar a aplicação com dados para 
testes de entrada; 
● Manutenção – “Reparos / otimização” – reparar e/ou otimizar 
capacidades e funcionalidade dos software. 
 
Ao descrever as fases do processo, é necessário entender suasatividades como 
a especificação de um modelo de dados, o projeto de interface com o usuário, assim 
como a organização das atividades que deverão ser realizadas. 
De acordo com Sommerville (2011), os processos de software são considerados 
complexos, e dependem das partes envolvidas (stakeholders) para tomar decisões, fazer 
julgamentos e previsões. Não há um modelo ideal, cada organização desenvolve e 
adapta seus próprios processos de acordo com as suas demandas. 
Embora não exista um processo ideal, existem as melhorias nos processo 
existentes, em que alguns processos podem incluir técnicas ultrapassadas, não 
apropriadas e, até mesmo, não aproveitar as melhores práticas da Engenharia de 
Software (PFLEEGER, 2004). 
Neste contexto, a fim de aproveitar as melhorias práticas oferecidas pela 
Engenharia de Software, é importante destacar os requisitos de um software. 
 
 
2 REQUISITOS 
 
Fonte: Freepik 
https://www.freepik.com/free-vector/checklist-concept-
illustration_5573507.htm#page=1&query=lista&position=9&from_view=search 
 
A elicitação ou levantamento dos requisitos de forma clara e objetiva tendem a 
mitigar possíveis frustrações dos usuários finais de um projeto de software. Na grande 
maioria dos casos, os usuários não sabem definir o que precisam, quais suas demandas, 
tornando ainda mais complexo a captura de informações para desenvolver um projeto 
que atenda às expectativas do usuário. É válido destacar, que a identificação das 
informações, requisitos, demandas no início do projeto é importante para as próximas 
etapas do desenvolvimento do sistema. 
Os requisitos de software são as descrições do que o sistema deverá fazer, os 
serviços oferecidos e suas restrições. O termo requisito não é utilizado de forma 
consistente pela indústria de software, há relatos que os requisitos são apenas uma 
declaração abstrata em alto nível de um serviço que o sistema deve ofertar, ou até 
mesmo, uma restrição do sistema (SOMMERVILLE, 2011). Um requisito pode ser uma 
condição, capacidade, função, objetivo, propriedade ou restrição que caracteriza um 
sistema e satisfaça uma regra de negócio ou contrato. 
 
 
 
 
 
Figura 2: Requisitos de Usuário e Sistema 
 
Fonte: A autora (2021) 
 
 Sabe-se que os requisitos podem ser descritos em requisitos de sistemas e 
requisitos de usuário, o Quadro 1, relata a distinção entre ambos os requisitos, no qual 
é possível notar que um requisito de usuário pode ser expandido em diversos requisitos 
de sistema. Assim, os requisitos de usuários são considerados mais gerais e os requisitos 
de sistema fornecem informações mais específicas sobre os serviços e funções. 
 
Quadro 1: Requisitos de Usuário e Sistema 
Definição de REQUISITOS DE USUÁRIO 
O sistema médico FTC deve gerar relatórios gerenciais semanais que mostrem o custo dos 
medicamentos prescritos por cada médico durante a semana x. 
 
Definição de REQUISITOS DE SISTEMA 
1.1 No sábado de manhã, especificamente às 11:00 horas da manhã deve ser gerado 
um resumo dos medicamentos prescritos, seus custos, motivos e pacientes 
destinados de cada médico. 
1.2 Após às 11:00 horas da manhã, de cada sábado, o sistema deve gerar um relatório 
para impressão. 
1.3 Um relatório será criado para cada médico, listando os nomes dos medicamentos, 
o número total de prescrições, o número de doses prescritas e os custos totais dos 
medicamentos prescritos. 
1.4 Caso um medicamento prescrito, possa ser substituído por um genérico (com o 
mesmo princípio ativo) devem ser criados relatórios separados para cada 
medicamento. 
1.5 O acesso aos relatório de custos deve ser restrito a usuários autorizados por uma 
lista de controle de gerenciamento de acesso. 
Fonte: Adaptado de: (SOMMERVILLE, 2011) 
 
Comumente os requisitos de software são classificados como requisitos 
funcionais e requisitos não funcionais. 
Os requisitos funcionais possuem como funcionalidade descrever o que o 
sistema deve fazer. São declarações de serviços que o sistema deve fornecer, de como o 
sistema deve reagir a entradas específicas, e como se comportar em distintas ocasiões 
(SOMMERVILLE, 2011). Já os requisitos não funcionais são restrições aos serviços e 
funções oferecidos pelo sistema. 
Os requisitos não funcionais não estão diretamente ligados com os serviços 
específicos oferecidos pelo sistema a seus usuários. Podem estar relacionados às 
características emergentes do sistema, como tempo de resposta, ocupação, 
confiabilidade, portabilidade e outros (PRESSMAN, 2007). 
Um dos principais focos do desenvolvimento de software atualmente é garantir 
uma boa experiência ao usuário. Experiência do usuário é mais do que entregar todas as 
funcionalidades desejadas. É preciso que o produto entregue funcionalidades de forma 
atrativa, fácil de usar, com desempenho excelente, segurança e mais um sem número de 
outros elementos cognitivos e emocionais. A tecnologia evoluiu, assim como o grau de 
exposição das pessoas às tecnologias. Isso fez com que o usuário passasse a ser mais 
exigente. Requisitos funcionais não são, portanto, a única fonte de preocupação da 
equipe de desenvolvimento. É preciso voltar a sua atenção também para os requisitos 
não funcionais, pois são eles que agregam valor à experiência do usuário. 
Para Sommerville (2011), os requisitos não funcionais podem afetar a arquitetura 
geral de um sistema em vez de apenas componentes individuais. A Figura 2 apresenta 
um diagrama com alguns tipos de requisitos não funcionais, os quais podem ser 
provenientes das características requeridas para o software (requisitos do produto), da 
organização que desenvolve o software (requisitos organizacionais) ou de fontes 
externas: 
 
Figura 2: Tipos de requisitos não funcionais 
 
 Fonte: (SOMMERVILLE, 2011, p. 61). 
 
A fase na qual os requisitos estão sendo coletados, é o processo de reunir 
informações sobre o sistema requerido, para tal Sommerville (2011) destaca algumas 
maneiras de levantar essas informações. 
● Entrevistas – fechadas ou abertas 
o Fechadas, conjunto predefinido de perguntas que devem ser 
respondidas pelo cliente; 
o Abertas, não é criado um conjunto predefinido de questões, a 
equipe desenvolve questões com o intuito de compreender melhor as 
necessidades e expectativas do cliente; 
● Cenário – estes podem ser utilizados para obtenção detalhada na 
visão geral dos requisitos. Um cenário é iniciado com um esboço de 
interação. 
o Como o sistema deve iniciar; 
o Fluxo dos eventos no cenário. 
o Descrição das eventuais falhas; 
o Informações relevantes para a execução. 
● Casos de uso – trazem definições estabelecidas pela UML (do 
inglês Unified Modeling Language). 
 
3 DOCUMENTO DE REQUISITOS DE SISTEMA 
 
 
Fonte: Freepik 
https://www.freepik.com/free-vector/social-media-
illustration_5275573.htm#page=1&query=documento&position=29&from_view=search 
 
O documento de requisitos de sistema, também denominado de Especificação 
de Requisitos de Software (SRS – do inglês Software Requirements Specification), é 
documento concreto referente aquilo que o envolvidos (desenvolvedores) deverão 
implementar, vale destacar que essa documentação de requisitos é destinada a todos os 
stakeholders. 
A especificação deve incluir tanto os requisitos de usuário quanto os de sistema. 
É um item importante para o desenvolvimento de sistemas, algumas organizações, as 
quais utilizam métodos ágeis em seu processo de desenvolvimento, argumentam que os 
requisitos mudam constantemente e que uma especificação de requisitos acaba sendo 
deixada de lado, pois o esforço de atualização acaba sendo constante. 
As Figuras 3, 4 e 5 apresentam algumas atividades que podem ser geridas, a fim 
de auxiliar na concepção do documento de requisitos. 
 
Figura 3: Técnicas para levantamento dos requisitos - Entrevista 
 
Fonte: A autora (2021) Adaptado de: 
(https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit)Figura 4: Técnicas para levantamento dos requisitos – Observação 
 
Fonte: A autora (2021) 
Adaptado de: (https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit) 
 
 
https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit
https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit
 
Figura 5: Técnicas para levantamento dos requisitos – Encontros 
 
Fonte: A autora (2021). Adaptado de: 
(https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit) 
 
 
 
https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit
 
4 MODELOS DE INTERAÇÃO 
 
 
Sabe-se que todos os sistemas envolvem algum tipo de interação, seja do usuário 
(envolvendo entrada e saída), do sistema, entre os componentes. Ressalta neste 
contexto, que a modelagem de interação do usuário é importante, pois auxilia na 
identificação dos requisitos de usuário. 
De acordo com Sommerville (2011), a modelagem de interação destaca os 
eventuais problemas de comunicação que podem surgir, tal modelagem ampara a 
compreensão da estrutura proposta para o sistema, a fim de produzir o desempenho e 
confiança requerida do sistema. O projeto de arquitetura, deve compreender como um 
sistema deve ser organizado e como será a estrutura geral do mesmo. No modelo de 
processo, o projeto de arquitetura é a primeira etapa, responsável pelo projeto de 
arquitetura de software, sendo um projeto criativo cujo objetivo é contemplar os 
requisitos funcionais e não funcionais. 
A fim de identificar a modelagem de interação, vamos atentar à modelagem de 
caso de uso. Na linguagem de modelagem unificada – UML (do inglês Unified Modeling 
Language), o diagrama de caso de uso relata as informações dos atores (usuários do 
sistema) e como ocorrem as interações com o sistema. 
Muitas vezes, a modelagem de caso de uso é utilizada para amparar na elicitação 
dos requisitos, em que um caso de uso pode ser tomado como um cenário simples que 
descreve o que o usuário espera do sistema. A Figura 6, apresenta um exemplo de caso 
de uso, contendo um ator (atendente) e dois casos de uso. 
Figura 6: Exemplo de caso de uso 
 
Fonte: A autora (2021). 
Cada caso de uso tem como finalidade representar uma tarefa discreta que 
envolve a interação externa com um sistema. O diagrama de caso de uso não oferece 
muitos detalhes, é adequado para gerar uma visão geral do relacionamento entre casos 
de uso, atores e sistemas. É recomendado a utilização do diagrama de caso de uso para 
complementar um caso de uso descrito em texto. 
Pode-se entender que o diagrama de caso de uso é ideal para: 
 
● Representar as metas de interações entre sistemas e usuários; 
● Definir e organizar requisitos funcionais no sistema; 
● Especificar o contexto e os requisitos do sistema; 
● Modelar o fluxo básico de eventos no caso de uso. 
 
Com o intuito de gerar uma visão real do caso de uso, vamos imaginar o seguinte 
cenário: “os proprietários de uma apartamento/casa sempre têm a intenção de 
modernizar algum de seus cômodos, utilizando um software para visualizar 
possibilidades! Partindo dessa atualização, vamos modernizar um quarto. 
Essa aplicação denominaremos de VisualizadorQuarto, o qual permite que o 
usuário altere o layout das partes de um quarto sem comprometer-se com um estilo. 
 
• Vamos ao caso de uso: 
• Usuário clica no ícone “Closet”; 
• A aplicação exibe um closet no canto direito; 
• O usuário redimensiona o closet para o lado esquerdo; 
• O usuário libera o cursor; 
• O usuário clica no ícone “Painel da Tv”. 
 
A Figura 7 apresenta a visualização de alguns dos casos de uso, e com o intuito 
de gerar a interação entre os casos de uso, as Figura 8 demonstra o resultado das 
interações do usuário, ou seja, quando faz as ações com o sistema (como exemplo, 
“arrastar” os ícones para a área de exibição). 
 
Figura 7: Modelo de Visualização dos Casos de Uso 
 
Fonte: A autora (2021) 
 
 
 
 
 
 
 
 
 
 
Figura 8: Modelo de Interação dos Casos de Uso 
 
Fonte: A autora (2021) 
 
 
 
5 DESIGN DE INTERAÇÃO 
Como estamos contextualizando o modelo de interação, é importante destacar 
o design de interação, o qual é o responsável por projetar o comportamento de artefatos 
interativos em sistemas e aplicações, significa gerar experiências que aperfeiçoam a 
maneira como os usuários se comunicam e interagem com a aplicação. Cabe salientar, o 
que difere o Design de Interação de outros tipos de design é o foco nas pessoas. 
 Há uma atenção especial no design de interação, com o objetivo de desenvolver 
aplicações interativas, intuitivas e eficazes no uso, proporcionando ao usuário uma 
experiência agradável. Desenvolver aplicações interativas intuitivas requer preocupação 
em quem irá utilizá-las e em que serão utilizadas. 
As atividades que podem ser descritas como triviais do design de interação são: 
identificar as necessidades do usuário e estabelecer requisitos; desenvolver designs 
flexíveis; construir opções interativas (protótipos, storyboard) dos designs; avaliar as 
opções. 
 O artefato de identificar e estabelecer requisitos descreve e distingue os distintos 
tipos de requisitos, e tais são organizados e revisados com o usuário com a finalidade de 
atender todas as suas necessidades. 
 Durante a definição de requisitos podem surgir problemas ocasionados em não 
fazer uma separação objetiva entre os níveis de descrição. A Figura 9 apresenta um 
modelo de ciclo de vida básico para a interação humano-computador - (IHC). Existem 
inúmeros modelos, e cada um tem a sua singularidade, podendo ser utilizados em 
projetos variados. O modelo apresenta como essas etapas se relacionam umas com as 
outras e sugere não um processo de desenvolvimento de projeto completo, mas sim os 
artefatos fundamentais para que o processo seja considerado interativo e centrado no 
usuário (ROGERS; SHARP e PREECE, 2013). 
Para poder tratar o ciclo de vida de maneira mais adequada, precisamos 
responder a algumas perguntas: 
• Quem são os usuários?; 
• Quais são as necessidades?; 
• Como criar designs alternativos?; 
• Como escolher uma alternativa entre as demais?; 
• Como integrar as atividades de projeto com outros modelos de ciclo 
de vida?. 
 
Figura 9: Modelo de ciclo de vida básico para IHC 
 
Fonte: A autora (2021). 
 
Entender as necessidades do usuário significa compreender e explorar o máximo 
de informações possíveis sobre ele. Estabelecer os requisitos consiste em uma elicitação 
das informações que a aplicação deve ou não fazer, e como devem ser manipuladas. 
Os fatores de qualidade exigidos pela aplicação como, usabilidade, flexibilidade, 
portabilidade, manutenibilidade, devido às exigências advindas da particularidade de 
cada aplicação. 
Os requisitos de usabilidade é um dos quesitos fundamentais em uma interface, 
uma vez que o sucesso de um sistema dependerá de fatores como a facilidade de 
aprendizado do usuário no uso com a aplicação, flexibilidade e robustez de sua interação 
(Sommerville, 2011). 
A partir da identificação dos requisitos de design, as personas e cenários podem 
ser criados para auxiliar os projetistas durante o processo de desenvolvimento da 
interface da aplicação. O conceito de persona foi introduzido em 1998 por Alan Cooper 
no livro intitulado “The inmates are running the asylum”, de acordo com o autor, a 
técnica proposta é trivial e eficaz, pois as personas são são personagens fictícios que 
possuem certas características de um grupo de usuários, tais características são guiadas 
por dados coletados na fase de elicitação de requisitos. 
Similar as personas, os cenários de uso é uma técnica considerada simples, e 
prevê que todo cenário deve envolver no mínimo uma persona e um objetivo. Os 
cenários são importantes para descrever as ações que os usuários deverão realizar, os 
storyboards são uma maneira de ilustrar os cenários (SOMMERVILLE, 2011). 
A etapade avaliar tem como propósito verificar se a documentação dos 
requisitos definem o que o usuário realmente necessita, se o protótipo gerado está de 
acordo estes requisitos, É importante salientar que outros tipos de verificações podem 
ser inseridas, como a verificação de completude e consistência (SOMMERVILLE, 2011). 
Essa etapa, na maioria dos casos, conta com a participação do cliente e analista de 
requisitos. Possui o produto como etapa final. 
 
 
6 ANÁLISE DE REQUISITOS 
Até este momento, podemos identificar a importância em diferenciar as 
classificações dos requisitos, em sistema e usuário, pois cada um indica elementos para 
o desenvolvimento do sistema. 
A elaboração da documentação de requisitos deve expressar as demandas e 
características específicas do sistema que será desenvolvido, além de classificar os 
requisitos elicitados. Tal classificação deve acontecer por prioridade (essencial, 
importante e desejável) para que durante o desenvolvimento sejam enfatizados os 
requisitos essenciais para o funcionamento do sistema. 
 
Figura 10: Análise dos Requisitos - Prioridades 
 
Fonte: Freepik 
https://www.freepik.com/free-vector/tiny-people-doing-priorities-checklist-flat-
illustration_13683705.htm#page=1&query=priority&from_query=prioridade&position=7&from_view=se
arch 
 
A Análise de Requisitos é responsável por coletar dados essenciais e necessários 
para contemplar as exigências do usuário, com o intuito de resolver um determinado 
problema e alcançar seus objetivos, assim como identificar as suas expectativas para 
determinado produto. 
Diante de tal complexidade do software, a obtenção dos requisitos não termina 
após a concepção de sua documentação, inclusive outra informação que um documento 
de requisitos deve nos trazer é sobre a prioridade dos requisitos, que podem ser 
classificados como essencial, importante e desejável ou, até mesmo, como prioridade 
baixa, média e alta. Porém, o objetivo é o mesmo, classificar o requisito conforme a 
prioridade de implementação e importância dele perante o sistema. Essa classificação é 
utilizada no gerenciamento do escopo das etapas do projeto e na definição das 
prioridades durante o desenvolvimento do sistema. 
De acordo com a IEEE (1990) a análise de requisitos é um processo que 
envolve o estudo das necessidades do usuário para se encontrar uma definição 
correta ou completa do sistema ou requisito de software. Tal análise de requisitos 
é fundamental para o desenvolvimento do sistema, que vai determinar o sucesso 
ou o fracasso do projeto. Os requisitos devem fornecer a referência para validar 
o produto final, ressaltando novamente a necessidade do envolvimento de todos 
os stakeholders durante o processo de desenvolvimento. 
Segundo Sommerville (2011, p. 98), a Análise de Requisitos consiste em: 
 
Reconhecer o problema – primeiro contato com o cliente, momento de 
entender as reais necessidades, problemas e demandas. Avaliar o 
problema e a síntese da solução – tem-se o entendimento do 
problema, e faz-se a identificação das informações que serão 
necessárias ao usuário, identificação das informações que serão 
necessárias ao sistema e a seleção da melhor solução possível dentro 
das soluções propostas. Modelar – para facilitar o entendimento do 
sistema, como as funcionalidades, informações e comportamento do 
sistema. Especificar os requisitos – consolidar as funções, interfaces, 
desempenho, o contexto e as restrições do sistema. Revisar – com o 
cliente fazer os ajustes necessários, eliminar possíveis redundâncias, 
inconsistências e omissões do sistema. 
Diante do exposto, o processo de elicitação de requisitos juntamente com 
sua análise podem ajudar a mitigar possíveis frustrações de clientes ao final de 
um projeto de software. A identificação de requisitos no início do projeto é muito 
importante para o bom desenvolvimento do sistema, o qual acaba se tornando 
uma condição, uma capacidade, uma função, um objetivo, uma propriedade ou 
uma restrição que caracteriza um sistema e satisfaça uma regra de negócio ou 
contrato. Para tal, é importante elaborar a documentação de requisitos e regras 
de negócio expressando as necessidades e características do sistema, para que 
durante o desenvolvimento sejam enfatizados os requisitos essenciais para o 
funcionamento do sistema, consequentemente evitando alguns retrabalhos. 
SAIBA MAIS 
 
“O modelo de processo de software é uma representação simplificada de um 
processo de software. Cada modelo representa uma perspectiva particular de um 
processo e, portanto, fornece informações parciais sobre ele. 
Exemplo: Um modelo de atividades do processo pode mostrar as atividades e sua 
sequência, mas não mostrar os papéis das pessoas envolvidas.” 
 
Fonte: Sommerville, 2011. 
 
#SAIBA MAIS# 
 
As revisões e inspeções de software fazem parte da rotina da organização que 
tem a qualidade implantada. Neste SAIBA MAIS, vamos entender como conduzir uma 
reunião de revisão de software. 
 
Fonte: A autora (2021) 
Adaptado de: (https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit) 
 
 
Fonte: A autora (2021). 
Adaptado de: (https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit) 
 
 
https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit
https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit
 
Fonte: A autora (2021). 
Adaptado de: (https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit) 
 
 
 
REFLITA 
 
Sabemos até esse momento, que a elicitação concreta e objetiva dos requisitos 
é uma atividade fundamental e pode ser decisiva para o sucesso ou fracasso ou sucesso 
de um software. Diante desse cenário de elicitação de dos requisitos, como você 
descreveria a importância da elicitação de requisitos para o projeto de software? 
 
Fonte: A autora (2021). 
 
#REFLITA# 
 
 
 
 
https://www.canva.com/design/DAEoJo71OLE/xRZ_tTqmISIDZqYYttMCcA/edit
CONSIDERAÇÕES FINAIS 
 
Desenvolver software é uma atividade cognitiva e sujeita a erros, uma vez que é 
desenvolvida quase exclusivamente por pessoas. As pessoas cometem erros, e esses 
erros podem levar a diversos tipos de prejuízos, como o retrabalho, prejuízos materiais 
e até mesmo risco à segurança e à vida. A execução completa das etapas da Engenharia 
de Requisitos pode garantir que o produto final atenda às necessidades para a qual está 
sendo desenvolvido. Isso quer dizer que, ao ser implantado, ele irá satisfazer às 
necessidades dos stakeholders. 
Embora seja possível realizar as atividades de validação no momento em que o 
produto será entregue, isso não é nada eficiente, pois pouco poderá ser feito para evitar 
a decepção e a frustração dos stakeholders. Portanto, atividades de validação devem 
fazer parte do dia a dia do desenvolvimento, começando pela validação dos requisitos e 
seguindo pelas demais etapas, de forma que erros, omissões e conflitos possam ser 
detectados o mais cedo possível, prevenindo custos adicionais com retrabalho e riscos 
no uso e na operação do produto. 
Assim, a Unidade 2 teve como objetivo apresentar alguns elementos Engenharia 
de Requisitos, como: Análise de Requisitos, Validação de Requisitos, Documento de 
Requisitos, Especificação de Requisitos, Diagramas de Casos de Uso, Qualidade em 
Requisitos e Validação dos Requisitos. 
 
 
 
LEITURA COMPLEMENTAR 
 
● Trabalho de conclusão de curso: Uma abordagem para especificação 
de requisitos sensíveis ao contexto baseado em casos de uso para sistemas 
autoadaptativos 
 
AMARAL, Eduardo Florindo. Uma abordagem para especificação de requisitos sensíveis 
ao contexto baseado em casos de uso para sistemas autoadaptativos. 2017. 
Link para acesso: 
https://dspace.unipampa.edu.br//bitstream/riu/1938/1/Eduardo%20Florindo%20Ama
ral%20-%202017.pdf 
 
● Artigo: Requirements Smells como indicadores de má qualidade na especificação 
de requisitos:Um Mapeamento Sistemático da Literatura. 
 
NASCIMENTO, Rafael et al. Requirements Smells como indicadores de má qualidade 
na especificação de requisitos: Um Mapeamento Sistemático da Literatura. WER. 
2018. 
Link para acesso: 
https://www.researchgate.net/publication/331911474_Requirements_Smells_como_i
ndicadores_de_ma_qualidade_na_especificacao_de_requisitos_Um_Mapeamento_Sis
tematico_da_Literatura 
 
 
 
 
 
 
https://dspace.unipampa.edu.br/bitstream/riu/1938/1/Eduardo%20Florindo%20Amaral%20-%202017.pdf
https://dspace.unipampa.edu.br/bitstream/riu/1938/1/Eduardo%20Florindo%20Amaral%20-%202017.pdf
https://www.researchgate.net/publication/331911474_Requirements_Smells_como_indicadores_de_ma_qualidade_na_especificacao_de_requisitos_Um_Mapeamento_Sistematico_da_Literatura
https://www.researchgate.net/publication/331911474_Requirements_Smells_como_indicadores_de_ma_qualidade_na_especificacao_de_requisitos_Um_Mapeamento_Sistematico_da_Literatura
https://www.researchgate.net/publication/331911474_Requirements_Smells_como_indicadores_de_ma_qualidade_na_especificacao_de_requisitos_Um_Mapeamento_Sistematico_da_Literatura
 
LIVRO 
 
• Título: Engenharia de Software Moderna: Princípios e Práticas para 
Desenvolvimento de Software com Produtividade 
• Autor: Marco Tulio Valente. 
• Ano: 2020. 
• Editora: Independente. 
• Sinopse: Essa recomendação de leitura é válida para nos manter atualizados nos 
processos de desenvolvimento, especificamente os métodos ágeis, como Scrum, XP e 
Kanban. Além disso, relatos sobre levantamento de requisitos de forma ágil e suas 
adaptações com os clientes. Contextualização da arquitetura de software, a qual se torna 
fundamental para visualização do sistema como um todo. É uma leitura que trará maior 
visibilidade aos processos de desenvolvimento de softwares contemporâneos. 
 
 
 
 
 
 
FILME/VÍDEO 
 
• Título: Gerenciamento de “Requisitos” 
• Ano: 2016. 
• Sinopse: (Todo mundo espera que um projeto cumpra seu prazo, orçamento e escopo. 
Mas, em muitos casos, mesmo cumprindo com seus compromissos, gerentes e 
administradores não entendem porque é que seus projetos e investimentos falham no 
principal: atender às necessidades para as quais foram criados. Este pequeno vídeo 
apresenta de maneira simples e didática o que é o gerenciamento de requisitos, e de 
que forma a sua prática pode auxiliar projetos a serem bem sucedidos no alcance de 
seus objetivos. As tarefas do Gerenciamento de Projetos apresentadas são baseadas no 
Guia BABOK versão 3 (IIBA - Instituto Internacional de Análise de Negócios, 2015). 
• Link do vídeo: https://www.youtube.com/watch?v=jajQyzOpLaE 
 
 
 
 
 
 
 
 
 
https://www.youtube.com/watch?v=jajQyzOpLaE
 
 
 
 
REFERÊNCIAS 
 
IEEE - Institute of Eletricaland Eletronics Engineers. Standards Glossary of Software 
Engineering Terminology: Std 610.12, N.Y.,1990. 84p. 
 
PFLEEGER, S. L. Engenharia de Software: Teoria e Prática (2nd ed.). Pearson Education 
do Brasil, 2004. 
 
PRESSMAN, R. S. Engenharia de Software - Uma Abordagem Profissional. 
Development, 2007, (pp. 42–60). Disponível em: https://doi.org/9788563308337. 
Acesso em: 15 dez. 2021. 
 
ROGERS, Y.; SHARP, H.; PREECE, J. Design de Interação. 3a ed. Porto Alegre - RS: [s.n.]. 
 
SOMMERVILLE, I. Engenharia de Software. Pearson Brasil, 2011. 
 
UNIDADE III 
PROTOTIPAÇÃO 
Professora Mestre Eduarda Maganha de Almeida 
 
 
Plano de Estudo: 
● Análise de Requisitos; 
● Técnicas de Análise de Requisitos; 
● Componentes da Análise dos Requisitos. 
 
 
Objetivos de Aprendizagem: 
● Contextualizar algumas atividades da fase da Análise de Requisitos; 
● Apresentar as técnicas de Análise de Requisitos; 
● Relatar os componentes da Análise dos Requisitos; 
● Conceituar a Engenharia de usabilidade; 
● Descrever as Técnicas de Modelagem. 
 
 
INTRODUÇÃO 
 
 
Como vimos nas Unidades anteriores, a Engenharia de Requisitos é um aspecto 
importante no Gerenciamento de Projetos, que tem como objetivo coletar dados e as 
demandas do usuário, a fim de alcançar o foco do projeto de software. Nesse contexto, 
podemos ressaltar como ponto chave, a coleta das necessidades do usuário de forma 
clara e objetiva pode impactar no produto de software final. 
Vamos pensar no desenvolvimento de software para gerenciar uma biblioteca, o 
que precisamos para iniciar esse processo? É necessário identificar as necessidades do 
nosso cliente (no nosso caso, a biblioteca), diante dessa identificação, temos que 
verificar a viabilidade dessas necessidades, a fim de entender se o desenvolvimento 
pode prosseguir. 
A partir da verificação de viabilidade, nos deparamos com a etapa de Análise dos 
Requisitos, cujo é importante compreender suas atividades, como classificar tais 
requisitos, analisar se a empregabilidade do software estará em conformidade com as 
especificações iniciais. Enfim, há inúmeros artefatos a serem seguidos, assim, o objetivo 
da Unidade III é definir e contextualizar a Análise de Requisitos e suas atividades, bem 
como apresentar exemplos de modelagem de requisitos, os quais podem amparar na 
sua validação com os envolvidos. 
Além disso, iremos relatar sobre a Engenharia de usabilidade e sua importância 
no processo de elicitação de requisitos, a qual também pode ser grande aliada para as 
etapas do processo de elicitação e análise de requisitos. 
 
 
 
 
 
 
 
 
1 ANÁLISE DE REQUISITOS 
 
Fonte:Freepik 
https://www.freepik.com/free-vector/setup-analytics-concept-
illustration_7140765.htm#page=1&query=an%C3%A1lise&position=5&from_view=search 
 
De acordo com Sommerville (2011), a análise de requisitos é um 
processo que envolve o estudo das necessidades do usuário para se encontrar 
uma definição correta ou completa do sistema ou requisito de software. 
A análise de requisitos é fundamental para o desenvolvimento de um 
sistema, pois envolve constantemente o usuário durante seu processo, a fim de 
gerar influências em todas as etapas e impactar no resultado final. 
A Análise de Requisitos consiste em, reconhecimento do problema; 
avaliação do problema e síntese da solução; modelagem; especificação de 
requisitos e revisão. Cada fase vai obedecer suas características específicas. 
Em reconhecimento do problema, é identificado a elicitação do sistema, o 
modelo de planejamento, a interação do analista de requisitos com o cliente, a 
fim de entender sua demanda (SOMMERVILLE, 2011). 
A avaliação do problema e síntese da solução, são fundamentais para 
detecção completa dos requisitos requeridos pelo cliente. A fase da modelagem 
tem como intuito dar suporte a síntese da solução, apresentando ferramentas 
que podem facilitar a compreensão dos possíveis comportamentos do sistema 
(SOMMERVILLE, 2011). 
A fase de especificação dos requisitos, é a fase referente à consolidação 
das funções, interações, desempenho e restrições do sistema (SOMMERVILLE, 
2011). E, por fim, não menos importante que as demais fases, a revisão, a qual 
geralmente é realizada com conjunto com o cliente, realizando as avaliações de 
conformidades do sistema de acordo com o elicitado em fases anteriores 
(SOMMERVILLE, 2011). 
 
Figura 1: Avaliação dos Requisitos 
 
Fonte: Freepik 
https://www.freepik.com/free-vector/star-rating-with-two-different-
backgrounds_1014851.htm#page=1&query=avaliar&position=1&from_view=search 
 
2 TÉCNICAS DE ANÁLISE DE REQUISITOS 
 
Fonte: Freepik. https://www.freepik.com/free-vector/approval-mark-product-advantage-rating-reviews-
meeting-
requirements_12085280.htm#page=1&query=requirements&from_query=requisitos&position=1&from_
view=search 
 
A análise de requisitos vai ser o processo para determinar as necessidades 
e interesses dos steakholders para atingir seus objetivos. Entre as técnicas 
existentes, pode-se citar entrevistas, brainstorming, questionários, pesquisas e 
observação. 
A entrevista apresenta a verificação